Reader story: Unraveling the Code Mess“To my surprise, most of the team was quite motivated to improve things but they didn't really know how.”
In response to my recent post about the lack of confidence inherent in a manually-verified software development worfklow, I got a response from fellow daily email subscriber Marcelo, which really resonated with me, and I expect will with many of you as well. I especially like how the core problem that was identified was expressly a lack of know-how, not laziness or ill intention.
I’m sharing it here with permission (edited slightly for clarity):
Hey Jonathan, how is it going?
I really like your daily email. I never replied before but this one felt quite familiar.
My most recent experience:
I actually was in this situation when I joined my current team. Lots of legacy messy code with nearly no tests done by developers, and a QA testing team doing the full testing part. Lots of bad decisions IMO that ultimately were leading to delays, lot of defects, code rotting every second a bit more, relationships a bit damaged cause of the friction between the devs and QA testing, etc.
After a few weeks of assessment on how and why the situation was like this, I started conversations to try to improve the main pain point, which was having a separate testing team and not letting developers care about quality.
To my surprise, most of the team was quite motivated to improve things but they didn’t really know how.
So the first thing I did was pushing a lot for unit testing and get rid of most of the e2e tests we had.
I run a couple of workshops for my team and others and it really caught up, so in a few months we had way more testing and less tangled messy code. We also started to have way fewer defects. The situation improved a lot. Slowly turning the tide.
Something really interesting was that all this mess was not like that “on purpose” or out of laziness. They just didn’t know how to do better. It was cool to see that if you take the right motivated people and learn and experiment all together you can improve things really fast.
Having said that, there were some developers that IMO were not competent, and apart from that they were arrogant and no matter how much experiences and past stories you show them they will not change their mind. Unfortunately, one of this guys was the tech lead of the team (I think that’s why things were in such a bad shape to begin with). After many, many energy consuming talks, he went to another team and it was much easier after that.
A few quick take aways that I could get:
- No matter how motivated and hard-working developers are, if they lack the competence and (self) direction, all that motivation and hard work goes to waste.
- No matter how much knowledge and past real stories you bring to the table, there are some who just won’t get onboard. Not really sure how to deal with this. In this particular situation it was painful and really tiring.
- No matter how much some members of the team want to change things for better, if the whole team is not aligned then it’s really hard to make impactful and long-lasting improvements.
In short, understand what and why that happened, try to get people on board, the self-motivated people are your stronger allies here, try to level them up(courses, workshops, learning session, etc). Try to outline some practical and achievable solutions. And a lot of patience and medium/long-term investment. That worked this time.
Hope you have a nice day! Marcelo
Thanks a lot for sharing, Marcelo!
And here’s a reminder that I love to hear from my readers. What stories or frustrations can you share? (I’ll only share them publicly with your express permission.)
Reader response: The downward spiral of manual acceptance testing
Lack of unit testing drives the need for manual testing. Since testing is bunched up, development is as well.
Which skill is more important: Testing, or debugging?
One of these skills, if you're good at it, diminishes the need for the other other.
Improve your software delivery