A company’s software assets are not its codebase, it’s the programmers who know what the problem is. On the balance sheet the code is a liability rather than an asset, and it’s not even the good kind of liability because 90% of all code is the kind you don’t want: it has nothing to do with the business problem itself, it just sets things up for other code that does. You can pay millions of dollars to have this “overhead” code written, and a month or year later it’s all rendered obsolete by an upgrade to the platform–and not necessarily your chosen platform, either.
Years ago I used to work for a company that made a web-based case tracking system for police agencies, and we spent thousands of developer hours writing code that processed templates to build HTML forms, serialized data to-and-from the database, and converted complex searches into SQL. We also wrote our own code for user authentication, session tracking, and our own federated remote query system. All written in Perl in the late 1990s and early 2000s.
With some awkwardness, a cop in Arkansas with a sometimes-online dial-up AOL account could search for the connections between a VIN and a gun’s serial # on a database in a neighboring state, and everything got ferried through email with PGP and XML. After 9-11 I even coded up a way to display the Department of Homeland Security’s multi-colored alert level in the UI, writing my own RSS parser along the way.
One day while standing around chatting with a manager, I said “what if Microsoft replaces ‘Northwind’ with a police database in the next version of Access? We’d be wiped out in one stroke.”
Specifically it wasn’t Microsoft Access we had to worry about, but Ruby on Rails that provided 99% of all the infrastructure we’d built ourselves for an HTML-fronted database application. Even if our idea of a case tracking system was superior, 99% of our time had been spent to build a platform upon which that product could be built. But in the end our customers didn’t care what kind of template processor rendered all the web pages, which meant a competitor could have duplicated our whole product at a fraction of the cost once all of those web application primitives became available for free.
There is nothing that can be done when an existing framework doesn’t have an abstraction for the feature you need to build, except to build that abstraction yourself. In the late 90s there didn’t exist a single framework with the right combination of features that we required for our product, so we had to build our own. The tragedy is that the product was a bas relief on the surface of that monstrous framework and completely inseparable from it, so when RoR came along it wasn’t possible to port our “business logic” over without rewriting it from scratch.
When you are writing your own code you must think about which lines are directly manifesting the program’s purpose, and which lines are only there to provide what wasn’t already in the framework, language or operating system. Some code must be written to be independent of the program’s function and some code must be written to be independent of the program’s form.
When this site and others exhort you to simplify your code, keep “business objects” pure, and to write as lucidly as possible for the benefit of a stranger, it’s because one day the function of that code will have to be ported into a different form, and the only way that’s ever going to happen is if the real asset of the company–the programmer–understands what the function is and the problem its trying to solve.
This is why naming is everything, why code conventions are important, why Model-View-Controller is recommended, and why functional style is adopted. Even replacing for-loops with list comprehensions helps because it boils away another overhead variable–the index pointer–and leaves a little bit less to port and maintain. Every line of code is a user interface and needs to be designed and tweaked and tested the way user interfaces are; for comprehension, flexibility and intuitiveness.
Now that police database system is history and another waste of taxpayer dollars. When the support contract wasn’t renewed the paychecks dried up and the company’s real assets took jobs elsewhere. What was left wasn’t an asset, it was unreadable.