Posted by mkarg
on December 29, 2010 at 10:58 AM PST
These days I got a feeling as if professional software products get worse with every release. One cause is a fatal misunderstanding of best practices by the big stakeholders. Looking at their current products, one should ask them to "Release Late, Release Rarely"!
Meanwhile I am looking back to more than 25 years of programming, and more than a decade I spent in a very sensible area where quality (in the sense of zero failures) plays a big role. So call me "sensible" for quality. For long years "we" (i. e. developers) had hard work to do using simple command lines tools like vi etc., but meanwhile there are great, even free, tools making our lives much easier. So one should think that the freed time was spent into quality. The reverse is the case. The more I look at professional software products, the more I see, sorry to be rude, simply: crap!
The question is: Why is that? Having some insight into several bigger and smaller stakeholders, including my own participations to some Open Source projects lead by my self, Sun, Oracle, Bull, Microsoft, and some more, and looking at the work we are doing in my company and its affiliates and subsidiaries, gives me some feeling where the root of the evil is located: In the organization of the project.
Gee! I can tell you how I hated to attend to those boring, mandatory "business organization" classes at college back in the 90ies. But hey, looking back from now I need to say: Those profs where just right! Fullstop. Quality is directly related to your project's organization (which is the way you organize people's way of working, not the way you imagine the resulting artefacts). If you don't organize for quality, you won't get quality. Thinking you already organized quality? Let's see...: You can write thousands of tests. You can do pair-programming. You can do Scrum. You can to Kanban. You won't get quality from that. Throw all that away. It has not at least to do with quality you'll actually get in the end. You only will get quality in the end, if you actively plan quality from the start. That means, you have to enact measures which will result in quality getting actively produced while designing. That's the reason why systems like ISO 9000 etc. enforcing FMEA (Failure Mode and Effects Analysis) and other methodologies the be applies at start and regularly whilst the complete project instead of enforcing just "testing". Not just doing TDD while writing code. That's far too late. Not while testing (that's just to find bugs you already did). Not whilst the beta phase (that's to find bugs you where too lazy to find on your own). Not by fixing reported bugs (that's just to wipe up the bugs your beta testers had been too lazy to report and which will break your neck otherwise). Quality starts at the very beginning of everything. And it doesn't start in your typing hands. It starts in your brain.
To gain quality, you first need to accept that a program is not "good" if it hardly does what it shall do. A program is "good" if you cannot crash it even if you want to. Let's make an example: I just downloaded latest JDK, GlassFish, Eclipse (including GlassFish Plugin). Within one hour I managed to screw it completely. All I did was using it. I not at all had in mind to break it. It just happened. I just used the wizards to create an EAR, EJB incl. EJB-Client, APP Client, deployed / redeployed few times. Crash. Bang. Boom. Now it's so screwed that neither Eclipse will be able to compile a freshly set up, empty project anymore, nor GlassFish will deploy X.EAR since it cannot find Y.EAR (which I undeployed and then deleted the projects, but it seems to have more than one redundant information about that which I cannot find). I tried to clean up, but gave up after another hour. And no, again, I had not done anything to crash it by intention. Is that "good" software? Well. Think of people wanting to crash it by intention (like hackers and unsatisfied employees) and then answer then. Don't get me wrong, I appreciate the work the GlassFish team does. I just don't think that form a quality perspective it would be "good" software. It's just "cheap" software from a big stakeholder. But "good" is far different (and would be much more expensive).
So there we are at the key point. Quality is expensive. Yes, I know, everybody goes round and round telling that quality would spare money. What a hoax. Quality does not spare money. Quality costs money. Lots of money. Everybody in the CAQ crowd ("Computer Aided Quality Assurance") talks about quality in the end will provide increased revenue. That is wrong. Quality will typically lower revenue - at least as long as you are not obligated to correct failures on your own costs (which is only the case in some countries of the world, so one can guess what the most global companies will act like). In fact, even in countries where you are obligated to correct failures on you own (like Germany), big stakeholders just sit back and wait for the one customer that dares to complain. Will he get a fix for free? Nope. I tried for months to get one from Sun Microsystems, Microsoft, Hewlett-Packerd, and others. And what did I get? If I would pay the fix, I would get it. So why should any of those vendors ever care for quality in the end, if they get paid to fix their own faults? In fact, they all tell about quality, but regarding to organizing for quality, they don't care in the end. Maybe the boss cares, but the lots of managers do not. They care for short term revenue which is better the worse the product is. Sad, but true. BTW, the funny thing is, that companies that everybody knows for horrible bugs, improved quality. Seems they meanwhile understood the benefit of long term revenue. But exactly that companies that provided quality for long time, now producing crap more and more. Strange, isn't it?
The reason is simple and let's tell it clearly: Off-Shoring. I really don't want to blame globalization, but in fact, it is nearly impossible to organize people located in different continents to work in a way that will result in something that is worth being called "quality". How should that ever work? Sorry to say that, but Sun, Siemens and others did not move to India because American or German engineers where too dumb. They were too expensive. It's not that American or German engineers where too expensive. They just wanted to make even more money. Certainly everybody told them that quality will be affected. But who cares if customers have no choice? From a colleague I know for sure that his company (which is a global player) for more than five years only got pure crap from Bangalore. And nobody cared. Not even the customers. Because they had no choice. Sink or swim. Example: I wanted to buy a car radio that is able to switch from album to album while showing the cover ("Cover Flow"). Well, first I thought my local dealer is dumb when he told me that even with a 350 US$ specimen from Pioneer, Alpine or Kenwood, I have to go through plain text menus to select the album. No, this not a hoax. This was christmas 2010, and I meanwhile got letters of confirmation from those vendors that the dealer is not dumb: You cannot switch to the next album with a single click. Definitively. That is not quality. That is crap by design. Ten years back the user experience was in the middle of the car radio development. Ten years back the development was located in Germany and the USA. Today the development is in India and China and I doubt that the majority of that engineers actually could afford to buy their own product (or just hardly). Who goes through menus while driving? They just didn't think. And why? Because their target is to make money. Not to provide quality. Just one example. BTW, the excuse of the vendors was not "we are too dumb" but it was "car radio development these days is bound to some monetary boundaries". We know what that means. If they would pay more for their engineers, they could just move back to the USA or Germany. "But it was a strategic decision and will not get changed, even if it will not result in any revenue at all." (citing a development engineer).
So what to do? Go back to the roots! First, you have to reduce product development to a few core people, located in a first world country. That people have to be experts. They have to be well paid (the major reason why lots of Sun people quit with Oracle was about reduced income, BTW). Those people have to have enough time and equipment and silence. Don't bother them with revenue, release dates, and so on. Just wait until the software is done. No need for thousands of engineers in India. No need for "taming the masses" things like XP, Scrum and Kanban. Just let them sit in a quiet chamber and wait and do not disturb. And, do neither ask your channel partners nor customers what they want to get. Ask professors what the future looks like and do that. Don't go for hypes. Just provide the best possible quality. That must be your target, independent of the actual product. And: Release Late, Release Rarely. No need for another release every month. A release once a year is well enough. Don't beat around the bush on lots of conferences. No need for "community". Just work and present it when it's done. That's the way to get quality in the end. Everything else just is marketing show.
I know that 99% will hate me now for saying this simple truth. But that won't change the facts. Quality is not provided by asking the masses. It is provided by few experts having time and peace.
An overview of all my publications, presentations, code snippets or complete products can be found on my personal web site Head Crashing Informatics .