When you’ve worked in software for as long as I have, you have made mistakes. I’m going to catalog some here intermittently so I can analyze them and hopefully avoid them in the future. I may change identifying details or use vague descriptions.
When you interact with a client, especially if they are knowledgeable about their domain, it can be hard to come in and seize the reins. You want to be respectful of what they know and what you don’t. But at the same time, they hired you for what you know, and sometimes you have to stop hurrying forward and take a look around, especially if the project is not running smoothly. This is a story about a time when I didn’t seize the reins, and the problems that followed.
I was working on a long running project for a client. It was a bear of a project, with a ton of domain knowledge and some complicated partially done software. The team working for the client churned, including employees and consultants. When I was brought on, I didn’t have a full picture of the problem space and it felt like we didn’t have time to gather it. No one had this global view. Meetings with the client would often go down rabbit holes and into the weeds. The project was a rewrite and the system we were targeting to replace kept evolving. This original software system powered the business and yet didn’t operate with normal software development practices like version control. When looking at the code, it was unclear what code was being used and what was not.
But most importantly, other than diagrams and meetings, we didn’t deliver anything of value regularly to the client. We would spin in circles trying to understand previous work and take a long time to make small changes. We did write a testable new system and follow other SDLC best practices including version control, CI/CD and deployment environments.
This project finally started to turn around when we shifted from trying to replace the entire running system to replacing the smallest part that could possibly work end to end. This gave the team a clear vision, and showed the client a path to business value. We accomplished more in a couple weeks with this perspective than we had in the previous couple of months. This also let us commit to a real project plan and timeline. Unfortunately, the client wasn’t happy about the projected and past expense, and shut down the project weeks after the development team was starting to show traction.
Lesson: I wish we would have had taken the “smallest bit that would possibly work” approach from the very beginning. I wish I’d had the insight to call a halt and not continue down a path that was clearly not working a few weeks after observing it, not a few months.