Five Reasons Why Developers Miss Chances of Creating More Value
Originally published in GoRetro
Originally published in GoRetro
I started my career as a software developer, and my dream was to become a software architect. The digital world has always fascinated me, and I enjoyed my job a lot; creating solutions put me on fire. But at some point, I realized my work wasn’t making others’ lives any better, my solutions were either being trashed or not used, and I didn’t know why until I talked to an actual end-user.
Talking to end-users, I perceived a massive gap in our processes. Management decided what to do, and project managers created a lovely plan full of charts, and we were convinced we knew what we had to do. Unfortunately, nobody talked to real end-users as managers thought they knew what users needed. I wish they were right.
The hard way, I learned the pain of GIGO. Garbage In, Garbage Out.
After some years as a developer, I decided to move to product management because I didn’t want any developer to create trash. I thought I could help teams create value. However, when I became a Product Manager, I faced many challenges with developers. And sometimes went against producing value faster.
I’ve already fallen into the mentioned traps either as a developer or a Product Manager. Hopefully, you can avoid them on your way. Allow me to share the five reasons developers miss chances of delivering REAL value.
1 — Solution Orientation
What matters most, implementing a solution or solving a problem? It makes no sense to talk about solutions without knowing the problem to solve, yet I often land in deep technical discussions where the problem is unknown.
Developers are passionate about creating solutions, and that’s great. But it’s a trap at the same time. Developers tend to ignore the problem if product managers don’t clarify it. Still, I don’t want to generalize because experienced developers ask for the problem before talking about any solution.
The implementation trap is falling in love with the solution and building something extraordinary nobody needs. Everything starts with understanding the problem and then figuring out how to solve it.
Once I had a great conversation with a developer about identifying the correct size solutions, it went like this:
Me: “Three months ago, we were 20 people, and now we are 50. Our internal system needs to have adequate user management.”
Developer: “Sure. Tell me more about it. What do you want to solve with that?”
Me: “I want to ensure users are limited to do what is related to their responsibilities. Currently, everyone can do everything, and this is dangerous.”
Developer: “I see. Let me tell you what. Imagine a mosquito is lying on the wall. You can kill it in several ways, I could smash it with my flip-flop, or I could build a bazooka to kill it. What kind of solution are you searching for?”
Whenever I see deep technical discussions, I ask developers, “Are we building a bazooka to kill a mosquito?”
2 — Segmented Accountability
A few things annoy me more than discussing splitting the stories into back-end and front-end. The issue often happens during refinement sessions. After explaining the problem and adapting the acceptance criteria, a developer asks, “Can we split it into back-end and front-end?” Then, I answer, “Can the user use only the front-end or back-end part of it?” I am more than tired of this.
It’s gone the time when everyone does their part in software development. Now, everyone is accountable for the whole. Discussions about splitting the stories into technical boundaries do not create value for the users.
Developers are self-managing, and they should be able to organize their work and collaborate to solve problems as a team. Segmenting the work also ensures a segmented responsibility.
User Stories can and should be divided into smaller items to deliver value sooner. However, be careful how you split them. Take a cake as an example; you cut it vertically and not horizontally; each piece has everything you need to enjoy. The same should be with User Stories; it should contain everything needed to create value.
3 — Refactoring Obsession
I know code needs maintenance to remain scalable and maintainable. This is natural. However, not everything needs maintenance all the time. What surprises me is an obsession with refactoring. Something annoys developers, and immediately they want to refactor it. The question is, when does it make sense to refactor and not?
It’s not because you have a problem that you must fix it immediately. Before deciding upon a refactor, I like asking the following questions:
What happens if we leave it like it is?
What would be the benefit of refactoring it?
What are the side effects consequence we may have?
How long do you think it is needed to finish?
These questions are not meant to block developers but to reflect on whether refactoring will pay off. As with everything in life, balance is essential.
Great developers know when it makes sense to refactor and when not.
I don’t like worrying about a problem I don’t have. Refactoring everything ahead of you is like avoiding all problems you may not even have. This is a risk-averse attitude, and to deliver the value, we need to take risks and learn as fast as possible.
4 — Cutting Corners
When the pressure comes, what’s the first thing to cut? Unfortunately, quality is the first to suffer if developers feel pressured. However, once stakeholders get used to receiving more, they won’t accept less. What will happen then? Developers become trapped.
Cutting quality processes is unsustainable and will inevitably lead to major consequences. I’ve lived that already several times. My suggestion is to set a minimum standard of quality, and do not accept going under that bar, and preferably this bar should already be quite high.
Let me share some things that work once or another time but it can put developers in tough situations:
From local environment to production: it speeds things up and creates a major unneeded risk.
Execute scripts directly in the production environment: if you love strong emotions, just do it.
Skip test process: no unit test, no automated test, and life of fixing bugs.
5 — Lack of Transparency
In many situations, developers are imprisoned by a poor Scrum implementation or whatever framework they use. Developers may get tired and start doing things independently without communicating with other team members. Unfortunately, that only leads to bad results, frustration, lack of commitment, among many others.
Lack of transparency is a perfect choice for unpleasant surprises.
Let me come back to the refactoring topic. Once a developer asked me to refactor a code for our invoicing process. I asked him why he perceived that as important, and he told me the code looked terrible. I was the Product Manager, and his answer didn’t convince me, but I shared my perspective by saying, “This process has been up and running for a year now. It never presented a problem, and we have no plan of changing it or implementing new features. I don’t see why a to refactor is beneficial for us.” The developer only said, “OK.” I should have known he didn’t accept my explanation.
After this exchange with the developer, he started being unproductive. I talked to him, and he said everything was fine. Four weeks passed by, and one day I arrived at work, and there was an e-mail from an accountant, “David, please look at our invoices asap. The VAT is incorrect everywhere.”
At that moment, I didn’t connect the dots. I talked to the team and said we would have to solve this issue. A couple of minutes later, a developer came to me and said, “There are tons of changes in this process. It went live yesterday without QA.” That moment I connected the dots, the developer didn’t accept my answer and refactored the code on his own.
To summarize this story, the whole team had to work for three days until late to fix a problem we didn’t have. Transparency is vital for collaboration.
Final Thoughts
I am a developer by heart, and the reason I became a Product Manager was to ensure developers would be empowered to create value. I believe developers can create more value they put their energy into the right things. Here are the attitudes I believe to be helpful:
First comes the problem, then the solution.
Quality shouldn’t be negotiable.
Worrying about an inexistent problem causes more trouble than helping.
Collaboration is more critical than segmenting work.
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