4 Patterns in Software Development Projects Which Lead to Failure

With experience, you can recognize the less obvious patterns which lead to costly disasters.

Gaining experience in a career makes you better at recognizing patterns. This is a significant part of the value an experienced employee brings to the table. You see the information presented on a project, in an email, from an employee, and say "Oh, I've seen this before! I recognize what's about to take place."

Some patterns indicate positive future outcomes. You can recognize the signs of a future excellent employee from an interview candidate. You can see a cleanly coded feature which is likely to work the first time. You can see strong communication skills from a well worded email.

From a recent college hire's email to their team:

Hey all - I was taking a look at our sprint board today, and I see a number of in-progress tasks which haven't had any updates in over a week. I hope you don't all mind, but I've taken the liberty of moving every task without an update into a new parking lot status. I scheduled a meeting this afternoon to review the parking lot tasks. I think it'll be hard for us to know our progress this sprint without getting clarity on the status of all our open tasks.

I can look at that type of email and recognize the courage, passion, high standards, and empathy wrapped up in a small statement, and immediately feel like I should lean in on this hire. I have seen other new hires like this before, and they were highly valuable.

Other times patterns can suggest future problems. Some of these patterns are obvious, and some are more subtle. I wanted to go over four of the subtle ones.

1. The Big Bang Launch will make things easier

Sometimes a core piece of infrastructure needs to change. Sometimes a core technology needs to be updated. Sometimes your entire UI needs a redesign. A big bang launch is one in which a large set of code and features are dropped at once, rather than being slowly rolled out in small chunks.

The engineering team suggests that the change would be easier to make if it was all written and deployed at once, rather than piecemeal. The marketing team is encouraging the big drop, as they believe a large launch will be more dramatic for customers.

I'll jump to the punch line - it is almost never a good idea to do a big bang launch. Almost every single time I have observed the big launch path chosen, it was later flagged as a mistake.

Why big launches are a bad idea:

1. You learn from deploying code to customers. Keeping code away from customers means you have missed learning. You have written more code without learning from your previously written code. Therefore, you now have more potentially wrong code.

2. Mistakes are more impactful. Updating a single webpage has limited impact. Updating an entire website has larger impact. Any mistake is compounded by the size of the launch.

3. Value is held back. If you believe there is value in what you're delivering, you're holding that value back from customers. You can receive value from your spent effort by launching portions as they're built.

4. Delays are larger. If your 1 week project is delayed, you might slip by 2 days. If your 1 year project is delayed, you might slip by 3 months. Larger projects means more variability in delivery times.