The Tyranny of The Masses in The Bazaar

A good friend of mine Rizal Al-Mashoor recently passed me this, A Generation Lost in the Bazaar : Quality happens only when someone is responsible for it.

The article focuses on two interesting works on the evolution of software, namely:

  1. The Cathedral and the Bazaar (O'Reilly Media, 2001)
  2. The Design of Design (Addison-Wesley Professional, 2010)

I will confess to have not read the second one but I most definitely read the first one as I have a soft spot for *NIX based operation systems and open-source.

Previously in the old days, software is built like a cathedral as the book implies, with nothing less than perfection in mind and with zealous adherence to quality. That was what gave us our IBM Mainframes, AT&T UNIX etc that some might argue as overbuilt or over-engineered (I don't really see that as a bad thing as that is why people buy German Automobiles). The downfall of that approach however is that it suffers from long release cycles and is slow to adapt to changes. Along came the Bazaar which was really borne out of the GNU FSF and Linux movements where hackers got together to do stuff they wanted by.....hacking away. As the article passed to me accurately states, that has caused code quality to slip quite a bit in favor of expediting the release of a solution quickly and the quality issues are further exacerbated by the decentralized nature of the open source Bazaar where there is no real central figure to enforce things. Linux is one of the few exceptions as Linus rules with an iron fist and his communication of his displeasure regarding the breaches of quality can only be described as abrasive. In the Linux kernel world, NOBODY disobeys Linus who is the benevolent dictator of the Linux Kernel. Otherwise it is very darwinian where the most popular solutions survive while the rest die out. Natural selection? Perhaps but notice I said popular, not the best in quality. The problem with the bazaar is that it is very democratic and those that come to market first or have the highest adoption rate win but may not be of the best quality. They may be as time goes by but quality is not really as important as rapid releases and solving problems, cohesion and quality be damned. As long as it works and looks good, its all good as some say.

This culture has also infiltrated the business users as well with the success of startups that adopt these bazaar hack-ey solutions to come to market fast. There is no denying their success but the issue is that people who aren't in the trenches coding see that and think it applies everywhere. Furthermore, today everybody has what I term as instant-gratification-gitis where push button solutions are expected and expected NOW. This has created a situation where new software developers do not really learn how to build cathedrals and experienced developers needing to dispense with the quality of cathedral style software for the sake of expediency. We have ended up with two bazaars now, the software bazaar of endless ideas that need to be executed as fast as possible and the bazaar of users with an insatiable need to solutions they want at breakneck speeds.

Before all you Agile/SCRUM zealots come out with your pitchforks and lynch me for the appearance to support the old cathedral way of building software, I am not supporting the waterfall model that has been associated to it, rather I am talking about the strict adherence to quality practiced by developers of that era. Granted I am generalizing but I must admit that a lot of the older software are better written although they may have archaic looks and features. We developers have been subject to the tyranny of the masses with lots of jaded or in most cases clueless developers saying why not just do it quickly so users will get off our backs, we can always optimize later and users who want things NOW although in most cases these days, they make you feel that they want it yesterday thus increasing the need to expedite the development process by dispensing the quality of the code. To the optimize later developer, as I have been reminded today, later optimizations will never happen as you will be thrown into solving other problems which will be brought about by the user wanting new features NOW and make you work like they wanted it YESTERDAY. This will mean that we will have a pile up of quick fixes and hacks that will make Frankenstein look elegant in comparison.

Most of you are saying, such are the times and it is how it is always done and it is the only way that works since the masses have seen it work. Really now? I beg to differ. You may have heard about something known as the Apple iPhone. The Apple iPhone is always behind when it comes to features and design. It has always been considered very conservative and succeeds only through marketing. I agree with those points as I am an Android user BUT here is the thing, what Apple does with the iPhone, it does well, they take the time to create the perfect type-face to the perfect feeling hardware. The take away here is that just because users want things NOW does not mean you have to do it like they wanted it yesterday. Apple has succeeded by making relatively conservative increments in the iPhone as they prize quality above all else. The iPhone users are still happy and as loyal as ever, all without following the trend of breakneck feature releases that are usually lacking in the code quality department. We must always remember that as developers working in the enterprise, we aren't Jobs and Woz in Paolo Alto. We are not in Oz on the yellow brick road off to make millions by banging out a million features to come to market quickly.

Our job as developers who aren't in Oz would be the creation of the best solution possible like a cathedral, beautiful and elegant, high in quality. The business user may not see it but that does not make it irrelevant. Why you may ask?

How many times have quick and dirty solutions caused the following?

  1. Bugs that will crop up due to code not being robust enough. These are the most insidious as they may pass functional QA but break under real load either now or some time down the road because you have to dispense with good pricinciples to satisfy the business user pressing the I WANT IT NOW button.
  2. The thing becomes a prick to change or enhance as it is a patchwork of hacks and good intentions. You end up needing to write a hack to fix a hack which ends up breaking a few other hacks thereby necessitating the creation of new hacks to hack the application back into barely working order. If you felt that was a mouthful and excruciating to read, imagine the developer who has to work on code a thousand times longer and even more excruciating to comprehend, much less fix. You will start to see diminishing returns as it will take more and more effort to change it to the point of being unmaintainable. The initial smiles you see from your end users due to your speedy delivery will now be frowns on how messed up your systems is and them hounding you to get your shit together which you can't because the code is no longer maintainable. Passing functional QA for the initial version does not mean anything if you built something that can't adapt to the evolving needs of users in a timely manner.
  3. The end user ending up buying a less powerful off the shelf solution because your rapidly developed solutions which lack quality end up being too expensive to maintain and they would rather that the assured quality of a less flexible product that they know works. Everybody loves a classic 1969 Ford Mustang but would rather get a Toyota Camry as a daily driver as it works more often than the 1969 with equal amount of maintenance.

In the end, the real take away is this. Users will love you when you succeed and hate you when you fail. Why not take a longer time to get things right so they will be happy later down the road and are assured that you are giving them the right thing every time rather than lulling them into a false sense of satisfaction by giving them a solution quickly that is in reality, a timebomb.

The responsible thing is never the easiest thing to do but it is the only sustainable way of doing it.