.NET Zone is brought to you in partnership with:

I am a Software Engineer working with the latest in .NET focusing on Web Development. With a burning heart for programming, I blog and author a book about C#. Filip is a DZone MVB and is not an employee of DZone and has posted 53 posts at DZone. You can read more from them at their website. View Full User Profile

Let's Write Better Software

09.27.2012
| 7915 views |
  • submit to reddit

Technology's 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.

Consumers have adapted to this, somewhat, and have come to expect rapid updates for software. 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

Let’s make better software, together!

What’s your suggestion on ensuring that we deliver high quality?

Published at DZone with permission of Filip Ekberg, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)