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.
Follow me on Twitter
Follow me on Blue Sky
Could you please elaborate on what the “smallest bit that would possibly work” approach is? What’s the “smallest bit”, in this regard? How does taking that approach help you overcome a lack of perspective?
I notice this in a few implementations when consultants ignore basically everything about the legacy package with the mindset that our thing is newer so it is naturally better because these best practices we have ensure that it will work. But at the end of the day the consultants are simply hiding behind other people’s work – hoping that if they hide long enough the project will miraculously meet its targets. Its definately a lack of domain expertise and time.
Sure thing. We ended up seeing success when we started building an end-to-end flow for just one use case. In our case, it was the ability to buy just one product that we’d migrated over. We discussed ways to ship that, but even just the hoops we jumped through to display one product gave everyone a firm grasp of what we were trying to do, and crystallized decisions to be made. Hope that helps.