By Mike Jackson

When writing software, you’re writing something that others will use. And in these days of off-the-shelf components, you may be using or bundling other peoples’ software too. This handy guide describes some simple, yet proven, ways in which you can successfully make the life of your users an absolute misery, incur the wrath of your fellow developers and make software lawyers salivate.

Why write this guide?

Sometimes it's good to see a problem from a fresh perspective. We've wound up Mike Jackson into an absolute frenzy and asked him to write an anti-guide. Here's what not to do when writing software.

Don’t use version numbers

You know what version was released on what date, don’t you? Of course! Why would a user need this information? After all, when they ask for help you can always take two or three e-mails to try and identify which of the releases they are using. Working with your users in this way helps you bond. It allows you to spend a fun couple of days together, desperately trying to solve a problem only to find that your user is using software released three years ago that you no longer support.

Don’t bother with a licence

There’s no need to have a licence in your download bundle, installer, or user document, nor is there any need for your users to accept terms and conditions before they download your software. It takes too much time to implement this, and you have more important work to do.

You can trust your users. Trust them not to steal your intellectual property, pass your software off as their own work or use it to make lots of money without giving you due credit. Users aren’t smart enough to even think of such things. Anyway, even if you did have a licence, no one would bother reading it.

Keep your project website or e-mail address to yourself

If you don't keep your contact details quiet, you run the risk of users contacting you. Helping them might encourage them to stick with your software and to use it. Worse than that, they might even send you a bug fix or some added functionality, and you don’t want to have to contaminate your code with that from outsiders. They might even stoop to asking you about a possible collaboration!

By not telling users how to get in touch with you, you don’t have to spend any of your valuable time dealing with your users and can instead spend it all on writing your software.

Build your bundles so that when they unpack, your files are spread all across a user’s directory

Some developers put their files into a single directory, then bundle that up and distribute it. You don’t want to bother with that. It's too easy.

Try to ensure that when your bundle is unpacked, the files inside are just unpacked into the user’s current directory. There’s nothing that makes a user’s day more exciting than trying to unpick their own files from your unpacked ones. For that added extra enjoyment, try and make sure that your files share names with those of your user so that when they unpack your bundle their own files will be overwritten. This makes it far harder for them to remove your software and ensures they’ll remember you with an incandescent passion.

Don’t waste time testing build files

You don’t need to test your build files, they already work. If they work for you then they must work for the users. If they don’t, then your users aren't using them properly. If you’re still unconvinced, remember that if a user can build your software, they can use it. You don’t want that, because they might get stuck and ask you questions (see above).

Say that your software is easy to use

Your software is easy to use! You can use it, no problem. So, don’t hold back, take pride in your work and make sure easy-to-use is prominently displayed in your user documentation, your website, in presentations and on posters. Your users, battling for hours trying to get your software doing what they want, will understand that it is them - not you and your software - that is at fault. Sometimes you need to humble your users to motivate them to overcome their problems, and so prove themselves worthy of using your software.

Don’t say where third-party libraries and files come from, or what versions they are

Again, you know where they came from and what versions they are, so why burden your users with this knowledge? You may get some nerdy type who wants to understand your software and how it works in more detail. These picky users might want to try more recent versions of the libraries to benefit from bug fixes or performance enhancements. They’ll set themselves up as able to improve your software for you, or worse, improve your software for others. In short, users like this are competitors and must be treated with suspicion. Suppress the origins of third-party libraries and files and keep such arrogant upstarts at bay.

Replace third-party copyright with your own

If you’ve used some open-source software, you’ve fixed some bugs in their code or extended it, then that means the source file you changed belongs to you now. Stake your claim and remove the original copyright and replace it with your own. Remember that as it’s your software you own it, all of it.

Don’t say that you’ve used other peoples’ source code, files, or libraries

You’ve taken the time to download their software, you may have had to fill in a form or even pay some money. That means the software is yours and you can do what you want with it – bundle it in your releases, stick it on your public, source-code repository, or give it to who you want. If you baked a cake and sold it at a local craft fair you wouldn’t list the ingredients, and where you bought them would you?

And, don’t worry about their licences either

Don’t waste time reading the licence of the software that you're using. Boring! After all, no one else reads that stuff, and it’ll only take up your valuable time. The licence will only end up saying that you can’t distribute the software without permission, or impose some other stupid conditions. No one's going to check up on it, are they? And, don’t even think of including their licences in your releases or repositories, they only take up space. You’ve written your software to use their software, so you’ve done them a favour. What more do they want?

Remember, if you’ve downloaded third-party software you’re free to do what you want with it. This especially applies to open-source software, because, as the world knows, open-source software is free software.