The enemy within. A bleak view into the lack of regulation in the IT industry.
“I value simplicity
over everything; I always look for simplicity.”
Anders
Hejlsberg quote
As a programmer I love writing code. Make no mistake. I love flexing my mind and seeing if I can find a short and elegant route to the solution required to resolve a problem or satisfy a business requirement. The key words in that sentence are "short" and "elegant". What I mean by those words are that I prefer the fewest lines of code possible and I feel a strong need to leverage the available technologies in the most efficient and effective manner possible. Since I am a C# programmer, "efficient" means selecting the necessary 3rd party libraries or preferably using the standard libraries that come with the .Net framework that provide acceptable performance. "Effective" meaning they solve the problem in a way that produces the minimum amount of technical debt.
My favourite saying has always been "The only thing I enjoy more than writing code ... is deleting code." What I mean by this is that when I approach a legacy application in order to make changes to it or to update the functionality I keep a keen eye on attempting to identify the areas where I can delete unnecessary code.
This includes:
a) Code that has been is duplicated, not properly encapsulated into re-usable units.
b) Identifying areas where the wheel has been re-invented. An API or set of tools/libraries already existed that do the job in a more elegant (and probably more efficient) manner.
c) Identifying areas where there are unnecessary abstractions or layers of indirection.
I firmly believe that it is our duty as programmers to build maintainable and scalable applications which minimize the level of complexity within the code we write. By managing the complexity within the code we write we are able to handle and thus implement more complex business rules. This leads me onto the main reason for this blog post... The problem is that programmers admire complexity and sometimes over complicate solutions to gain "intellectual control" over the code they produce. The more difficult or complex a solution the more likely the business will develop a dependency on the developer that built that solution to maintain that solution, since they understand the solution the best and would require the least amount of time to make bug fixes or updates to the code. Management are unable to identify code that has been made to be unnecessarily complex, and when they do they are presented with reasons such as "The solution is re-usable" or "We might need that functionality for scenario A...", and needless to say scenario A is as inevitable as being hit by a meteorite.... Possible but highly unlikely.
At the moment the IT industry is suffering from the following symptoms:
1) Legacy systems that have been difficult to maintain and are undocumented.
2) Having developers take control of the core of the business by becoming dependent on the custom in house Software built to run the business.
3) Having no control mechanisms in place that will review code written by the developers.
As Billy Hollis rightly states
we are all code addicts as programmers, and we need to fight this code
addiction. We the programmers must avoid becoming the enemy within the organization and ensure our code is maintainable and well documented. I will attempt to provide a set of processes which management can put in place to avoid the symptoms mentioned above.