Reducing Technical Debt in Web Development

With a degree in computer information systems from Mohawk Valley Community College, John worked for small businesses and performed freelance work before joining Site-Seeker in 2007.

Before I get into why it’s important to me to avoid technical debt and why it should be important to you, it’s important that you understand what it is and some of the reasons it happens. I’m going to cover some of this information, but I’m not going to go into all the details myself because, fortunately, others have already done this. “Technical Debt 101” is a very good explanation of what technical debt is and “The Three Sins of Software Development” goes into some of the causes of technical debt. I suggest that you read both of these articles.

For those that don’t want to take time to read the articles above, technical debt refers to the increased cost of maintenance and modifications to code (your website) in the future that come from cutting corners, using the wrong method and not doing the work well from the beginning. Just like any other type of debt, there is interest associated with technical debt that you incur and you’ll eventually need to pay the debt back in full.

Why Does This Matter to Me?

Here’s the one, most important thing I’ve learned about websites after working in web development for more than 20 years. They need to be updated and modified often. You don’t just build a site and then forget about it, at least not if you want it to be successful. Technology in web development changes fast. SEO requirements and SEO methods change even faster. If a site is built well then changes and updates can be made quickly and efficiently. If a site is not built well then changing it could mean that you end up paying more to get the changes made than you really should, or even worse, that you’ll need to rebuild your site again from scratch.

I enjoy complicated work, but I don’t enjoy frustrating work. If I need to spend more than a few minutes figuring out where and what needs to be changed because of over complicated code, then I get frustrated. Not so much because of the difficulty, but because of the time involved. Why do I care about the time you might ask? Because I usually have 10 other projects that need to be done and 20 other people wanting me to get to the projects that are important to them. Time is the single most important thing in my life. I hate wasting it. Once time is wasted, you can never get it back, it’s gone forever.

Another reason that this matters to me is my integrity. Maybe I’m old school. Maybe I worked in QA too long in a previous life. Whatever the reason, I feel that the client should get the best possible product that I can give them. To do less compromises my integrity. I’d rather face the consequences by doing what I think is right than to compromise and do what I think is wrong. I am open to new ideas, but I insist on validating those new ideas before I put them to use and I generally discard anything that I think is a waste of my time.

Why Do Websites Generally Include a Lot of Technical Debt?

When most companies go out looking for a developer to build their new site, from what I’ve experienced, the most important thing to them is “How Much Will it Cost?” and they only focus on the initial cost. Rarely do they think about total cost of ownership. They will, more often than not, hire the guy that will get it done the fastest and will do it for the lowest price. They don’t care how it will be delivered and never think about how this will affect what it costs them later on.

Meanwhile, these developers that work at cheap rates and promise to do it faster, need to use tools and methods that increase their efficiency and speed. This is the only way they can make a profit: building a lot of these cheap sites as fast as possible. They do not concern themselves with how difficult these sites will be to maintain or modify. Most of the time, they won’t be the ones that have to do it. And if it takes them longer to do the job, then they’ll get paid even more, and they really don’t care how much it’s going to cost you.

Another reason that developers use the tools and methods they use is that many of them do not have enough experience to build sites without them. These tools make it possible to get a minimum acceptable product from all web developers from neophyte to fair. They are also brainwashed into believing that it’s the best way and once adopted they never question the choice.

The developers are not always entirely to blame though. In many cases, the developer’s employer, usually someone that knows nothing about what proper development should be or look like, insists that they use these tools because they are popular, they are the latest fad and/or trend, or because “everyone else is using them” (which of course, as we all know, is the best reason to do anything) or because they need acceptable from developers that are incapable of delivering quality without it. In some cases, the developers just don’t know any better, or they use the same poor reasoning to justify using them. In other cases, the developers do care and would rather not use these tools but they are not in a position to change it or they’re scared of losing their job if they rock the boat.

I want to take the time to cover an example of this that recently occurred to hopefully emphasize what I’m talking about.

