Re: Everything's broken and nobody's upset

This is a re-worked answer to Scott Hanselman's great post 'Everything's broken and nobody's upset'. I replied it below the post, but I think it deserves a post here. Scott's post is about how we seemingly accept a long list of annoyances and issues with the software we use and how we apparently ignore the fact just how broken today's software seems to be. In my answer I tried to give an answer to why that is. This answer is below.

I think a lot of the problems with today's software are simply allowed to show up in public because the dev teams of these software products aren't given the time to fix them: Time to Market is critical, marketing already reserved a given launch date for the product, things are already in motion and only the bugs in the category 'it kills kittens and old ladies' are fixed at that point, the rest is 'moved to a later date'. But that later date never comes, because after the product is done, the team moves on to the newer version with new stuff, and fixing bugs is dreadful work, new stuff is exciting.

There's another thing about bugs which is also key in this issue: fixing them won't sell more licenses of vNext: people won't run to the store, yelling "OMG! They fixed bug 33422!!!1 I can't believe it!". They'll run to the store because new, shiny things have been added, like a completely new UI with ergonomic characteristics of which no-one really knows whether it's actually a step forward.

We, as software developers, all know software contains bugs, even though we did our best to fix them before RTM. But in the end, we have to admit that that label, 'RTM', is really just an arbitrary calendar event, not a landmark which says "0 bugs, It's ready!". This means that even though something went RTM, it doesn't mean it's bug free, it simply means: "It's good enough that it won't kill kittens nor old ladies".

A wise man, who unfortunately passed away way too soon, once said to me: "Your motivation and ability to fix issues and bugs is part of the quality you want to provide", which means: even though at first glance your software might look stunning out of the box, if that essential part of the quality of the software is missing, i.e. when a bug pops up it gets fixed, pronto, your software isn't of the quality you think it is. The insight given by this wise man opened my eyes all those years ago and I to this day still try to live up to it: stand for the quality you want to provide by giving customers the best support and software they could get.

If I look at today's software development landscape, I see a tremendous amount of people trying to write applications without the necessary skills and knowledge, in languages and platforms which have had a bad track-record for years, yet no-one seems to care, or at least too little. Last year I was in an open spaces session and some guy explained that they would place people who just started programming as 'trainee' at customers for 'free' and after a few months these trainees became 'junior' programmers and the client had to pay a fee per hour. I asked him what he thought of the term 'fraud', and he didn't understand what I meant. I tried to explain to him that if you think a person who has no training at all and you let him 'learn on the job' for a few months, is suddenly able to write any form of software, you're delusional. He didn't get what I wanted to say, and how it was a bad thing that someone with no skills was placed at a client as if the person knew what he was doing. Shockingly, some others in the room agreed with him.

But with the lack of highly trained professional developers growing and growing each day, more and more people who can tell the difference between a keyboard and a mouse are hired to do 'dev work', as the client doesn't know better and is already happy at least someone is there to do the work. I fear it only gets worse in the coming years. Frankly, I'm starting to get fed up with the bullshit pseudo-devs who seem to pop up more and more every day, who cry 'I'm just learning, don't be so rude!' when you tell them their work pretty much doesn't cut it, while at the same time they try to keep up the charade that they're highly skilled and experienced. You're either a trainee and therefore your work can lack in areas, or you're a professional and you have to take responsibility for the quality you say you'll provide.

Sadly this process of pseudo-devs which are seen as the true 'specialists', is in progress for some time now and will continue in the next decade I think. Let's hope they'll learn something about what 'quality' means with respect to software, that 'quality' is more than just the bits making up the software. But I'm not optimistic.


  • I think the point you are slightly missing is that the vendors of operating systems and developer tooling themselves are the worst examples of this sort of poor quality. I'm not going to start yet another rant about how appallingly bad most Microsoft software is, but if users find their core OS and Office software "acceptable" with such a low quality threshold, why should they expect anything from much smaller software vendors to be any better? There's no incentive for developers to improve things because even with a low quality bar they're better than the "big boys" whose software the general public seem happy with!

  • >There's another thing about bugs which is also key in this issue: fixing them won't sell more licenses of vNext: people won't run to the store,

    Ok, but having bugs:
    1) create frictions with users, that might end up hating the product
    2) generates support and maintenance work.

    In other words, fixing bugs doesn't create 'pros' as you wrote, but not fixing bugs create serious 'cons' and this will degrade sales. This is why fixing known bugs is a top-priority, at least for me :)

  • I think it's incredibly dishonest to suggest we ever stop being trainees.

  • @Jeff: if you say you're a professional, a specialist, and you're actually a trainee, it's IMHO wrong. If you say "I'm just a trainee" and you are at that point, in that particular field, it's ok, IF (!) the client indeed understands what that actually means.

    I didn't want to imply we never stop learning, but I did want to imply that if I say I'm good at 'X', I'm not a trainee anymore within X, but a specialist, a professional. There's within the field of 'X' still infinitely more to learn, but for the job at hand, being good at 'X' is what the client expects (!).

    See it as what you expect from a guy you hire to fix the plumbing in your house: you hire a person as that person says he's good at fixing plumbing. You expect, after paying him, that things are fixed and work like they should. As he's a professional.

  • This is something I've been thinking a lot about lately and honestly it's not just an issue with software. Every time I hire a "professional" to do X, I'm severely disappointed.

    I keep thinking to myself, man, if I produced work like that, I'd be out of a job. Maybe I'm just growing into the old version of myself, but it's really disheartening to constantly see the lack of craftsmanship in other people's work (llbl excluded of course :).

  • There's a name for this: Agile

  • Great post Frans! Totally agree!

    LOL @ the "agile" comment, it's so true.

Comments have been disabled for this content.