HomeNews and blogs hub

Ask Steve! - So what shouldn’t you do?

Bookmark this page Bookmarked

Ask Steve! - So what shouldn’t you do?

Author(s)
Steve Crouch

Steve Crouch

Software Team Lead

Posted on 4 May 2012

Estimated read time: 3 min
Sections in this article
Share on blog/article:
Twitter LinkedIn

Ask Steve! - So what shouldn’t you do?

Posted by s.crouch on 4 May 2012 - 4:55pm

We mention things you should do when developing software quite a bit. But we were asked an interesting question at the Software Sustainability Institute’s Collaboration Workshop this year: what things shouldn’t you do when developing software?

Come on, there has to be some. And there are – many! But let’s focus on five of the big ones…

1. Don’t develop code you can’t maintain

This has got to be high on the list. Code can turn into spaghetti from out of nowhere, and it’s always worth avoiding. Best to get into good habits early on in the project!

2. Don’t make your software difficult to build and install

We’ve all experienced this with other people’s software. If user’s can’t install it, they’ll move on – perhaps to a piece of software that has inferior capabilities. Why not make it easy, and simplify (or even automate) the build and install processes that are so often fraught with peril?

3. Don’t keep the source code to yourself

If you hold the source code in only one place – your development machine – and you lose it, you only have yourself to blame. If your development machine is your laptop, it’s even easier to lose. Avoid the pain and use a suitable source code repository from the outset!

4. Don’t forget documentation

Writing documentation is boring, but it is necessary. It’s your primary means of communicating your users what the software does and how to do it to. As with difficult build and install processes, you risk disenfranchisement if users can’t find out what they need to know.

5. Don’t overlook testing

Features, features, features. But if you neglect testing your software, you risk losing users, users, users. In the rush to implement and release a really handy new feature, ending up with a release that doesn’t work will not instil confidence in your product. And including a means for developers to run a solid set of automated tests and implement their own is very useful as a fail-fast development environment when they want to modify it themselves.

Well, that’s my five. You’ll notice I haven’t covered any software release “don’ts”, but that’s because I’m currently putting together a related top 5 list of software release “Dos” :) So these are just scoped to software development. If you’re interested, you can check out these in more detail in in my post on the Software Sustainability Institute’s blog.

Maybe you disagree with my list above, in which case let me know what you think are the big software development don’ts.

Share on blog/article:
Twitter LinkedIn