Let's write better software

Posted by Filip Ekberg on 27 Sep 2012

Bugs are an expectation instead of an exception

Technology have been a big part of my life ever since I was a kid. If it wasn't a console it was a computer and later came the mobile phone. All these things running on electricity have always interested me. My first mobile phone was a Nokia 5110, which is the only phone that actually never broke.There's a joke around the net that the old Nokia phones never broke and that's very true; however they didn't do much more than calls, sms and snake.

When the phones with color displays appeared the mobile vendors noticed that people wanted to switch phones often; as soon as a new feature was released everyone had to have it. The vendors immediately started pushing out more and more phones, a lot more phones than were actually needed on the market. With this overwhelming amount of mobile phones and rapid development came a lot of more bugs.

Since I swapped from my first Nokia phone, I haven't had a single phone for more than 1 - 2 years. This isn't because I really needed to get a new phone but because after a long period of time it started feeling slow, less responsive and lacked all the cool features the new phones had. If the consumers want to buy new phones every second year, why should the vendors make phones that work for more than 2 years?

This has gotten too far, I'm not talking about the mobile phones but technology in general; the consumers are expected to change their behavior and their hardware/software often (every 1-2 years). What's scary about this is that I've caught myself saying:

Oh, you've got the 2 year old version/model. That program/accessory doesn't work on that version/model. You need to upgrade.

As consumers have somewhat adapted to this and expect rapid updates for software's. The vendors no longer need to spend as much time on finding bugs as they did before. A very good example of this is the launch of Diablo 3 where Blizzard needed to push Diablo 3 to the customers without it being completely finished. If you played Diablo 3 when it first arrived and play it today, it's almost as you play 2 completely different games; the story the same, but other things have changed.

It is not rare that vendors have open-betas of their in-development software or hardware. In Office 2013, Microsoft added an "instant feedback button" and this is Great! However, I've seen a lot of software's where they "forgot" to remove the "report a bug"-button in the RTM (release to manufacturing). Of course it should be easy to report a bug once you find it, but nowadays it's pretty much like the vendors expect the users to find bugs and that they need rapid ways to report these.

We no longer see bugs as exceptions, but it's rather expected and when we do find a bug we immediately think "this will be fixed in the next version sometime this week".

Stop delivering less than awesome software

We've seen that consumers are not scared of changing their behavior, as that's what we do; we adapt. Vendors need to start delivering better software and hardware!

As a software engineer, I know what I can do to ensure that each piece in the software that I create is high quality. If you don't feel that you've done an awesome job, something is wrong; we need to be proud of the software that we deliver!

It's quite often that bugs derive from "quick fixes", but a quick fix can turn into a quickly evolving bug.

Here's what I suggest we do to ensure quality of things we deliver:

Test, test and TEST!
Refactor your code according to the programming guidelines of the language your using
Write documentation (even if short!) about your methods, flow and functionality
Write test documents which includes both manual and automated tests
Create automated UI tests
Run complexity analysis tools such as NDepend on the code base to find too complex areas
Don't deliver if you're not happy with the outcome
Write readable code
Don't try to optimize better than your compile can by writing complex and un-readable code
Drink a cup of coffee before you deploy