Imagine you’re testing a system that has a long startup time, and you find a small change that needs to be made. Now you have to make the software change, rebuild the executable, shut down the application, deploy the new executable, and go through the long startup period again. What a waste of time! Wouldn’t it be great if you could avoid having to stop and restart the entire application? It would be like refueling in flight. Well, now you can.
In my last post I talked about how software has both a primary and secondary value, and how this idea relates to complexity within the framework of Scrum. I want to take a deeper dive into the ideas of complexity and simplicity in order to establish a common vocabulary that I can use in future posts (and hopefully to spur on a discussion with you, from which we will all gain a better understanding).