March 9, 2016

Experiencing technical debt

A 21 year old's hot take on technical debt in programming.

In many metrics, I am young. I am 21 years old and fresh out of technical college with my A.A.S in website development. I am young in world and workplace experience as well as wisdom. I physically look young. I am told I look, on average, approximately two years younger than my current age (this has been going on for at least four years now). I am a young programmer, having only been a part of the world of code for three years. My coding style, abilities, and knowledge is limited. I am young.

However, though I may be young, in many ways I am not young. I have coding knowledge that earned me the nickname of a reference guide among my internet friends. I have coding abilities that, even as a one year programmer, impressed a then-four year programmer.

I have also seen with my young eyes sights often only experienced developers speak about. I have experienced within my limited experiences events only programmers of age understand. I have knowledge of things I probably did not need to know and sometimes wish I did not learn until later.

One of those things is technical debt.

Technical debt, in layman’s terms, is simply junk that exists in a system that should be cleaned up because it is a mess, is getting out of hand, and is giving you a headache but has yet to be dealt with. It may lie in the build pipeline, in code, in graphic creation, in documentation, in tools and workflow. Wherever it is, it is something that is not good and should be corrected to meet modern standards, guidelines, or ideals. Yet nobody has done anything about it for so long (for a variety of reasons) that the debt has become part of “it is just how things work around here.”

Another way technical debt can accumulate is through lack of knowing what you are doing. I most often see this method though a common scenario:

In regards to getting a website for our business, we have hired this person to make one and set it all up. When they are done, we will have full control over it and can do whatever we want with it. We do not have anyone who really knows this stuff, but since this employee is very knowledgeable with a computer, they can manage most of it and the rest of us will learn as we go and play it by ear.

Because there is a lack of experience and knowledge of how everything works and goes together, technical debt quickly incurs. Planning and foresight is not available, thus inconsistency develops. Knowledge of what is needed to handle a small hole is not present, so a board is slapped on it. Existing abilities are not evaluated or understood, so duplicate features are available. Discernment over what is and is not needed is not performed, thus links and prompts are blindly clicked and unneeded stuff added.

Recently, I have been experiencing the debt incurred by this scenario. I was given access to a small church’s website and social media. In the months to come, it will be my job to manage everything, keep it all up-to-date, promote the promotions, and maintain the site. One of the more immediate plans we have is to completely scrap their current website and build a new one. Until the new one is ready, the current site will be slightly maintained and updated.

As I am out of a laptop for a while and cannot begin prototyping the new site, I have been looking into the current site’s issues and what can be done to resolve them. The set up is rather typical: Bluehost shared hosting and WordPress. I have had a personal blog for over four years and have worked with self-hosted WordPress on a number of occasions, so I know how to manage a WordPress site rather well.

Upon logging in for the first time, the technical debt that has occurred since the site was created in 2010 (at least from what I found) greeted me like a wall. It was clear the person put in charge did have some, albeit limited, knowledge of WordPress management for it was not a total disaster, but enough to make me sit in amazement for a bit. I was immediately drawn to the installed plugins: 25 total, 21 active, 2 inactive, 1 “must use”, and 1 “drop in”. 9 of them had updates, majority of them multiple versions behind. I found two different plugins that created a “mobile version” of the site (both unneeded, as design is responsive), two different SEO managers, a ton of extra widgets, as well as shortcodes, visual editors, a “firewall, anti-virus, and cache” combo, and a suspicious “must use” character simply named “SSO” that lacked a description or website for more details. To keep things brief, it took me two days to carefully go though the majority and determine what was good and what needed to be tossed. The grand total is currently 10 plugins, 7 of those active. Had there been knowledge and discernment in what was needed, this technical debt, which affected the live site as well, would have never been seen by my young eyes.

I also went through the site pages, pruning the junk, removing and updating content long out of date or incorrect, even correcting typos on the index. I rearranged the site navigation to be more clear. I moved copy-paste content into the site footer, fixed URLs (the about page was /sample-page/), revised internal WordPress options, and vacuumed up an awful lot of other mess lying on the floor. For two days of work I managed to get a lot done, but I still have more to deal with. I still have more technical debt, occurred by lack of knowing what needs to be done, to experience.

I have also battled technical debt in my own works. Right at the beginning of my programming walk, I picked up an abandoned plugin for some software and began maintaining it. However, the original author wrote it in such a way that is is literally impossible to implement certain desired features or fix annoying bugs. Changes I made to it in the early days do not make matters easier. It has gotten to the point I am slowly, section by section, identifying parts of the plugin, writing new code away from the old, then ripping out the old code and plugging the new API into the gaps, adding compatibility methods (earmarked for eventual removal) where needed. In the few areas I have redone so far, the plugin works better than ever, but the overall technical debt is so strong it takes a long time just to do these small areas.

I may be young, but technical debt is an experience I am already seeing and learning from. At times I wish I did not have to deal with such mess and always keep moving forward. Yet, even if you plan out the entire project, you will always incur debt, knowingly or otherwise. The more you code the more you learn, and the more you learn the more you understand what is good and bad. In three years I have individually developed over 40 different projects and applications and contributed to numerous open source projects. Code I wrote a year ago I may now perceive as bad. A lot of this bad code I will never touch again, but for the stuff I do, as I work to repay what I borrowed, I am thankful for the bad code. I am thankful for the impossibilities. I am thankful for the mess of plugins. For without the experience I gain cleaning it up, I will never learn what good code is like, how it looks, and how to write it. Lacking understanding of the pains of technical debt, I will not know what others behind me may have to deal with. It is in these fires that I become a better programmer and learn the most.

Age is only a number, but the youngest have the most to learn. Yet even the young can know what their elders know, and the inexperienced can have more experience than expected. All it takes is the right amount of (technical) debt.