Software development is an intricate craft; a technological art form that allows creators versed in the subject to effectively type things into existence. Coders paint with letters and numbers like something out of a sci-fi fever dream, with even writers like William Gibson failing to imagine the wild realities of what development evolved into. Rather than simply calculate, we can now use code to do so, so much more – including coding other tools, allowing others to create as well. And this tools-creating-tools-creating-tools family tree is almost reminiscent of humankind’s ingenuity with stone – or even, dare I say, a Godlike simulacrum of a creator creating a creator. But with the fanciful dreams of software development’s potential, and the education that brought us here, aside – software developers continue to be humans. Even with libraries worth of learning behind a coder, they can still fall into the simplest of pitfalls of development. Something that might seem so obvious in hindsight but overlooked in the blind fury of planning and typing. As such, it’s important to remember the various “Dos” and “Don’ts” of development, things easy to miss but sometimes detrimental to forget.
Do: Remember you’re creating for the user
With the intricacies of software development, you can get caught up in the wild net of what you’re creating – and you want your software to have it all. You know exactly what it needs, and you want to stretch out the potential on your software as much as possible to get it there. But as soon as you’ve put the final bells and whistles onto your software and released your pride and joy out into the world, your users find they don’t know where to start. The interface is a block of text and buttons that are impressive and useful to you, but meaningless to a consumer. There’s a concept called the “false consensus effect” which comes into play all too often as a creator. Because you’re steeped in the topics of what you’re developing, you might feel like you know what everyone wants – but remember, your audience might be a wide and varied bunch. For the software you’re creating, some may want to use one aspect for one thing, while some might want it for another – which is why it’s important to know your audience. Before going into the design stages, make sure you do market research into the types of people who will be using your software. A more personal and home-based software might need to be simple with clear buttons, while a specialised software can have more in-depth functions – it helps to scour forums of people who might want to use your product, or literally ask them, for what kind of software they want.
Do: Gather all material before starting the project
If you’re creating this software on a commission, it would behove you to get all of your information in one go. Picture this: you have a vague idea of what you’ve been told to create, and you get to work on the code. You’re on a tight schedule that you’ve calculated to a tee, and you know exactly when each part of the development will be finished by. After three-quarters of the way through, you realise you’re missing something integral – maybe it’s the business’s logo itself, or maybe it’s text written up by the client’s own copywriter. Whatever it is, you might not be able to go any further without it. You get in contact with the client, and it turns out they’re away from their desk – you don’t know how long it will be, and it could be a good few days until you hear back from them. But with this halt in production, your entire timescale has fallen apart.
Which is why you should have all your material on hand from the beginning; the assets, text, aims – not to mention deadlines and the overall pitch for the product. When creating the brief at the beginning of development, it’ll be useful to create a checklist of everything you need from the client. Cast your mind back to every piece of software you’ve worked on before, and what it took to complete it all. This will help for future reference and helps cover the specifics of whatever a client might throw your way. Remember it like cooking a complex recipe; when going to the store, have your list of ingredients with you so that you can get them all in one go. It’s a pain going back for the bits and pieces you missed, and your food might burn while you’re chasing the last few items.
Do: Be confident with your decisions
Much like the last point, it’s imperative that you’re on the same page as everyone involved on the project – this might include your development team, or your client if you’re working on commissioned software. When in the planning stages of the software, every decision should be your final answer, as it’s often hard to go back and change. You, and everyone else involved, should be at a point where you can confidently answer any question asked about the software. Otherwise, this could lead to confusion and a horrible Frankenstein’s monster of an application. Decide on a platform for your software – are you all aware if it’s going to be created for a PC, Mac, Android or iOS? The more intricate parts of your software rely on knowing the platform, and the software needs to cater for that. Communication is key when one or more people are working on a product.
Do: Be patient
As I mentioned in the introduction, software development is an art, and art should not be rushed (unless, of course, that’s the point of a particular art piece – but I digress). With coding, you’re bound to run into countless dead ends, or features that simply do not work. This is completely normal, and panicking and trying to patch over this may just make the problem even worse. Coding requires immense concentration; this is why when most of us think of coders, we imagine them hunched in their chairs, wide-eyed and lit only by their monitor’s glow. This is because coding is about focus and following the process – and jumping the gun could break what you’ve worked for.
Don’t: Create messy code
In the heat of wild coding passion, it’s very easy to create an unbroken block of text, each following on from each other with no rhythm or reason – nothing neat or tidy. To use a cooking allegory again, it’s like your kitchen counter getting covered in everything in the midst of preparing a meal – there might be flour strewn everywhere, sauce smeared over the cupboards and ingredients not put in the right places. If you need the paprika again, where have you put it? It just makes continuing with the recipe, or making another one after it, much harder. The same goes for creating code – you might think you know where everything is after a coding session, but think about when you get back to it the next day – do you really remember where one module ends and another one begins? It’s not only annoying dealing with your own messy code – it’s also time-consuming. And though you might be the only one working on your software now, you may eventually bring someone else in to help you with it. With a messy code, they’ll understand even less of it than you do.
Keep your software code as easy to maintain as you possibly can – it’ll be less stressful for everyone involved, and will be overall more enjoyable to deal with.
Don’t: Forget to document and test
As I’ve discussed in the “do” section, it’s important to remember that you’re creating your software to be used by others – and with that comes documentation. As a new user installs and uses your software, they might go into it with a particular aim in mind. And with this, you’ll need to write up everything your software can do, and how to go about achieving it. It doesn’t have to be a massively in-depth guide, but more of a step-by-step instructional on using your software from the very beginning. There might be something very specific about the installation process itself, which is why it should be written up for your users to follow. With the more specialised users who would want to use your software – for example, other developers and system administrators – you should provide a more intricate guide on the specifics. It’s important with your documentation that everything is as accurate as possible so that it matches up with the current version of your software. If you have recently updated the software with a new feature, remember to make this known to your users – your documentation needs to be updated just as much as the software itself does.
And with documentation comes testing itself – testing is so easy to overlook, especially if it’s a very small feature that’s recently been implemented. However, this feature still lives in the heart of your code, connected to everything else – it has the very real possibility of breaking another part of the software. You’ve spent countless waking hours writing this software, and it’s important to ensure that it works. Rather than manually testing every aspect of your finished code, it can help you a lot to create an automated unit test to push the boundaries of what you’ve created. This automated test environment maximises the efficiency of your development process, and publishing the test results to your users and clients will help them to understand the progress the software is making.
Don’t: Forget to back up code
Possibly the most obvious one, but also something so commonly forgotten by every creator. Document back-up is imperative for not only coders, but for writers, artists and photographers – if you keep all of your work limited to your machine, then all your hard work can be lost as easily as the machine itself. If you’re coding on a desktop computer, you can easily contract a virus or have your wires blown out in a power surge – or maybe you just spilt coffee on your unit. If you’re coding on a laptop, you might lose your code by leaving it behind on a bus, or simply have it stolen from you. I cannot stress enough the benefits of using online hosting and storage for your work – if the worst happens to the system that you’re working from, you can simply re-access your hard work and get straight back into it.
Backing up and hosting your code can also help you if you air it in a public service – code-hosting sites like GitHub and SourceForge are not only helpful backups for losing your work, but the community aspect can help you take your coding to the next level. Not only do these platforms have great communities that can help you with dead-ends in your work, but users can subscribe to your software and be up to date with the latest versions, news, mailing list and a full-fledged wiki devoted to your software. Who knows, you might even find contributors in these public circles to develop certain parts of it for you.
If you’re not interested in having your code open to the public, there are other hosting services that do the same thing, only private – for example, Assembla is a popular private platform for this, and offers use of a full revision history (to return to earlier versions), release tagging and even abilities for branching.
Though all of these may seem simple and obvious, they’re incredibly useful to remember in your coding process. Remember: software development is not just about writing code, it’s a craft to be undertaken slowly and artfully.