How to paint your door

Imagine if building and maintaining your house suffered from the same amount of bureaucracy as software development. Then imagine trying to paint the door to your house.

Before you could even start discussing paint, you’d have to hire 5 lawyers. These lawyers would spend three months writing a piece of paper that all participants had to sign, which said “I will not reveal any details about the coloring of this door.” Then you’d have to hire a Chief Door Officer, a Head of Door Painting Chief, a Human Resource Door-Painting Director to supervise that nobody got hurt in the process, a Door-Painting Risk Assessment Director to constantly calculate the risk of the greenness of the door, a dedicated Specialized Door Painting Chef to create food to your employees, in addition to some 25 painters, and 250 Door Coloring Quality Assurance employees, to make sure the door was “really green enough”. And of course, all of these employees would have to be specialists, with 25 different certifications each, and a PhD each in door painting, to prove that they actually knew their jobs.

Before they could even open up as much as a bucket of paint, each painter would spend three months arguing over the chemical compounds to use in the paint, the CMYK composition that most closely resembles the word “green”, in addition to arguing over whether or not they should use a pig hair paintbrush, or some new plastic based paintbrush. Not to mention that every time anyone brings up the question of whether or not to use Agile or Waterfall methodologies, the entire office would erupt into fist fights and quarreling, to such an extent, the Human Resource Door-Painter Manager would have to hire baboons to simply separate the different fighting fractions. Licenses for the chef’s recipes alone, would dwarf an average African Republic’s gross national product too may I add …

Of course, nobody could yet again not even open as much as a single bucket of paint, before the Risk Assessment manager had created unit tests for your door, which implies creating a robot that opens and closes your door, 11.000 times every day, to make sure its handles doesn’t break. Some 9 -18 months later, you can finally start painting your door. 15 years later, having spent 25 million dollars, employing half the village, and spending your country’s national gross product on a bucket of green paint, you could finally experience your new door – A new shiny green door, making you the envy of all your neighbors.

Am I the only one seeing the problem here …?

Don’t get me wrong, I love my unit tests – There are in fact more than 300 unit tests in Magic. But Magic was built arguably on the front page of MSDN Magazine, no NDAs to be seen. Every time I had a problem, I would post my code to Reddit and ask the great people over at /r/dotnet for help, to look at my code, and come with improvement suggestions. It was built by a single person, almost exclusively in his weekends and spare time, and still it’s a “billion dollar project”. In fact, I would argue, Magic has a higher amount of quality, than every single “professional project” I have ever worked on combined, even though I never had a Chief Door Technology Officer, or a Paint Risk Assessment Manager, or even a dedicated chef for that matter. And I can pretty much guarantee you that my budget for building it, was far away from the gross national product of both Norway and Cyprus for that matter.

Magic is not the exception that confirms the rule, Magic is the confirmation of that the rules sux, and that our current ideas of building software, are in fact madness!

20 GOTO 10

The above Amstrad CPC464 BASIC illustrates how easily it could be done. Sorry to sound the alarm here, but we lost something along the road …

Published by servergardens

Create .Net Core CRUD APIs wrapping your SQL database in seconds