Have you ever had a failed project? Of course you have. Did you analyze the reasons? Maybe something wasn’t delivered on time, or within budget, or with full scope. This happens more often than you think, and guess what? Most of the time, it’s not about the bad code. It’s about unreached business goals.
Let me explain. Developers write code, right? They try to solve some problems with technical decisions. Nothing wrong with that.
The problem starts with the mindset of a developer when they think that the result of their work stops with the code. For instance, they committed a new piece of code at the end of the day and told themselves, “Great job!” Or, they used all the latest frameworks and design patterns — well done! Or, maybe they achieved 100 percent test coverage — wow, talk about being a guru!
However, somewhere on this planet, there lives a person who is your client. You know, the person who pays the money, who usually doesn’t know anything about the code (and doesn’t actually care). This person hired you to deliver a solution for either their business or a client’s business, and they have totally different metrics for success of your work than those listed above.
All clients care about is business goals: money, numbers, customers, and market traction, depending on the project. Delivery of your code is judged exactly from that perspective.
Now, let’s get back to the developer’s world and look at some examples of what I mean.
I’ve already mentioned above things like design patterns and correct architecture. That’s great, but does the product you’re creating really require the level of attention you’re devoting to this type of optimization? If a client is aiming to try out the market with so-called “minimum viable product,” there’s no need for a premature optimization. There is a good chance that the project won’t even grow to that level.
From that point of view, what do you think? Would your client be happy if you just do it as quickly as possible, and potentially save them some money? After all, to them, if you deliver the product faster, that allows them to test the market sooner and create some plans for the next version of the product.
You could probably argue that if you don’t spend the time on proper architecture and foundation, then it will be expensive to fix bugs in the future, which would lead to recreating the project from scratch. That’s true, but again, think about it from the business point of view.
In my experience, if the project grows to the point of dealing with optimization issues, by that point the client will have a lot of clients, their feedback, analytics numbers, and usually a new vision for the next step of growth. Quite often, that means recreating the project from scratch, not because of those performance issues, but because of business reasons — different functionality, pivoted pricing model, new design, etc.
Wrong Kind of Testing
How do developers usually test the code? A better question is, what do they test? In my experience, it’s all about avoiding bugs: validation of input data, successful registration process, whether all links work or not, etc. In other words, if it doesn’t cause a bug or exception, we’re good to go.
However, that’s not enough. It’s too narrow. You need to take things a step further into the business world.
You care about business results, right? In addition to making something work, developers also need to test whether that function is actually being used. For that, you usually need to set up some kind of analytics or event tracking system to monitor the usage after the launch. Be prepared to change the functionality or even remove it. After all, that extra code is pointless if your client doesn’t employ it, so it’s wise not to get attached.
Also, while testing before the launch, look for the logical errors. What doesn’t make sense or is hard to use? What could potentially cause users to not use the function? Too many fields to fill? A too clunky menu navigation? Some buttons missing?
If you have misgivings, tell them to the client before the launch. Don’t be afraid to question existing decisions if you think that, after building the function, they don’t make sense from a business point of view.
Of course, to be able to think in that direction, you need to do extra homework on the business context. Dig a little deeper into the product and its goals, have a few conversations asking the client “why?”, and possibly even read some articles or books on the subject. All that preparation is worth the time because then you can give much more value to your client; you’re not just a pair of hands.
What’s important to remember here is to talk to the client in their language: speak about conversions and numbers, not about code or design.
It’s Not My Problem
Quite often, it seems that developers see business people as their enemies. Project managers, clients, marketing department, salespeople — even if they all work in the same company — there’s a silent war going on.
Usually, you can feel it by hearing phrases like:
- “…they’re stupid and constantly changing demands…”
- “…meeting again? They don’t let me do my job!”
- “…they think it’s a five-minute change, they have no idea…”
- “…I don’t know how long it will take. It’s done as soon as it’s done…”
These types of comments are typical of developers focused only on delivering the code without thinking too much about the business application for it. They don’t realize that someone would need to present that functionality to the customers, write a press release or a blog article, apologize on undelivered deadline promises, etc. You know, that outside world, with real people.
In reality, the development team and the marketing team should act as one team with a common goal. They should help each other by discussing situations instead of blaming each other.
Make Your Work Matter
These are only three cases. You can come up with much more. It all comes down to one thing: at the end of your busy day, when you get up and shut down your computer, don’t evaluate your results on the amount of code produced. Ask yourself, “Did I do everything to help my client be a step closer to their business goal?”
If you constantly challenge yourself with that question, you become a much bigger asset in the eyes of your clients, as you’re not just a developer; you’re almost like a business partner.
You give advice, you prioritize tasks according to the situation, you actually make writing code an invisible process. Above all, you deliver business results and talk about them; not about your coding world, but about the client’s world of business. When you do this, your work becomes invaluable.