Well now. Here is a thing. The thoughts that will be (briefly) laid out here were going to be the basis of a talk I was going to give (had I got round to it) at a conference over the sea somewhere. I didn’t get round to it, I took up LondonWorkTakeTwo, and it fell by the wayside. Of course, the seed was still there, and has been for the past oh, five years. As I grow ever more disgruntled with the statements of others.
Having said that, I have submitted the germ of the seed of the idea to a free workshop day in that London, but it may be too frivolous to fly there, given it is only a day, and I intend it to be light-hearted, but with a definite undercurrent of malevolence. Much like me, then. Without the light-heartedness. Or indeed the undercurrent.
But let me be short for purposes of outline. Abstractions and frameworks. Programmers love them. And, at a time, so did I. Always trying to solve the problem in the most generic way, in a pleasing and elegant fashion. (Quiet at the back.) Although now, here and now, it has all gone too far, and while I have come to this conclusion, it seems the world and his coding mother have strayed further towards the Platonic instruction set.
It gets worse, though. Those who are falling into this trap seem to mostly come from the Agile camp. (OK, quite self-selecting, as I have been working with said types for a good while now.) But really, it all comes down to premature optimisation.
Programmer A has itch to scratch, problem to solve. He solves it. Job done.
Programmer B has a problem to solve, and scratches the itch. However, being somewhat of an enthusiast, decides to make the solution generic. Before he has solved his problem, as, you know, abstracting this out, making that a bit more generic, sure won’t it save time in the long run. We spend a bit extra now, get something sweet, and apply it to our problem. Job done. In more time.
Programmer C has an itch to solve, problem to scratch. He thinks. He ponders. Then he makes Yet Another Framework to solve all the range of generic problems he thinks might occur, one of which is his own, maybe, because you know, if his makes this kewl he can release the code, so others can benefit. But he has to make controllers and models, and special cases and derivatives, and shoehorn it all back in to solve the original itch. But the world loves this, and he gets lauded. Job done. In an age.
See, I have come to think, that really, you solve your problem first. Bugger the making it generic. The problem you are trying to solve isn’t generic. You know what you have to do. Where you need to be. So just do it. Make it work. If the problem raises its head somewhere else, in a slightly different form, that is the time to try and see what the commonality is, start on a generic solution. Not before. With one problem, making some generic answer is an absolute nonsense.
On to programmer D. He has an itch in a different place, and has been swept up by the evangelism of Programmer C. Thinks this framework is just the knees of all those bees. But here is the thing. No framework is perfect, and most were written to solve the generic solution the author thought of. Which in all cases isn’t. It was written with the predujices and colourings of the author in mind. If you have the same problem, which Mister D doesn’t, then all is fine. Otherwise, you are bending the framework. Not extending it. Not showing how extensible it is. If you don’t have the same problem, I say again, the framework is a nonsense. You will spend your time fighting with it, rather than getting to the core of your issues.
Coders are like that, though. They love to try and see behind the problem, to have The Answer. Well, for all your vanity and clever tricks, I guarantee your code will be rewritten within (at most) a decade. Some new technique will come along. Some new way, some new paradigm (nnnnnnnnn). In the past decade, procedures have come a long way, but mindsets haven’t. Your code, and mine, will get left behind. Sent to /history/null
Please. Solve your problem first. Don’t foist your previous solutions on to me. And don’t do it by stealth. That is worse.
Then we get to the whole meta object protocol. I can see the point, of course I can, in the same way I see the point of frameworks. I amn’t saying they are bad per se. I am saying if I have the same problem as the author had, I would use that to solve it. Invariably I don’t. So please, quit with the telling me what you have will sort my scenario out, make it faster, easier to maintain and all the other bland and irritating platitudes all jumped-up self-aggrandising solution-to-your-coding-ills types have been harping on about for ages.
Just solve the problem you have. Don’t worry about the next one. For all the claiming to do the iterative Agile schtick, you seem to forget it the minute you open emacs. But that in itself should have been the warning sign…
