Making a piece of software more generic is tempting to programmers. But it isn't free.



I have noticed something about the way I think. Whenever I think of a solution to a given problem, my mind starts wandering off looking for a more general solution that will fit a more general version of the problem.
I enjoy this feeling, it is intellectually challenging. I consider myself a decent programmer and I think that to some degree, this habit is either the cause of or an effect of this fact. Talented programmers have the ability to redefine problems - in more general terms and in particular, in simpler terms. There is always a better and more generic solution which is almost always more interesting to create and possibly a good investment as well. But tempting as it may be, there is a cost and it is something that I need to remind myself of frequently.

I was recently working for a customer that had a very large database of clients. At one point, they needed a list of clients that matched a certain number of criteria's. A simple (well it was quite complex but still) SQL query, and I would be done. Simply handing them the output would be the least generic solution to the problem. However, I asked whether this was something that was likely to show up again and it turned out that it was. So I hacked a minimalist winforms app that could perform the query. And because they might need to fetch old data, I made a date picker on the form, allowing them to choose when the data should be from. A little more generic and a wise investment. I spent about ½ hour making this app and I am sure that this ½ hour would quickly be spent by me or somebody else real soon. But I could have made it more generic (and indeed, I did consider this). It could be customizable in all kinds of ways, applying arbitrary filters, outputting in various formats and so forth. If one extreme is the hard data, the other, I think, is Turing completeness - where you have a programming language that gives you all the possibilities that the computer offers.



So besides from the fact that making something more generic takes more time, are there any drawbacks? Surely, more generic == better, right? Well, I once wrote a blog entry entitled "Good things about hard coding". This was obviously meant in a bit of a provocative manner but my point was and is that there is a cognitive cost to generic code as well as an economic.

Quick, tell me, what does a FilterItem do?

Say that you are making a program that needs to manipulate some data that comes from a file. You may then have a FileReader class which reads your file and deserializes the data. Good. But then you figure out that this data might as well come from a database. So you make an abstraction called DataProvider, of which FileReader becomes a specialized version. It's beautiful and generic. However, if I look at the code now and I am not the author, the term DataProvider is a little more abstract than FileReader would be. I can sort'a tell what it does but where as the term FileReader is quite self documenting, the more abstract term DataProvider is a little less obvious. And the more layers of abstraction that you apply, the vaguer the self-documenting effect becomes. You end up with functions and classes that are named with combinations of terms like stream, container, input, output etc.
In my opinion, you should strive for generic code, but only to the point where it actually saves you from duplicated code. The way I try to achieve this is by constantly making vertical slices, or breadth-first development - moving to the right on the genericity scale every time I spot duplicated code.

By Kristian Dupont