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.