I had a moment of reflection at work today, as I was completing a task.
During college, I was taught the power of Object-oriented programming and, among other things, the importance of abstraction. I had a good understanding of the theory of abstraction and what it did. I had a fair understanding of how to go about abstracting stuff only during my first job/internship. That project had, in my opinion, the most adequate use of abstraction. Not too much, not too little.
An ASP .net project, it had views with HTML, JS, CSS and some server-side tags, codebehind files that wired the data to the views, a Business Logic Layer (that was literally called BLL.vb), and a Data Access Layer. During the documentation of the project, I classified it as having the then-famous 3-tier architecture (MVC was just catching on at the time). It’s the most memorable project I’ve worked on, and the .NET platform blew me away.
Today, I realized the hazards of the overuse of programming abstractions. I was trying to refactor a project to adjust to changes made in an API’s response. The API had one additional field that needed to be captured and handed over to the view. The task entailed modifying the entire chain of layers from the model to the view. This chain of layers in my case wasn’t a lengthy one. But I asked myself, “What if I had abstracted things further?”
I’ve seen vast projects with thousands of lines of code with layer upon layer of abstraction, following the best practices of code ever thought of by man-kind. Yet, the code is fragmented into so many different layers, it is almost impossible to club it all together and get a sense of what’s going on. Not even my IDE can help me put the pieces together. These projects require vast amounts of documentation and code comments, so that the future members of the team could take over. But are these layers even necessary?
I strongly feel they aren’t. Code should only be as modular as required, not as modular as a book on Software Engineering or expert programming guidelines would like you to have it. We quickly submit to well-organized, deeply modular projects that contain millions of lines of code and accept them to be the hallmarks of Software Engineering. They aren’t. They often contain data being passed from one layer to another, with the layers in between doing nothing but passing data around. Elaborate Interface and Exception definitions do not spell out the formula for robust, testable, maintainable code.
Speaking of maintenance. I think this obsession people have about writing maintainable code is laughable. It’s 2012. Product lifecycles are short, and within 2 years, you’re expected to either work on a new product, or introduce features that can no longer be accommodated in the current architecture. Only portions of the current codebase would be of any use, and the layers of abstraction would sooner or later fall apart. While abstractions you create may help you maintain the product during it’s lifecycle and maintenance period, you will probably feel like rewriting the entire codebase once you hit a roadblock.
Projects should be architected to get things done, and not for detailed blueprints, specifications and diagrams of what is being built. Sure, that’s impressive to the average client, but that isn’t the soul of Software Engineering. Of course, I’m never going to find a firm that actually builds software neglecting code-quality or maintenance, but how I wish I could. Code, would truly be like poetry. Free-flowing transmission of a Software Engineer’s innermost essence. Alas, my next firm will probably adore me for writing thousands of lines of well-commented and documented code, with unit test cases, for displaying a “Hello World” on a Windows 8 desktop.
We tend to be attracted towards ideals, while losing sight of the purpose. The focus on solving the problem at hand gets lost in the infinite layers of abstractions. Limit your layers till the point you solve the problem and one more (for good luck), and not till the point you think your code will be maintainable for hundreds of years.
In a few years, we’ll all be fighting for oil, natural resources, and dive into anarchy anyway. Functional programming may just rule the roost then.





