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.