Recently, we had an older site that was not responsive (mobile-friendly) and the site needed to be updated. The client did not want to redesign or rebuild the site. I looked at the site and estimated how long it would take to make the modifications. All that was really needed was to tweak a little HTML, tweak the existing CSS, add a mobile menu and then add some additional CSS to deal with narrow screens. The coding on the site was simple to understand, I thought.

At the time the changes needed to be made, there was too much work for me to do, so we looked at outsourcing the job. When we got the estimates from the developers we contacted, they had given us quotes that were 4 to 5 times what I had estimated. Why? Because instead of just changing what needed to be changed and adding what needed to be added they had all given estimates for completely rebuilding the front end of the site in whatever method it was that they used for building new sites.

I can only think that they simply didn’t understand how to do things any other way. To top it off, the estimates were all at least twice what I would have estimated to completely rebuild the front end of the site if that had been necessary. What really bothered me the most was that they all wanted to do this rebuilding in a way that completely disregarded Site-Seeker’s development guidelines and would have increased the work needed to make additional modifications in the future, using tools and methods that we do not want used for this very reason. In the end, I needed to find the time to do the work myself in order to prevent both the client and ourselves from incurring additional, unnecessary technical debt.

What is The Effect of Technical Debt on Total Cost of Ownership?

Let’s take a look at what generally happens when a site is built in ways that make it more complicated to work on in the future. As I’ve said, I’ve been building and maintaining websites for a long time and I’ve gained a bit of understanding of the life cycle of a website.

Please excuse the crudity of these graphs. I didn’t have time to draw them to scale, or paint them…

Model 1: Build, Ignore, Repeat…

This is the model I’ve seen most often. The client has a new site built and once completed they do very little with it. They make no changes. They make no updates. No effort is made to keep up with the current pace of technology. Sometimes I think they believe that a website will continue to work indefinitely, and by working I mean that people in the world will actually find it and the site will bring in some type of business, whatever it is that the owner is selling.

But this isn’t how it works. Eventually something will change that causes this site to no longer show up when someone is searching for what the owner wants to sell. Features just stop working or just look extremely bad because browsers stop supporting the technology used to build the site. It’s usually a combination of these.

After the long period of neglect, the site owner finds that it is more cost effective to start over than it is to try to bring the old site up to date.

The site owner does not learn from the experience and the cycle continues.

Model 2: The Money Pit

In this model, we start out with a lower initial cost, the owner saved big by bidding out the job and went with the company that came in the lowest and promised the fasted turn-around.

Once the site is launched, effort is made to maintain and update the site on a regular basis, but the maintenance and improvement costs continue to rise until these costs exceed the initial development cost. Sooner or later, the owner decides that they don’t want to keep throwing money into the pit and they start over.

My experience is that they usually haven’t learned anything from the previous experience. Instead, they go out and get the lowest and fastest again. The next cycle can actually be more costly than the previous round because they want to keep all the great features from the current site and just want to make it work better. This causes the developer that builds it to cut even more corners to get it done under an unrealistic budget of time and/or cost.

Why does this happen? There are too many reasons to list them all but I will outline a couple.

One reason could be that the developers that are maintaining and improving the site are not the same developers that built it. This has nothing to do with the skill of the developer that’s doing the maintaining. In order for the maintainer to work on the site, he needs to figure out what’s going on and understand how the code works. This happens every time that work needs to be done, even when you’re the person that did the original work. The main difference is that the person that built it already has a general understanding of how the site works and where to start looking. The developer maintaining the site could also be at a disadvantage because the tools and methods he uses are significantly different than the ones originally employed to build the site.

Something that could contribute to the above and is also a problem of its own is that the code is simply overly complex.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?”Brian Kernighan

The problem is that there are too many clever developers writing code that is too hard for other developers, and even themselves, to figure out later. There are also too many developers copying code from clever developers without understanding what the code does. Good developers understand this and have learned to do things in a way that they won’t have a problem understanding in the future. They’ve learned how to write code they will be clever enough to debug.

“Simple can be harder than complex.” Steve Jobs

Any time a developer works on the site they are in essence debugging it. They must understand how it works to make changes to it. Overly complex code takes longer to understand. The increased cost is not caused by needing to do more work, the increase in cost comes from the added time needed to figure out what needs to be done.

