日本人 versus 中国人 cage match
There’s a famous pair of pictures found on a blog post at The Atlantic‘s web site. The first of the pictures shows refuelling operations at a Japanese airport:
The second shows refuelling operations on the same aircraft at a Chinese airport:
Both of these approaches are also reflective, in my opinion, of philosophical approaches to software development which I will call the 日本人 approach and the 中国人 approach respectively. (I will also refer to these approaches as “Order” and “Entropy” for reasons which will become clear at the end.) It is my considered opinion that both approaches, incidentally, are utter bollocks and create shit software.
Why the 日本人 approach sucks
Look again at the picture of the Japanese refuelling operation. Every little detail is accounted for. The two workers are wearing coordinated outfits right down to the bloody shoelaces for crying out loud! Surely they must have a well-thought-out system that is a marvel of efficiency, safety and effectiveness!
Well, no, actually. I mean I don’t know about aircraft refuelling, but I do know that in software a focus on fine-grained process that monitors every little detail of the creation of software is damaging to the outcome. Brooks noticed this too over 35 years ago. The statistic he cited was that 75% of software projects are deemed failures by the people making it. (I’d wager that the percentage is closer to the Chambers Constant—99.44%—if you were to ask the users of the software.)
There’s no end of methodologies for software development out there and every single one of them (even, perhaps especially, the ones that claim to free the developers!) lose the big picture in favour of a never-ending plethora of ever-irrelevant details.
I’m sure anybody who’s ever coded in an enterprise environment has seen the software equivalent of colour-coordinated shoelaces. (Mine was being told I wasn’t allowed to use Python scripts to generate my boilerplate code because not everybody in the company knew Python. Note that this was a code generator I wrote for my own use that was not part of the build process in any way, shape or form…) I’m also sure that such people will admit, grudgingly or openly, that the software quality wasn’t appreciably improved, but the quality of the workplace was noticeably degraded.
So it’s the 中国人 approach
Not so fast. Coding anything non-trivial is hard work and it’s complicated. Human beings are limited in their cognitive capabilities and, as a result, we suck at complexity. This is why we make teams for things. And once we have teams we have a need for constancy, regularity, communication and all the other things coders suck at. I’ve worked in shops that had, for all practical purposes, no controls and the results were easily as ludicrous as—sometimes worse than—the shops that had B&D-style processes.
The problem, in the end, is that cowboy coding is like that guy in the second photo. Sure you may metaphorically get the plane fuelled, but you’re getting a metaphorical mouthful of avgas in the process. If you’re lucky. If you’re unlucky you’ve got burning fuel spilled all over you instead.
Cowboy coders produce shit. It’s often inspired shit, but it’s shit nonetheless (in terms of reliability, expandability, utility, etc.). I submit the aforementioned Chambers Constant of projects at SourceForge and Github as my evidence of this.
So the solution is…
You think if I had the solution I’d be writing a blog about it? Fuck no! I’d be making millions fixing the software world and letting computers finally live up to their potential! I have no answers, but I do have an idea what the answer would look like.
I like the works of Michael Moorcock. (Yes, this was a jarring segue. Deliberately so. Suck it up.) While he’s weak at plotting and his characterization can be charitably termed weak, his strengths outweigh these weaknesses enough that I’m a fan.
One of the concepts I’m a fan of is his cosmology of the eternal struggle between Order/Law and Entropy/Chaos. In Moorcock’s writings too much order is as bad as too much disorder. Excessive Law results in tyranny and stagnation. Too much Chaos results in continual destruction. The solution in Moorcock’s world view is a metaphysical “Cosmic Balance” that keeps the two opposing forces in check.
We need some kind of software development balance to allow us to combat the creeping control freaks behind things like the Booch method or its ilk whilst at the same time not having our software fall into the more typical anarchy that is the norm in projects (despite the increasing clamps placed on the work by management). When a business leans too much toward process, it needs a boot back to the middle. When it leans too much toward cowboy coding, someone needs to rein in the cowboys and crack the whip a little.
And we need an instance of the Eternal Champion in every software shop to boot things around until balance is finally achieved.