I’ve been developing, managing, and selling custom software solutions for nearly 20 years. During that time, I’ve worked in various business domains and technologies with each combination providing its own unique set of challenges. Throughout my experience, I have observed that there are a set of cross-cutting truths that apply to all software projects.
I’ve been calling these consistent observations “truths” because I’ve yet to find a project that they don’t apply to. I’m sharing my set of three truths of software projects because they are simple but powerful aspects to keep in mind when building, managing, or buying software.
Truth #1: If it’s good, it’s never done.
Successful software is never done. There is always room to implement new features, provide support, or seek new markets to bring the software to. Money is commonly the bottleneck, not good ideas. Embracing this truth helps reframe how you think about the software product and feature set. It’s why you should release early and often and look to get value from your product as quickly as possible.
This truth is also good to keep in mind when building your product team and how you think about investment and the returns.
Truth #2: You’ll know more tomorrow.
This truth is true for every creative endeavor. You’ll know more tomorrow about the product, technology, client, etc. than you know today. And, that knowledge will improve every subsequent day.
This truth implies that your software projects should prioritize good planning, but not too much planning. Some of your plans will inevitably need to change. You’ll want to make sure you’re using a process that’s both adaptable and robust so that it can accommodate the changes that will happen.
Respecting this truth involves being able to defer major decisions as long as you responsibly can.
Truth #3: If you want to go fast, increase the quality.
This truth is the paradox of custom software. In my experience, the only way to design and build software faster is to increase quality.
The following graph demonstrates what I’ve observed.
Initially, reducing quality allows design and development teams to produce more output over less time. However, there is always an inflection point. I’ve noticed that this inflection point happens when an application grows to a size that is too large for a single developer to know all the side effects that a product change will cause. At that point, the rate of functionality delivered quickly reduces and eventually levels out. Each subsequent new feature leads to a series of application bugs that manifest throughout the entire system.
This is why some teams will choose to build quick and dirty prototypes that need to be thrown away and rewritten using quality practices after they’ve served their purpose.
It’s not uncommon for a design and development team to seemingly start slow. They do this to set the foundation for quality. That foundation commonly includes a solid user experience, automated testing suites, and a thoughtful architecture and technology choice that’s set up to correctly model the business domain.
Starting with quality from the beginning enables teams to go fast in the long run. When starting a new project, it’s good to keep in mind both this truth and truth #1: If it’s good, it’s never done.
Understanding and honoring these powerful truths leads to better long-term outcomes and more successful software projects.
As with costs, software development takes time and no amount of Agile or scrapping will change that fact. In my experience, many business leaders either create incentives or fixate on processes in the name of “speed.”