What Should a Total Cost of Ownership Graph Look Like?

This graph shows what I think total cost of ownership should look like and what I think is possible if you want to expend the effort.

You achieve this by first choosing a good engine or platform to build your site on and that drives it, like WordPress. It needs to be easy for the average person to use in maintaining the site. The system you should choose should also be something that will likely be around for a long time. Once you choose you should stick to that decision and not change because someone else thinks you need to change.

The next step is to find a developer that understands that platform well, not just someone that gets by. It doesn’t matter what platform you choose, but you need to choose one, and then you need to find a developer that is an expert in developing on it. The developer your choose also needs to know what should be avoided and you need to know what should be avoided and make sure that the developer follows those practices.

The final step is to have a solid plan for what you want the site to do and how it needs to work to accommodate your business logic.

Once the foundation is in place, and is built to handle your business logic, and it is built well, the foundation should never need to be replaced. Features will be easy to add and the public facing website should be able to be changed without needing to go back to the beginning.

The initial cost of building the site may be slightly more and it may take a bit more time, but if it’s done well, it should never need to be replaced with something completely new. You’re not going to tear down and rebuild your business and do things in a completely different way, why would you want to do that with your website after you’ve invested time an money into it?

Site-Seeker wants to be a long-term partner for your business. There are much more important things, like marketing your website, that you should be doing once your new site is launched. If your site is built poorly then you’ll have to focus too much of your energy and time on that instead of putting it into those other efforts.

At Site-Seeker, we have chosen to specialize in building and maintaining sites using WordPress. The reason for this is the same as the reason that you need to choose a platform and stick with it. When you focus on one thing, you can become an expert in that thing. You know what it can and cannot do, you know its limitations and you know exactly what needs to be done to make it do things. Can we provide some services for other platforms? Yes, we can. But if we’re building a site then we will build it in WordPress. If you’re looking to have a site built in some other platform then you should find an expert on that platform. If you’d like, we can help you look.

Things to Avoid

Most of what follows could be considered just my opinion, but I’m going to try and back up my opinions with facts that I know from my own experience dealing with the things I think should be avoided. Many of my opinions go against the majority, but just because everyone is doing something does not mean it is the best thing to do or that the reason they’re doing it is in your best, long-term interests. I have never been a short range goal type of person, or a person that does what’s best now if it will mean that it ends up costing me more in the long run. I’ve also never been one to do something just because everyone else is unless I have proof that it’s the right thing to do.

Frameworks

I’ve posted in the past about my feeling on frameworks. Here are some facts about frameworks that cause them to increase technical debt.

When I talk about frameworks in this instance, I’m not talking about building computer applications, I’m talking about building websites. The problem starts when programmers try to apply the principles of computer application programming to building websites. On the one hand, you have an application that will rarely go through drastic changes and on the other you have a website that may be changed drastically on a regular basis. I think this is a simple fact that the creators of these frameworks fail to consider.

Frameworks are built by clever people trying to do things in the cleverest way they can think of or that are trying to apply principles to website development that should not be applied. This makes the code more complex, actually extremely complex and obtuse at times. This is okay as long as you only want to do what the framework lets you do. As soon as you want to do something differently than the framework does, or you want to add something the framework doesn’t, you have a problem. Sooner or later, everyone wants to do something that the framework does not do. You can either compromise and live with what the framework does or you can invest the extra time and money to have someone figure out how to change it or add it.

Frameworks are generally unnecessary to anyone that has a lot of experience with the core language that they are designed to make easier. Some people believe that frameworks increase the efficiency of building a site. In my experience, they do not, or they do not if the person using them has enough experience with the core language. Using a framework will likely take just as long to figure out how to do something as it would take an experienced programmer to do in the first place. Using a framework does not, from my experience, reduce the amount of code that needs to be written, it only changes how the code is written and it’s complexity.

