Wille Faler’s Buzzword Bingo

A previous post raised a misunderstanding for one reader, thinking that I was somehow opposed to reuse.
That could not be further from the truth, I am by nature a “lazy” developer - I don’t like solving the same problem more than once and therefore always strive to refactor into a single unified solution when I come across a similar problem a second time. To me, writing as little code as possible to meet requirements is a virtue.

BUT, what I was railing against in my previous post was people trying to solve problems they don’t have, with “solutions” that have vague responsibilities and roles. To add insult to injury, people often try to justify these vague “solutions” by throwing around the word “generic” (hence the word in the post title).

If there are classes in a codebase to which you cannot clearly and succintly state what its responsibilities are, it is code bloat, I don’t care how much someone tries to say that it is “generic” and solves all manner of non existent problems, it is bloat all the same.

Many a years ago when I was just a young lad coming into development, a senior guy on my then team put me against the wall for some classes I had written and asked me (for each class): “What is it’s responsibility? What does it do?”. At the time I couldn’t answer the question succintly, and we rightly cut the code. Ever since, I have in turn asked the same question of people I have worked with when I have come across classes of dubious nature or purpose, almost always to good effect (either cutting the code, or refactoring to make responsibilities clearer).

As a rule of thumb, never try to solve problems you don’t have. IF (and that is often a big if) you eventually come across the problem you predicted - refactor.
99% of the time you’ll find it easier and a lot less effort to refactor a clean codebase to solve the problems when they come along rather than try to predict things you do not have a clear picture or understanding of.

Much has been speculated about the Credit Crunch’s potential effects on the wider economy - and I’m still inclined to believe that although the effects on the labour market might be negative, it will not be anywhere near as brutal as the aftermath of the dotcom-bust and 9/11, at least not for IT.

Personal, anecdotal evidence (the best kind*, as you can bend it anyway you want to fit your thesis..) would suggest that the IT market is actually pretty bouyant at the moment: in the last two or three weeks I have been barraged with more phone calls from recruiters than at any other time in the last 2-3 years, even though the last 2-3 years have been rather good.

* ..although quite obviously not the most reliable kind of evidence..

House Price Crash Calculator

..personally, I think a reset to mid-to-late-2005 prices seems reasonable, given current rental yields and credit conditions.

“Generic” is a word I have come to hate on software projects. Everytime I hear someone use the word “generic”, I pretty much instantly know that the person using the word is trying to solve a problem he can’t really define, because it is problem he doesn’t really have.

The same kind of bad smell and warning bells that go off should be sounded when someone uses the word “generic”, as when you find a class called ThisThatAndTheOtherManager in your codebase, because trying to do something in a “generic” way is a sign of the things I just mentioned: someone trying to overengineer a solution for vague problems that really don’t exist at the current time.

My firm opinion is that all solutions should be specific for the domain that they address - let me give an example: what does the generic ThisThatAndTheOtherManager really do? What problem does it solve? Is it clear to you? Probably not. On the other hand, what does the interface Comparable do? Even without knowing Java (from where the example comes), you can probably safely say that a Comparable can be compared with things, most likely other Comparable’s. That is a pretty specific, well defined task.
Sure, it doesn’t say a whole deal about how it compares itself to others, but that is where the beauty of object orientation comes in - you can solve a multitude of real, specific problems in the same domain, not by trying to create multipurpose objects that can be anything, but by creating encapsulated objects with tight, well defined responsibilities.

Any reusability comes not from being generic and multipurpose, but through having a small, well defined area of responsibility where the details of how that responsibility is carried out is hidden from the objects collaborators.
By combining objects with well defined responsibilities in different ways, you can achieve re-use because you have specific building blocks for your solution to a problem.
If you were building a house, wouldn’t you prefer to use nails and screws made for the purpose of putting up walls, rather than some blunt and generic “adhesive-put-things-together-thingy” that you didn’t quite know what it did or how it was supposed to do it?

So the next time you try to create a “generic” solution and solve problems you don’t really have or can’t really pin down, think twice about what you are doing. “Generic” is a swear word and an anti-pattern that merits a big smack over the back of your head if you use it.