My Top 10 Development Tips

1. Thou shalt KISS

The KISS (Keep It Simple Stupid) paradigm or Occam's razor is paramount in programming, especially for complicated projects. All too often there is the temptation to write code that is beautiful in its sophistication and reeks intelligence whereas a simple design would suffice.

One extreme is to pack an entire program into one killer class or function that might execute the fastest but debugs the slowest. Remember that optimising your code should be the very last thing you do, if at all. However, there is plenty of literature on the web about how to program fast code while keeping the code penetrable.

Another extreme is a design that plans to be as versatile and extensible as possible, incorporating every single possibility before it's even known. Apart from wasting a lot of time, this approach can lead to paralysis through analysis where there are so many classes and relationships between them that you lose site of your original goal.

Both these approaches lead to hard-to-debug code that is difficult for yourself and others to understand.

This leads us on nicely to the next commandment:

2. Thou shalt use iterative development techniques

Debugging is possibly the grimmest job in the world and so often it takes up most of the time. So how do we avoid it? It cannot be avoided completely, but if you program iteratively you'll find that your bugs are smaller and easier to squash.

Iterative development is all about programming tiny steps and then compiling and testing the code. I've heard of people compiling steps as small as a single line of code - this is not silly if you feel it necessary. It might seem like a waste of time but it saves time in the end.

"But it takes over an hour to compile my source code! How can I possibly use this technique?" If you are recompiling the whole of your code then you're obviously wasting time. Try separating your project into several object files and if this is not possible, think about writing a stand-alone mini-program to test the code you are writing.

When you start a project make sure you employ the simplest class design that just does the job. For example, if you are programming a word processor from scratch, start with a single function called printHelloWorld() even before you've thought about standard input from the console. Then compile, run and test. After some time you'll find that programming is a pleasure because it always works!

3. Thou shalt continuously refactor

So how do I come up with a design that is perfect for the job? Answer: you don't - you come up with many designs. If you develop iteratively then you will notice that with each iteration your class design becomes less adequate. This is normal and means that you will need to redesign it. This is called refactoring.

Some people think that the best way is to think up the correct class design from the beginning - that way less code has to be rewritten. However, this is very seldom feasible as project goals often change through the course of time or become more sophisticated. Anyway, actually writing code takes no time compared to designing it. Look at refactoring as an iterative approach to design and you'll realise that it saves time in the end and means that your final design will be just right for the job.

It also means that you'll always at least have something to show at your milestones - better than showing a mass of fully designed code that crashes.

4. Thou shalt document thy code

It doesn't take a minute to document your code with inline comments. When you work in a team of programmers you'll spend a lot of time looking at other people's code. This is often the best way to learn what is well documented and what is not.

Some programmers who have not documented their code have argued that the code itself is the best documentation. I agree that this is true, but a couple of lines of comments at the top of the file would have saved me time having to go through it. Function and class names should speak for themselves, but it is reassuring to at least have an overview of them and how to use them at the top of the file.

5. Thou shalt write progress reports

Even if you are not required to, it's a good idea to keep a log of the changes you have made to your code and to keep track of your progress throughout a project. This helps you to monitor how long you are spending on certain tasks and can avoid time wasting. Of course, when I mean time wasting, I don't mean the time you spend with your finger up your nose, but the time that you spend on "sub-projects".

A sub-project is the term I give to a project that spins off from your main assigned project. It hasn't been assigned at all and it's one of those great ideas you've had that you can use in your assigned project and be a great module that can be used again in another project somewhere along the line. Hmm.

We've all done it and sometimes our enthusiasm gets the better of us and we go off on a tangent on a sub-project that starts to take over more and more of our time. It all comes crashing down when the project manager finds out how you've been wasting your time and tells you to scrap the whole idea and your hard work you've put into it.

If you have a great idea, share it with the team. If it really is worthwhile then it might be assigned to you as a real project at some time.

