10 Keys to Successful SW Dev: #9 Respect the Process

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Software Development is difficult to get right. According to the latest figures, only 32% of software development projects are successful, and 43% of the features developed are not used. We’ve been successfully developing software for over 10 years, and have put together a list of 10 successful patterns (what works) and anti-patterns (what doesn’t) based on this experience.

The first installment covered #10, Tools and Infrastructure.

#9 on the list is Respect the Process.

As a custom software development company, most of our projects involve building new software that no one has built before. There are many things that are being done for the first time. Having a repeatable method is essential to making this less risky, and having the right one is critical.

In our case it’s a method that’s evolved out of agile and user experience design best practices and includes lightweight, just in time requirements gathering and design, test-driven development, pairing, daily scrums, weekly demos, two-week development iterations, agile estimation and velocity measurement. It encourages releasing early and often in order to get real user feedback, which we use to guide further development.

By having steps and procedures that are reproducible and reusable, we reduce unnecessary risks, waste, and churn. It’s easier to get a realistic picture of the project and the resources committed to it, and to make go or no-go decisions. It’s easier to add people and start up new projects. And it’s easier to adjust a project to fit changing circumstances.

The trick is in keeping the right balance of process and visibility while not getting in the way of progress.

There are two anti-patterns to this that we see, especially when we are doing project rescue:

Cowboy Development

The first is “Cowboy” development. No method, no best practices, no documentation, just coding as fast as your fingers can type. It’s cheap and fast for little one-off tasks, but for anything larger, or anything that uses many of these little one-offs, you end up with a buggy, convoluted, low performing mess, a support nightmare, and a straight jacket for new development.

The Wrong Process

The second is having the wrong process for your project. We see this most often when we run into waterfall methodologies for custom software development. Waterfall is a useful methodology when requirements are well understood and immutable, but for software development, this is rarely the case. Spending 3 months on requirements, followed by six months of development, 3 months of testing, and another six months of dealing with change requests and feature rework is not a recipe for success in our industry. Very often, a method that’s too heavy weight and not adapted to the nature of the project ends up getting abandoned or worked around. In which case you end up with Cowboy Development anyway.

Related Services: Custom Software Development