written by owen on 2008-Nov-23.
In today's age of new programming languages, frameworks, templates, RAD tools, MVCs and things that pretend not to be MVCs. A new productivity demon has emerged. Marketing is promoting easier and easier ways of rapidly creating stable enterprise applications that basically write the code and make your tea at the same time. At the same time when the adoption rate for the new paradigm is low they seek try desperately to win over new and old programmers with exciting new buzzwords without offering any really new solutions to old problems. Programmers are spending an incredible amount of time writing what I have coined as "Throwaway Code". Often referred to as scaffolding though this not directly what I;m referring to in this article. This article is largely about code lifespan, reuse and its general usefulness in future projects.
The "Throwaway Code" that I'm referring to is the code that;
- exists for no other reason except because of some lacking feature in your language. aka The missing feature.
- is tied to a specific framework and will be useless once they find a better way to do it. aka Framework Hacking.
- is useless design pattern code. aka Getter Setter
- gets boring fast. aka Model Boredom
Now I will explain each of these scenarios.
The missing feature
No programming language is perfect and anybody who says that their programming language is perfect clearly has not written enough code to have a clear understanding of anything that can be considered "perfect". Each language has their strengths and weakness. There are often times that you get stuck with a language such as COBOL and you have to write a million lines of code just to print out a table. When in a different language the same code could be written in 5 lines. There are times when you can hack your way into the language in order to get what you need but this is not always possible because sometimes the feature you require would need to be well supported at the lowest level of the language. You will only notice instances like this if you have experience with other languages otherwise ignorance is bliss. Time spent casting variables that the compiler has sufficient knowledge about could be spent writing ACTUAL USEFUL NEW CODE. In time the language will implement the feature and your hacked code will be a memory of times gone by.
I often look back at STRUTS 1 and wonder how could anybody EVER think that that was a good ideal? Though when you think about it frameworks are written by humans and humans make mistakes from time to time. Point is all that struts 1 code is now useless. Besides the things you learn from it, the code itself is useless out of its "struts context". All those lines of code are now replaced by newer, faster and smaller code. Very little of it can be safely ported into something else. So basically that code you spent hours carefully putting together is now trash, "throwaway code". Even the sections that you had cleverly custom hacked/coded where all in vain because they were all tightly tied to the framework, solving problems OF the framework rather than problems that evident in the wider scheme of programming. This is another point to note when it comes to frameworks; alot of time is spent hacking at the framework, it cannot really be seen as programming but more like patching holes in a pot. Because if the pot was good at the beginning then your time would be spent writing LOGIC CODE as opposed to hacking/scaffolding problems in the language. Of course
you may say programming is all about hacking away at useless things for hours on end trying to solve a problem. However when your hacking away at scaffolding do you really learn anything? Except maybe the intricacies of a not so perfect framework?
Now the problem of useless design pattern code seems to be popping up ever so often nowadays especially in OOP. OOP seems to be eating alot of its own dog food. I tend to see the programmer writing code for no other reason than to make it easier for the tools that they use, so that the tools can generate more code for the programmer to write. I've mentioned this before. Point is depending on where you are in the evolution of a language/framework there is alot of code that you'll be writing "just-because". I remember concatenating strings in C. Although ignorance in bliss, there are things that you really don't need to do. Having to cast-type the same thing 4 or 5 times in the guise of improving maintenance and extensibility is nonsense, its redundant. There is always a better way to do things. It often becomes evident after the language is replaced with something new. At this point there is a great enlightenment "omg version 3 is so cool". But no one will admit that version 1 sucked all hell - ESPECIALLY when its just out of beta. Its not even about evolution, certain basic programming paradigms are being ignored or hacked around. Singletons anybody? Even auto generated code has crazy drawbacks and redundancies that pop up only during maintenance.
I've only noticed this in one case with one particular language. It seems that with MVC programmers become obsessed with creating a web of models, deleting them entirely and then re-creating them again. As if they are never satisfied with the model OR maybe its just too boring to update OR some new feature comes out that requires a total re-thinking OR maybe they are just get sick of it entirely after a year of playing with it. These model changes are usually not evident because the output is usually not affected. I will have to look into this more but your opinions on this topic are welcome.
Programming is becoming more and more abstracted and as a result much of the code written simply exists as scaffolding. Soon to be replaced by the next big iteration or framework bug fix. In reality it may be nothing new, a right of passage or growing pains. But one thing is for sure; the bigger the API - the greater the chance that 90% of your code will end up in the recycle bin or frozen in time, waiting to be re-factored.