In many fields of life, standards and regulations are a good thing. Standards are why you can get into a new car and be comfortable driving it; without standard steering wheels and brake pedals, no one would be able to drive a rental car. Software is different. The misguided effort to impose standards and regulations on software development has played a key role in the nonstop cybersecurity disasters and software failures that most organizations try to minimize and ignore.
Do software standards and regulations literally cause software and cybersecurity disasters? Yes, in much the same way as looking at your cell phone while driving causes auto accidents. Everyone agrees that distracted driving is bad, but somehow distracted programming is ignored. It’s a classic case of ignorance and good intentions that have horrible unintended consequences. Seeing the bad consequences, the community of standards writers believes the problem is that their standards aren’t deep, broad and detailed enough -- let's distract the programmers even more!
Software and Bicycles
Suppose that writing a software program were like riding a bicycle, and that finishing writing the program was like reaching your destination on the bicycle.
Even if you're not a bike rider, you’ve likely seen lots of bikes being ridden. You've probably seen kids learning on training wheels:
(Image)
Kids eventually learn to balance and learn how to handle curves, hills and the rest. Then there are serious riders whose bodies are tuned to the task. They ride with focus and concentration, assuring that they handle every detail of the road they're on to maximum advantage.
(Image)
Because people who create standards and regulations on software are appallingly ignorant of creating code with maximum speed and quality, they impose all sorts of strange requirements on programmers. It's as though the bicycles were invisible to everyone but the programmers, but the leaders have it on best authority that the bicycles they demand their programmers use are up to the most modern standards.
(Image)
They create increasingly elaborate processes and methods that are supposed to assure that bicycles reach their destinations quickly and safely, but in fact assure the opposite. The programmers are required to juggle a myriad of meetings, planning discussions, reviews and other activities while still making great progress.
(Image)
The oh-so-careful regulators go to great lengths to assure that at each stage of the bicycle’s journey the rider does his riding flawlessly and without so much as a swerve from the proscribed path. When developers are forced to follow regulations and standards, they don’t just pedal, quickly and smoothly, to the finish line. They constantly stop and engage in myriad non-programming activities. No sooner do they start to pick up speed after being allowed back on the bike than ring! ring! It's time for the security review meeting!
Riding a bicycle competitively is not the most intellectual of activities. Neither is being a batter in baseball. But both require exquisitely deep focus and concentration. The batter's head can't be swimming with advice about what to do when the pitch is a sinker; the batter has to be present in the moment and respond to the pitch in real time with the evolving information he gets as the pitch approaches the plate.
In the same way and arguably even more so, the programmer has to be immersed in the invisible evolving "world" of the software around him, seeing what should to added or changed to what, where in that world. The total immersion in that world isn't something that can be flicked on with a switch -- though it can be brought crashing down in an instant by an interruption. In the same way, a biker doesn't get to maximum speed and focus in seconds. It takes time to sink in to the flow.
Meanwhile, all the managers judge programmers primarily by how well they juggle, like the skilled fellow in the picture above, blissfully unaware and seemingly uncaring that the unicycle is better for stopping, starting and going in circles than it is for making forward progress.
Conclusion
This is the ABP (Anything But Programming) factor in software -- make sure the programmers spend their time and energy on things other than driving the program to its working, useful, high-quality goal. The managers feel great about themselves. They are following the latest standards, complying with all the regulations, and assuring that the programmers under their charge are doing exactly and only the right thing -- doing it right the first time. When such managers get together with their peers, they exchange notes about which aspects of the thousands and thousands of pages of standards they have forced their programmers to distract themselves with recently. Because that's what modern software managers do.
Comments