When Bad is Good

A thought on a dreary Friday. There are two types of software projects - those that go well and those that do not. Typically, we think of those projects that go well as successful, and those that go poorly as failed. But it’s not quite that simple. What matters most is the point at which things go poorly and the point at which things are going well.

I’ve been on projects where we have lots of parties to celebrate our success. We’ve signed off on requirements. Throw a party. We’ve just passed our architectural review. Another party. We’ve just completed coding and testing commences next week. After that, we’re going to demo the system to out customer. Party again. At this point, we might be six, nine, or twelve months into the project.

I’ve been on other projects where we spend a lot of time developing infrastructure code early, and continuously troubleshoot complex problems. We host frequent customer demonstrations, and receive a lot of feedback - not all of it entirely positive. We fight through tough integration challenges, feel like we’re constantly revamping the user interface, and the build fails a few times a week. Testing occurs frequently and is always turning up bugs. There aren’t any parties, and it’s a lot of work. People grow frustrated at times, and friction between team members needs to be carefully monitored. This might go on for six, nine, or twelve months.

I’ve found projects that experience significant challenges early often go one of two ways. They either get canceled early or wind up delivering some pretty good software. These are good things. Projects that get cancelled early save an organization from making a significant investment in a project that’s going to fail. Win fast. Fail fast. And move on!

Ideally, of course, the project wouldn’t get cancelled and the team would go on to deliver a great piece of software. Even in this situation, the team has fought through significant issues early in the lifecycle, and eventually they discover their rhythm. Development starts to click and progresses at a relatively sustainable pace with few late surprises.

On the other hand, projects that seem to be running smoothly early typically experience significant issues late in the software lifecycle because they’ve delayed attacking high risk items. This is a worst case scenario. We’ve now made huge investment and have crappy software.

All in all, this is one of the most significant benefits of agile practices. They encourage us to write code early, ensure the system is always functional, share the system with users, and a whole lot more. In general, this mitigates a lot of serious risk that goes unnoticed on projects that delay these activities until late in the lifecycle. And it allows us to continuously evaluate the project and determine if it’s wise to proceed or allocate resources differently. In the end, our customers aren’t going to remember how well the project was going six months ago. What they are going to remember is if we were able to deliver a great piece of software.

Comments