![Lead Image © leeavison, 123RF.com Lead Image © leeavison, 123RF.com](/var/ezflow_site/storage/images/media/images/leeavison_123rf_superhero_kid_s/144972-1-eng-US/leeavison_123RF_Superhero_kid_s_medium.png)
Lead Image © leeavison, 123RF.com
Common DevOps Mistakes
Every Ready
Special Thanks: This article was made possible by support from Linux Professional Institute
The world of software development is built on a foundation of two awkward metaphors. First, there’s building construction, in which software has “architects” that help with the “blueprint” of the code and then turn it over to the software developers who “build” it. The second metaphor is complex manufacturing, wherein software development has highly specialized phases that work in a conceptual pipeline [1]. Designers design and then hand it off to developers who develop, who then hand it off to testers who test.
It turns out, though, that these are pretty poor metaphors for creating software. Understandably, early software developers would rely on parallels to known professions, but in reality, that doesn’t work very well.
Software development doesn’t operate like the construction industry. Buildings require tons of upfront planning, because not much can really be changed once you’ve laid the foundation. However, that’s not true at all for software. Also, software development is knowledge work [2] and doesn’t look like manufacturing, because you can’t break it down into simple, repetitive tasks to be executed by low-skill assembly line workers.
Some of the most important sea changes in software have taken aim at these metaphors: take the agile software development movement [3], for instance. It took aim at excessive formalism, process, and heavy upfront planning, all characteristics of the construction industry and complex assembly lines. Instead of putting more and more effort into planning and locking plans into place, why not concede the inevitability of change and get good at responding to
...