6. Thou shalt communicate with humans

All too often we get so wrapped up in our own code and deadlines that we feel that we don't have time to leave the computer and swan about and talk to others. Spending too long at a time on your backside in front of a screen is not good for your health and you tend to get bogged down so much that you are not working very efficiently. Other symptoms are staring out of the window, panicking and general frustration.

To avoid these problems make sure you get up and talk to people. Ask your colleagues about how their projects are going - they will be pleased you show an interest. When they ask about your project you will be forced to explain it on a higher level. So often I've found that talking about a project out loud helps you to clarify the steps needed to program it. When I'm on my own, I sometimes get lost in a low level of complexity. Having to explain it to someone else often helps me simplify things and there are plenty of times when I've returned to my desk with a clearer idea of how to advance - all because someone lent me their ear.

7. Thou shalt give pair programming a go

Okay - this shouldn't be a commandment because it's probably not for everyone, but you don't know until you try. Pair programming is part of the eXtreme Programming approach to development and simply means two programmers sitting at one computer. That's one computer with one mouse, one keyboard and one monitor.

Pair programming can be incredibly rewarding. It's fun, it's constructive and forces both of you to continually keep check of how the code is coming along. So how does it work in practice?

Usually what happens is one person sits at the computer and types and the other one thinks about the next step. Then you swap places. You see how the other person codes and you can learn a lot from it. Having two pairs of eyes on the code means that a lot more bugs are stopped in their tracks and you can both share in the joy of the code that works a dream. I've also found that I feel less tired at the end of the day because of spending less time looking at the screen - half the time I work on paper to prepare the next step or plan out the next major refactoring design.

8. Thou shalt use UML

Universal Modelling Language (UML) is exactly what it says on the packet and thus you should use it when designing and explaining your designs to your colleagues. It's worthwhile getting used to it because you will find it speeds up your design time and encourages you to work with pencil and paper and less time looking at a screen.

Knowing UML also means that you can understand common design patterns like those in the GoF (Gang of Four) book. Most patterns you will be familiar with and others will give you inspiration for new ways of implementing things. But most importantly they will help you in explaining designs. "I'll use the Visitor pattern for this part ..." is a far more succinct and less confusing way of explaining a design than the many sentences you'd need without it.

9. Thou shalt not panic

Sometimes time schedules are tight and with the pressure of your boss, client or producer on your back it's hard to stay focused. If you panic you will be compelled to program faster which will lead to more mistakes and more time debugging later. You will make rash design decisions and your code will probably be poorly documented. You'll also be tempted to leave some piece of refactoring and hack a fix into the system instead.

All these symptoms of pressure don't help and it's important to remember to adhere to good development techniques. In hard times, I've found it's better to spend even more time planning than I usually would. Making to-do lists and setting an agenda can help to calm you down and put your mind in gear. If you give yourself a set of mini-goals then you will feel rewarded when you meet them and keep you more on track.

If you need to work longer to get something done then often it cannot be avoided. But please, don't do an overnight shift! I've been in this situation before and when you look at the code later in a fresh state you wonder what you were thinking. If you are going to work longer then try not to exceed 12 hours shifts. Working longer means you are burning more calories so make sure you eat more. Also take breaks as you would during a normal day and get your boss to order you a great take-away.

10. Thou shalt enjoy thy project

If you're not having fun you won't work well. If you're working on a project that bores you then you'll probably find that this changes after time.

I have found that most of the projects I have been given that I didn't initially enjoy were ones that were either buggy from the start or they were about things I knew little about. Either way, they were projects that challenged me. The best way to get on with these kinds of projects is to sit down and learn them. If you're a programmer then you probably enjoy learning new things - if you don't then I really don't know how you got this far!

If you're a newbie then you've probably been given a project none of the others wanted. They probably didn't take the project because they also didn't know much about it. This is your chance to get good at something and within a little time you will be rewarded by being the one being asked for advice rather than the other way round.