Programming Theory: Throwaway Code
Page is part of Articles in which you can submit an article
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.
Framework Hacking
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?
Getter Setter
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.
Model Boredom
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.
Conclusion
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.
permanent link. Find similar posts in Articles.
comments
I thing VB6 was sufficient. Does VB.Net really offer us more, or is it an attempt to fill Bill Gates pockets more? I don't know for sure, I'd have to write more .Net code. What do you think?
by mad bull 2008-Nov-24
VB6 is now like windows 95 - no support, no new hardware, updates or controls ( At least from the MS side). Your in the cold with that. NET is new and supported. You'll find your way around much faster and get more stuff done than with the VB6 stuff. Its the easiest way to go if you coding windows apps and sqlserver stuff.
by owen 2008-Nov-24
i argue that VB.NET gives you alot more. It's not very recognizable for simple applications, but when it comes to more complex applications and with a disparate programming team, multiple program language preferences, etc. It makes sense to have interoperability of .NET for one.
by alex 2008-Dec-09
I think STRUTS 1, was a major improvement for some people who where programming a lot worse before, at least STRUTS gave them some structure and helped them to move away from being simple novice programmers. STRUTS helped paved the way for STRUTS 2 and java server faces (JSF) by the observation of all the things that were wrong with STRUTS. So it did its job.
by alex 2008-Dec-09
I am a big advocate for throwaway code. For a couple reasons.
1. I like to deliver fast
2. I think the prototyping is a great way to analyze requirements
3. It's not as hard to refactor code once you get the hang of it and if you properly modularize your code from the get go
4. The more time you regurgitate a problem the better solutions you come up with
As an aside, I think that automation and tools are a great way of minimizing the burden of not only writing code but of throwing it away!
by alex 2008-Dec-09
It really is important to choose the right framework. I especially like frameworks which allow me to write code in such a way that it could be easily ported to some other framework or use.
To borrow from .NET theory, I would say its always advantageous to use class libraries and worker classes that know as little about the framework or application controller mechanism as possible. This allows the classes to be easily stripped out. For that reason I tend to keep my controllers in an MVC framework very short and offload the majority of the work to other classes.
I also tend to like using dependency injection so minimize the ties between my code an external resources.
by alex 2008-Dec-09