I don’t know about you, but when I first sit down to design a program or web application, I have an idea of what I want it to do. As I proceed, I think of features I can add which will add to the flexibility of the design. The problem is that every feature you add for that purpose adds layers of complexity to your design, and masses of code to the code base.

For example, if I’m working on blog software and I add “categories” to it as a new feature, I now have to add some way to view, add, delete, edit and connect those categories to each article. That means a new screen for each of those capabilities. Plus possibly database/model code to handle them. This multiplies a lot. And often you find that you don’t really need that functionality anyway, you use it so seldomly.

I recently had this issue with my blog software, Grotblog. Originally, I had Grotblog using flat files and sequentially named directories for each post. Eventually, I realized these were bad design decisions, and I needed to refactor the software. The idea was to use hashes for filenames, and store the hashes in a SQL database. Some time back, I had written up a data dictionary for the software, so I copied this into a PHP file and starting looking at the design. I started considering some ideas that I had had when I first designed the software. For example, I kept track of the number of comments per post. Now I started wondering who cares? It’s not a number I ever really looked at, and I doubt anyone else would be interested in either. So there’s a feature that goes into the bin.

The more I looked at the data dictionary, the more I realized that some of this stuff could be taken out of the database, and inserted instead into a configuration file or two. Taking something out of a database and putting it into a config file meant that I no long had to provide screens for it. And didn’t I say from the beginning that this software was for someone who was willing to write his or her own HTML and such?

As I continued to examine the dictionary, I realized there were a lot of features I had added for flexibility that weren’t really needed. They could be added later, if needed. As it was, I was looking at a lot of time refactoring things. If I could eliminate that time and effort and stick to essentials, I could save myself a lot of grief.

The more I thought about this, the more I realized that I did this on most projects. I started out with a maximum of features designed to add flexibility and ease of use. And then spent months coding all this stuff. Instead, I thought, wouldn’t it be better if I started with a minimal feature set and then add on as needed. This would also allow me to use the software and determine if I really wanted a “flexibility” feature or not. Perhaps something I thought I wanted or someone else might want was actually something no one would notice if it were missing.

So that’s my lesson for the day. For a new project, figure out the minimum feature set you can tolerate. Then use the software, and look at any comments you may get from other users. What’s worth adding? Of course, if you can, provide for the possibility of other features as you go, but don’t add them early on unless they could be considered “essential”. Design the code with simplicity in mind. Add flexibility (and therefore complexity) only as needed later. Version numbers never get less, and you can always increment them in the future.