You can Depend on it

by MikeHogg12. April 2012 10:09

Imagine for a second, that you wrote an entirely (well mostly) self contained application.  Let's say it has its own home built web server, uses file based persistence, and entirely compiled in one executable.  All it needs is a particular OS and filesystem to run. It doesn't happen like that but we are pretending for a minute. Now, let's say the list of web server features to implement in the next release has grown so long that you don't know how you are going to deliver them all, and someone suggests looking at third party web servers out there- pretend IIS and Apache, or Tomcat. And now you invite IIS into your little ecosystem, for better or for worse, til death do you part(or whenever the rewrite comes along) not only to your language compiler, OS, Html interpretations, and NTFS filesystem, but to this IIS application.

Of course it sounds ludicrous, because we are so used to Having Apache, or IIS. It is a standard requirement.

It's everywhere now and this is good. Your GoDaddy account has two options, Apache or IIS, and nobody thinks twice about it. Same with libraries.

You never think about it but even using .net 1.1 or .net 4.0 is a dependency.

It is something that becomes a responsibility to manage for the life of your application.


I used to work on an 8 year old legacy .net web application, created by contractors who had long gone and whose names nobody remembered any longer.  It was a mess, sure- few codebases exist that don't look like messes to anyone but the authors), but it was 8 years old and running just fine.  I worked on this job next to a contractor superstar, one of those famously notorious contractors that sell you the latest and greatest and the moon on top of that and in half the time you wanted, and are not around three months after delivery to answer questions about a behemoth application they delivered held together by shoestrings.


Mind you- I learned a ton from this guy.  I used to be partial to old technology, to the point of mistrusting anything new.  Prejudicial, even.  I used to rationalize it as being loyal to the old team... trusting only the tried and true, and being cool, a real nerd who only used obscure old command line tools and found fault with anything that tried to take away my manual control.  In retrospect, I wonder how much of it was just a simple fear of learning new things.  Anyway, this contractor showed me what it was like to be on fire about new technology.  He was always a couple versions ahead in everything.  We would be discussing some new feature that we just found out about in c# 2.0 and he would tell us to just wait and see how fast we get along when we finally get to c# 3.0.  We'd be discussing the upcoming 3.0 framework and he'd be talking about the 3.5 update and the new features in 4.0.  He'd bolt on Application Blocks by the six pack, dotnetnukes and bootstrapper libraries on a whim it seemed.  And he made a lot of money.  He was an independent contractor, made his own hours, drew his own contracts, worked hard, and made a lot of money.  But his answer to any of my questions about the inner workings of some framework call or how to expose a property properly would usually be that I should download and add some application to my codebase.


Of course, the way I paint it, it doesn't sound all that good.  And you can guess how the story will end.  But I did learn how to overcome my fear of the new tech.  Learn or be run over by developers that are learning.  But maybe with a bit of moderation.  The story continues... Our team eventually had to upgrade the servers that our project was hosted on from Server 2000 to 2008, and we took the opportunity to upgrade from 1.1 to 3.5.  Along with the one or two library application blocks we depended on from 2002, we had 50 or 60 projects in our web application, and it was fairly painless to upgrade everything, and that application I am fairly confident today, is still chugging along, with new features being added to it even, 11 years old...


A couple years later I was asked to get into a project to fix some application that wasn't working.  Turns out it was that contractor's application from the story- Most of the eight or ten feature sets/third party application blocks that composed the total web application had stopped working within the first three or six months of release, long after he had gone, and the users had just not been able to find resources to fix it.


Most of the standard dependencies, the web servers, the language frameworks, the operating systems, the filesystems, they all are pretty low maintenance.

I can imagine most applications lasting 8 or 10 years before being absolutely forced to think about these dependencies.

But they are there, and everytime you add one more to the pot, you're adding to that total cost.

You're adding to the time and effort some developer- likely not you- will have to spend pouring through your code five years from now looking for conflicts

or compile errors against a new framework, or hunting down obscure bugs that happened when someone decided to just upgrade and see if it all works.

You're adding to that. There is the possibility that business decisions are made to rewrite the application, or buy a replacement from a vendor,

or spend time/money to fix it. There is a possibility that your pride and joy might die an early death at the first sign of trouble

instead of fading away into the sunset several generations down the road.

So someone explains all the benefits of relational databases, and you find that to be a Good Thing, and add that to your application.

You weigh the odds, make a judgment call, add a third party library to your project Logging.

And another JQuery. Add some new architecture pattern AWS. Add a new framework MVC4.

And now the future is not as stable as before. What is your life expectancy now? What is your confidence of that number?

How will you approach the decision to add the next dependency to your application?

About Mike Hogg

Mike Hogg is a c# developer in Brooklyn.

More Here

Favorite Books

This book had the most influence on my coding style. It drastically changed the way I write code and turned me on to test driven development even if I don't always use it. It made me write clearer, functional-style code using more principles such as DRY, encapsulation, single responsibility, and

This book opened my eyes to a methodical and systematic approach to upgrading legacy codebases step by step. Incrementally transforming code blocks into testable code before making improvements.

More Here