When Software Projects Go Wrong

Before Drive Current embraced developing in teams and agile methodologies, we worked on a project for a large non-profit organization. We had a single developer on the job who churned out code and over the course of six years built a very sophisticated application. He didn’t have a lot of support, just a few hours of UX design once in a while. Not much product management. No formal QA.

We didn’t run two-week sprints ending with a presentation of new functionality. Instead, our lone wolf programmer coded for months and then demo’d a giant feature in multi-hour calls. The feedback would often result in significant restructuring. This resulted in coding to accommodate extreme flexibility.  Which ultimately meant quite a bit of gold-plating.

There was no automated testing infrastructure so when seemingly small requests or bugs were submitted, the change would often be agonizing as we worried what else might break. Frustration mounted when the customer asked for seemingly simple changes, but often had to wait for weeks. In the end, after six years on the project, our programmer announced he was burned out and couldn’t continue.

That was a hard blow, particularly because there was zero code coverage; no one else knew how the software worked. It had evolved with the input of 20 different stakeholders (various state agencies, universities and non-profits) and after digging into the code, the decision was made to rebuild it from the ground up. That the customer made the decision to throw away six years of code was pretty shocking and humbling for me.

Thinking back to the beginning of the project there were so many different decisions that led us to that point. Of course it wasn’t a total loss. Building Version 1.0 gave the varied stakeholders an opportunity to really understand what they needed. Together we took the service to beta and got end-user feedback. The customer learned lessons that you only get trying to support real users.

I learned as well. Here are a few takeaways from what could be called Drive Current’s most spectacular failure:

• The biggest mistake was probably having the customer talking directly to the developer. He tried his best to accommodate all requests and rarely pushed back. A Product Owner vetting the importance of each request and prioritizing a backlog would have been invaluable.
• There were no sprints. It’s so obvious that regular feedback is critical. It’s amazing we didn’t get that once upon a time.
• A related take-away is that its hard for most people to pay attention during four hours of demos and discussion. A bite sized presentation with a handful of features will yield clear, focused suggestions. Marathon meetings often yield pages of notes with conflicting ideas.
• If you look at our overall effort – 98% was development. We should have coded less and communicated and planned more. Even if the budget only called for one employee, perhaps only 70% of the allotted development hours should have been used and the rest spent in other areas.
• The temptation to ditch automated testing must be resisted at all costs.
• Developers work best with feedback and support. Working in isolation without constructive conflict and a variety of ideas is not ideal.

I’ve recently found myself in a similar situation on a project.  It’s tough when technology ambitions outstrip budgets. So writing this post was a good exercise to reinforce lessons learned…