I’ve been writing code for a long time – professionally, since 1986. In that time, I’ve learned tricks and strategies for making it more robust, more flexible, faster, etc. I’ve planned software to the nth degree and I’ve written it off the cuff.
I’m a firm believer in prototyping. I like to get something up and running as quickly as possible so that I can grow it, play with it, see what design changes make it better, etc. It’s very difficult to keep a lot of variables in your head at once and having thing written down, even code snippets, makes it easier to juggle thoughts.
One of my personal strategies is to keep a notebook. I outlined this as a personal best practice in my book. I’ve been doing this since my days as an engineering student. Although I don’t do this as a legal document, I do find it useful for many things. I jot down ideas and alternatives, I track to-do lists, I diagram code, and doodle icons. Since one of my friends introduced me to engineering paper (it has a faint grid on it), I’ve preferred using quadrille ruled (like graph paper) notebooks. This is partly because of my previous life in solid modeling and computer graphics, as graph paper makes drawing things a bit easier for me.
When I work on a new project, I try to keep in mind the big picture, but I’ve found that having a prototype makes it easy to play with ideas as long as you don’t go too deep. I’ve tried many time to plan code solely on paper (or an electronic document), but found that, especially with an existing code-base, I’m usually wrong. It’s irritating to find that once you’ve carefully planned your code, that as soon as you try to implement it, you find out immediately that you were planning to modify the wrong classes. Also, the amount of planning should depend on the size of the project.
I’m also a firm believer in phased development. Being able to give the customer (even if it’s the marketing department) something to look at and comment on, is invaluable. People have an easier time understanding what you’re talking about when they can see it, rather than imagine it. In my current project, I’m trying to replace an existing application that was developed as a prototype (by someone else). Now I’m able to start over with a good idea of what my customer is looking for. This is happening with staged development, too. My customer currently has an application that he can play with and comment on. Since it was developed in phases, he hasn’t had to wait for a year before there was something to work with.
On the other hand, the requirements are now growing. This is requiring some code enhancements that I hadn’t expected and is challenging some assumptions that I’ve built in. Fortunately, code is morphable and as long as it’s not written completely horribly, can be changed without starting over. Constant refactoring is key to this process. I’m continually taking code snippets and creating new methods, making all of my methods smaller. Being happy with refactoring and not beating yourself up about prior decisions is important. When I morph new features into my code-base, I prefer to do it piecemeal, testing along the way, rather than making giant changes and fixing dozens of bugs at the end. In the long run, I think it produces more robust code and provides the instant gratification feedback along the way.
For example, the latest change I’m making is to allow for sub-directories in a set of C files to be compiled in my application. I had assumed that there would be no need to have sub-directories (there weren’t any examples in the old code-base). To accommodate this, I needed to add new menu items, new file save and load routines, and ensure that they new files would compile properly. The easiest way to get started was to go to the end first. I added the information to my saved files and enhanced the loading code. I only took an hour or so to make the necessary changes and I knew that things would work. I proceeded to work on the UI and that’s when the fun really started. But, with refactoring and a lot more notes in my notebook, it will get done soon enough.
As Jeff Atwood points out, What’s the worst code you’ve seen recently? My own. Does this thrill me? No, but I’ve learned over the years to cut myself some slack. My code is no worse than anyone else’s, I know how to make it better, and I can morph it into a beauty.