Wait Makes Waste
CindyVanEpps 120000EA06 Visits (2178)
“You’ll eat it and you’ll like it!” my Grandma Stowell used to say. Its not that she was a food tyrant but rather that she had spent all day in the kitchen preparing a meal.
Now I can go to a restaurant, place an order and be served within 20 minutes or so. The testing and feedback on the product I receive happens immediately. If I determine that it is so delicious I must have more, or that I have capacity for dessert (as if dessert has any pre-conditions!), I can receive more product in the same dining event.
Through streamlined processes and technology, I can drive up to a window, place a food order, and receive it within minutes. Usually I get exactly what I want and am happily on my way. But on the rare occasion something goes awry – for instance, if I protest the size or warmth of my chicken nuggets; I can get my order replaced in under 30 seconds while I wait.
Whether I am at a fast food restaurant or a diner, I don’t really care if the preparers are the same as the servers. I really care that I get my requirements met quickly and that the product is acceptable quality. If I need to adjust the order based on missed expectations, I expect to do that also in an acceptable time frame.
DevOps is the PrepServe of software delivery.
The old adage “haste makes waste” is based on the principle that making a mistake requires a costly return to the beginning of the work because of loss of large blocks of time required to accomplish the work and the loss of resources wasted in starting over.
Consider how technology has advanced the software delivery world. We have the ability to collaborate to specify and understand requirements, even with time zone challenges, in days rather than months. Delivering in smaller increments of capabilities not only gets capability in the hands of the users faster (the pot o’ gold of agile methods) and it also greatly reduces the time it takes to isolate the cause of a defect. Automated testing ensures that tests can be run more often and test results are collated and reported in hours and minutes rather than days and weeks. Virtualized services reduce the cost of complex test environments from millions of dollars down to hundreds. Capturing infrastructure as code ensures that development and test environments are “production-like” to reduce the risk of error resulting from environment inconsistencies.
With software delivery, wait makes waste. In the time it takes to develop a large system, the players change. The business analyst who is assigned to user acceptance test your product 1 year after someone else specified the business requirements likely will not understand the original intent. Technology changes: the architectural constraints as well as the business analysts’ technology frame of reference that impacted the original requirements are likely far different. Business drivers change: competitors advance their products and approaches. Resources change: this year’s budget cycle may not provide the developers, enablement program, or infrastructure that your large system change requires.
A most poignant example of wait makes waste happened when I worked in software development for Space Shuttle Mission Control at Johnson Space Center, NASA. We were collecting the requirements to procure the first set of distributed systems' hardware to start migrating Space Shuttle Flight Design off the mainframe. In order to ensure a low cost solution, the NASA executive sponsor explicitly captured the requirement that the monitors in the new system would be black and white displays. At the time, color monitors were bleeding edge technology. During the many months of the request, bid, and award to vendor process, the chosen vendor had advanced their technology so that color monitors were their primary product. We actually paid the vendor to downgrade the capability in their primary product to meet the specific requirement! Needless to say, I was disappointed both as a system user and as a tax payer.
“You’ll eat it and you’ll like it!”
It is an extreme example, but certainly represents the paradigm for delivery of business value in software that many business users have come to expect as their reality: belabored and detailed processes that in the name of “haste makes waste” cannot be streamlined. I provide the food acquisition examples to encourage that there is a better way. DevOps provides fast service and an immediate feedback loop but those are really the means to the end – customer satisfaction. And for business users dependent on software systems, their satisfaction is delivered as functionally appropriate, secure, available, responsive and easy-to-use systems. Can you biggie size that for me, please?