DevOps Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2576 posts at DZone. You can read more from them at their website. View Full User Profile

Infrastructure Debt Harder to "Pay Off" Than Technical Debt

  • submit to reddit
Most of you have probably heard the term "Technical Debt".  It's basically those bugs in a code base that add up after messy quickfixes that don't involve the proper amount of testing and refactoring.  The @TheKeyboard blog recently coined a the term "Infrastructure as Debt" to bring awareness to the even nastier task of cleaning up the issues related to your environment and the process of moving code from deployment to production. 

I'll summarize some of the issues he highlighted.  By fixing these, you can 'pay off' your Infrastructure Debt:

  1. Developers each using a different 'preferred' development environment causes code to be out of sync.  You can institute the same environment for all devs or let them use identical virtual machines with their preferred tools.

  2. The deployment process needs to be controlled and standardized through automation.  Different deployment processes lead to Infrastructure Debt.

Elaborating on the second point:

I really think there is one rule: if you cannot do your deployments with one command then you are DOING IT WRONG. If you can type the commands you are doing into a shell then you can script them so you don’t have to type them in again. If you can script deployment, then you can automate deployment. If you can automate deployment then you now have a consistent and repeatable process that will behave the same way every single time you deploy.  --Chris Hartjes

Tools like Capistrano, Phing (PHP), or Jenkins can help you here.  It's important, Hartjes says, that you examine your process beyond the coding.  Check out the post if you want some more details on this Infrastructure Debt thing.



Cristian Vasile... replied on Sun, 2011/11/06 - 3:59am

Regarding point number one, let me tell you that I wouldn't work in a company that would force me to use inferior tools (e.g. Eclipse).

As a lumberjack, please don't ask me to replace my chainsaw with an axe.

Also, regarding code out of sync, it's because developers think differently. If you want code to look like it was written by one developer, try pair programming and pride management. You can't solve a social problem with tools, you can only deepen it.

As for virtual machines, please do so if you have a huge amount of money to throw out the window. A friend of a friend worked for a big company that had this policy. Because it took tens of minutes to compile the project and everything else was so terribly slow, I estimate this friend did actual work for half an hour or less a day.

The advice at point 1 is (or should be) the horror of any developer.

Jess Holle replied on Sun, 2011/11/06 - 8:22am

Developers should be free to use whatever tooling works for them.  If the result doesn't build in an integration environment, then that clearly isn't working for them, of course.

Lund Wolfe replied on Sun, 2011/11/06 - 6:51pm

Mandating an IDE is a good way to limit your upside potential in terms of developers. Obviously, everyone on the same project should be using the same source control and the same code formatter/formatting either through the IDE or elsewhere before code is actually submitted to source control.

I'd be more concerned about technical debt as poor quality design and implementation (bad code or inconsistent with existing design) than automating deployment. If there are deployment consistency problems, then there is probably a more fundamental problem, like not automating distribution/packaging, or lack of functional testing, or not knowing which parts of the system are affected by the changes (incomplete deployment). The production deployment itself should be relatively trivial (or at least clearly/simply documented in step order).

Roger Lindsjö replied on Mon, 2011/11/07 - 8:08am in response to: Cristian Vasile Mocanu

I agree that forcing tools on developers is a bad idea (although we differ on the usefulnes of Eclipse). However, I think with development environment the author actually means your own test environment, but it is very unclear from the article. So, if your system should run on some solaris version, then every developer should have an environment to run their tests in that is similar to that environment, and a virtual machine is suggested (not sure if that is the cheapest solution).  

Daniel Manchester replied on Tue, 2011/11/08 - 11:32pm

I'm always interested to hear from/about developers for whom use of their preferred IDE is utterly non-negotiable. We're forced to be flexible about so many other technology choices--an existing app's framework, a corporate-dictated database, a deployment OS--that it seems arbitrary to be inflexible on the IDE question.

Marc Stock replied on Wed, 2011/11/09 - 5:39pm

Let me guess use Eclipse, right?

Paul Russel replied on Sun, 2012/06/10 - 8:41am

Excellent article. Even if you are doing things right, it is very easy to slip back into old habits. Switching frameworks? It's too much time to make your CI environment work with the new stuff - we can do that later. Of course in the meantime everyone goes back to running tests and deploying by hand. We are just climbing back out of that hole.

Also, thanks for the notes about ways to handle virtual machines. They are now featuring very highly on my ToRead list.

John Smith replied on Thu, 2013/02/14 - 4:52am

 very interesting post.this is my first time visit here.i found so mmany interesting stuff in your blog especially its discussion..thanks for the post!       Discover Ara Networks

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.