It's concerning how many developers obsess over code quality while missing the fundamental question: are we building what users actually need?
Most of us have seen projects where teams spent weeks perfecting their architecture, choosing the latest frameworks, and arguing over the smallest of details on a pull request - only to deliver features that users never use. đźš« This happens because we often jump straight into implementation without properly understanding the business requirements.
Here's a typical scenario:
Developer: "I've implemented a complex caching system to improve performance by X%"
User: "But I need the system to handle multiple currencies, not faster loading times"
The solution?
- Start with workshops with BOTH your business and devs. 🤝
- Use techniques like Event Storming or Domain Storytelling to make sure everyone is on the same page. đź“ť
- Implement a system with 0 latency feedback loops - anyone should be able to send a screenshot to the business and ask their take. 🔄
Typically, teams spend a tiny minority of the whole project time on the things above, whereas it should take a good chunk of total project time.
Technical excellence matters, but it should come after ensuring we're building the right solution.
Final food for thought: A perfectly coded wrong solution is still wrong. 🤷‍♂️
Top comments (7)
If you are in a company where developers get the freedom to build features the customer doesn't want, developers are having too much free time.
I'm not saying developers can't suggest better solutions, but it is up to the customers to decide if they want it or not. It is their money your are spending.
Of course the opposite can happen too, when the customer keeps requesting features that are not needed. Most of the times it is because the application has become that complex or there is no adequate documentation and the users are lost.
I agree that for all projects communication is the most important thing. Not only customer to developer, but also amongst developers or other groups of people that work on a project.
I believe the big frontend-backend split is due to a lack in communication.
I did see months-long features developed that were then completely scrapped. It was in a product company so there wasn't just one client specifically. In this case there wasn't much communication at all, so everyone thought the right thing was being done.
Another issue would be not necessarily implementing the features that are completely unneeded, but rather implementing something based on incorrect understanding of the requirements.
Here the blame is on both sides - the client/business and the devs.
Hence the importance of communicating well.
It's easy to say of course. Sometimes I feel like communication works if there is someone with great organizational/comm skills but often times there is no one like that.
Then it helps to go through some design workshops (or periodic ones) with everyone in the room to talk through their interpretation of the requirements.
True on the frontend-backend split, they seem very far apart. There are full-stack devs which in my opinion are a great asset to a team, but that's another discussion, too long to be had here hehe.
As far a I know I never had a big feature cancel because of bad communication. There were other reasons big features were cancelled but they had nothing to do with communication.
I think if companies don't invest in people with good communication skills they will fail. I think there is a difference between technical communication and business communication. It is like talking using PHP jargon during a Java conference talk.
As a developer it can be hard to master to business communication, that is why it is good that there is a person that can do both. Most of the times that person is only technical adjacent.
I think event storming and domain storytelling is already to technical. Flowcharts or visual mocks are much easier and less time consuming.
The MoSCoW method is a good way prevent scope creep.
Project management is a skill on its own, and I have seen quite a few people that can do it doing different projects at once. I picked up tips and tricks form them, but I would never call myself a project management master.
Like programming communication has a lot of different facets. Most of us are not able to master everything, but knowing some bits can be enough to create connections.
I've been on 5 dismal failures. Each failed for a different reason.
Project 1. The project leader was a moron. That's it, end of story.
Project 2. The company was going down. The project went down for the ride. Which was unfortunate, because the project was ISDN on OS/2 back in the 1990s, and it was awesome technology. Ahh well.
Project 3. The project was a "make work" project. Hard to get excited about a corporate project that just exists to keep the developers from getting bored. Wasn't even an R&D project, nor skunkworks. Just a busy work nothingburger.
Project 4. The project was going along smoothly... until the company acquired a small company that already had a successful product in that market space. Our project was redundant, and had it's plug pulled. (I am a big proponent of "innovation through acquisition", so I'm 100% behind the decision. Even though our heroic efforts were for nought, and our code was fabulous.)
Project 5. The project leader did not know how to run a project. The project leader was not a programmer, he was a subject matter expert. (Not claiming I would have done any better running such a project.) Eventually the project folded. From its ashes, the project leader did the project (mark 2) all on his own, as a one-man show. So, yeah... kudos to him — he taught himself how to program, and got it done all by himself! Some of the worst code I've ever seen, but cleaning that up was left to the maintenance crew.
This is a real concern.
To mitigate such issues, define some roadmap and critical features.
Use weighting coefficients.
This way, you won't discard the caching system. You just prioritize other tasks.
I absolutely agree that aligning technical and business priorities is crucial. It's one of my main focuses as a marketer in an engineering world!
Moving forward, it's important to consider:
The best teams sequence priorities appropriately - first building the right thing, then refining how it's built. Iteration is key.
I think the most important thing is to understand what the customer needs. For this, product teams and different stakeholders are essential—they study and understand these needs better than developers. So, in my opinion, developers need to have good communication with other teams and stakeholders. We need to understand the priorities, the needs, and reduce the product to a real MVP.
However, we also need to have strong control over technical aspects. It's very important to know what's happening with our product—good observability and data help us react quickly to any problem.
In my experience, we can move fast and create a small MVP to start understanding the customer. But we must keep good control of the product. For me, communication, data, and observability are key.