Let's say I'm a business owner. I've just invested a significant amount of capital to build a software platform that will automate some processes, build business intelligence, and enhance employee efficiency.
How long do I have before that software will need to be fixed? Or, how long can the software endure before it requires expenditure again?
As engineers, we look at software in a mathematical sense: done equals all features complete and no more bugs. As we build test suites to prove software functionality, we’re more and more confident that we are approaching that goal.
Some years ago, a client who liked to ask, "When will it be done?" The question wasn’t about a specific feature or short-term goal. Instead, the question was more concerned with when the software would stop costing money.
Fundamentally, a disconnect exists between the engineers and the stakeholders when someone asks if something is done. One will say, "It will never be done!" And the other, "It has to be done sometime, or it doesn't make sense to keep putting money into it."
Breaking the logjam requires an understanding between the stakeholders and the engineers as to what done means. This involves clearly defining features and their priority, using a QA cycle, and contingency planning for undiscovered bugs.
Features vs Bugs
First, separate the features from the potential bugs.
We define software functionality positively by listing the features of what it must do. Given the development timeline, resources, and budget, we can also list the nice-to-haves.
Estimates are not guarantees, but eliminating the "unknown bugs" part of the equation will provide a firm foundation for engineering and accounting and clearly define goals to accomplish.
Quality Assurance
What quality assurance cycle will the client pursue to prove the software is ready?
QA will discover and classify bugs in the solution and establish a confidence level in the solution's readiness.
The extent of that confidence is directly related to the resources placed to build it. The larger or more complex the platform, the harder that confidence is to prove. In other words, a one-person QA team on a massive platform will not build much confidence.
Ideally, QA is accomplished by non-developer resources who will use the software with a developer's mind.
Contingency Plans
A humble software engineer will always acknowledge that there could be more bugs - whether those undiscovered in the project or those existing in software and library dependencies.
While bugs can be discovered/fixed before features are "done", the reality of software is that bugs can raise their ugly heads at any time.
Some of these will be incidental, meaning they can be worked around without a huge hit to productivity. Others will be showstoppers, halting the use of the platform until something is done.
If QA has happened well and the solution has a solid test suite, showstoppers shouldn't happen. Or, if they do, they may be related to other, underlying code or infrastructure.
Either way, there needs to be an understanding of the potential cost. On the one hand, if a showstopper happens, productivity is lost, therefore revenue is lost. Balance that with the cost to resolve the issue, and fixing the problem is often the right thing to do.
Done means Done
Aligning stakeholders and engineers on what “done” means for software requires a clear understanding of features, the QA process, and the reality of later bugs in software.
As long as there is an agreement on what "done" means and doesn't mean, the reality of unexpected bugs does not have to be a potential issue down the road.
Documenting and prioritizing the software’s features helps. QA and the test suite can build collective confidence above the threshold that meets "done."
Once the project is “done,” changes and fixes that come up later will enhance the solution’s value even further.