There is an old saying: software can have quality, features or be on time. Pick two.
Those three factors – features, time, and money – define the software development process. Features are the definitive characteristic – that defines the battleground, defines the product. Think of your smartphone. If it didn’t make calls, or play mp3s, or send texts, would you have bought it? Features are the product.
So, what’s quality? To get software that works right every time and doesn’t send that eighty-billion dollar space ship into the fifth submatrix band and thus into oblivion requires reliability and resiliency. We’ll focus on reliability, or this will be a very long post. To get reliability, you need to ensure correctness of the code. That’s what we call quality: ensuring that things are done right. Usually that requires a fair amount of testing.
Quality in this case is indeed time multiplied by money. In testing, you can cheat a little on time, but only by spending more dollars/yen/yuan, whatever. For an example, imagine you’ve designed a system with three parts: a controller application that visualizes the systems for the human, takes rules for operations, and coordinates all the parts of your ship; a storage part, that stores all the data, makes sure it can be found and processed effectively; and a dispatch system, which takes the instructions from the controller and actuates the physical components that do the flying. Like your hyper-drive, or solar panels.
To test all of this you need to hold some variables constant on the other two modules while you exercise the component under test. So, to test the controller, you need the storage and a mockup or simulator of the actuator modules set to some known state. Then you can run the tests on the controller, and check the results: for a known state of the dependent modules, the inputs you give the module under test should result in predictable outputs. For example, if my storage module is telling me we have a shortage of oxygen, rules in the controller should prevent someone from actuating the airlock (and thus venting some of our precious O2).
If you have one working example of each component in your lab, you can test all three components serially: you hold some data constant in the two modules not tested, and run exercises on the module under test. But let’s say you are running out of time (more on that in the next post). To test all three of these systems at the same time (saving time) you will have to throw three times the amount of dollars in test resources at the problem – three times the test engineers, three complete test rigs, three times the facility, power, cooling. If you have five modules, you’re taking five times the cost to test in parallel. That is expensive.
Thus, my contention, you need a monopoly to get the level of quality needed not to trash a bunch of colonists and their big arkship. Only a monopoly has the time (and the money) to get the job done right. Why? Next post…