Once you use a framework, you are married to that framework. Should you ever wish to get a divorce, you will need to start building the site from scratch, especially if the framework is used for any features of site administration or business logic. This means that you will be limiting what future modifications you can make to your site. Should you decide to remove the framework but you want to keep specific functionality provided by the framework, that functionality will need to be rebuilt.

These are just the things that cause technical debt. I’ve said nothing about the other problems associated with them like code bloat and performance.

My advice would be to not use frameworks, ever, unless you want the relationship to be permanent and you can live with whatever blemishes and limitation that they have. I can’t make that decision for you, but if you take my advice you’ll ask any potential developer if they use them or you’ll insist that they don’t. Yes, this goes against all the popular beliefs, but you’re not looking for a developer that needs these crutches to get by, you should be looking for a developer that realizes how limiting they really are.

A good web developer needs to understand just five things well:

  1. How to use the core code of the CMS that is being used
  2. How to code in the language the CMS is built in
  3. HTML
  4. CSS
  5. JavaScript

Premium WordPress Themes

I’m sure there will be more than a few people upset by me saying that you should avoid premium WordPress themes. Before I tell you why, let me just say that this does not apply to all premium themes, and it may even apply to some of the free themes you can find. I personally lump these into one category I call “Pre-Built.”

The first thing you need to understand is that a lot of pre-built themes are built using WordPress theme frameworks, see the section above.

Even when the theme is not built using a framework, the theme may add functionality to the site. If it does and if you ever wish to switch themes in the future, you may lose those features. You’ll have three choices.

  1. Rebuild the site from scratch.
  2. Build the features you need to keep into the new theme, increasing the cost and increasing the amount of work that will be needed the next time as well.
  3. Find another theme that adds exactly the same functionality, drastically limiting what you’ll have to choose from.

The second thing that pre-built themes do is limit the changes that can be made to them. Pre-built themes are updated by their authors, or they should be, when there are changes in the way WordPress works. If changes are not done with care, then your site may break when these updates occur. In addition to this, if any custom functionality is added to the theme and you decide to change themes, all of that custom functionality will need to be rebuilt for the new theme.

Pre-built themes are not something that should be avoided altogether, they are something that should be chosen with care.

CSS Pre-processors (SASS, LESS, etc)

Here’s another one that I’ll likely catch flack over. I’m not going to cover what a CSS pre-processor is other than the basics. If you are interested in reading about what this is, I suggest reading this article: Sass And Less: An Introduction To CSS Preprocessors.

So why do I think these are bad and increase technical debt? Well, the first reason is, once again clever developers trying to do clever things. CSS is not and never has been a programming language. CSS is a very simple way to style a website. CSS predecessors over complicate things by turning CSS into something it was not designed to be. The article that I mentioned above lists some of the problems.

The second reason is that these things make it more difficult to make simple changes later. Let’s say, for example, that you want to change the color of something on your site. Normally what I would do is open up your site in a browser and load the page where you want the changes made and inspect the element in question. This gives me the exact line in the exact file where I need to make the change. A change like this should take only minutes. However, if I used a CSS pre-processor then I need to be familiar with all of the files and how those files are put together, just like coding in a programming language. If I haven’t looked at it in a while or someone else built it, then what should take me minutes may take me much, much longer. The change takes the same time but finding where to make that change can be time-consuming. It becomes more like debugging code.

What I’ve covered here is just why I feel that CSS pre-processors add to technical debt and doesn’t cover some of the other drawbacks of using them. If you’re interested in some of the other reasons I don’t like them, you should read The problem with CSS pre-processors.

I have nothing against other developers that use them, and in fact I don’t care if they use them and you shouldn’t avoid those that do (that is, as long as you can live with the other problems they cause). What you should do is insist that they are removed from your site once it’s launched and from that point on that they not be used. This way, they get to keep the illusion that it’s actually helping them do the job faster and you don’t suffer from needing to pay for hours instead of minutes when you want a change made.

Summary

It’s up to you. You can continue to go the route of increasing technical debt or you can insist on the developer you choose doing their work in a way that reduces it. You can focus on the long range goals of why you’re building a website or you can focus on the short range goals of getting it cheap and fast. Choose wisely.