DoD Software Development – the Wrong Center of Effort

I spent some time last week going through the details of a well known DoD three letter acronym IT program. There’s no point in disclosing the particulars because the observation I’m about to make applies to most of them. But, as I was looking at the capabilities of the software and seeing it demonstrated I asked “Hmmm… I always thought there was more to this thing. Is this really all it is?” A: “Well, yeah, it’s mostly just an integration of a COTS database with middleware. The code itself is a few hundred lines of database data definition language and probably less than ten thousand lines of Java, probably a lot less.”

During the rest of the conversation we talked about the fact that, since this is “joint” program it has a staff of program managers and systems engineers at each service plus at OSD and JFCOM to develop the requirements, “design the architecture” and so on. Each group also has its own testing and certification staff to prove out the code before it can be integrated into their versions of the C2 node this thing is designed to integrate… What you get looks like this (where conceptually, the cost per line of code can be estimated by integrating the area under the curve and dividing by the lines of code):


10,000 lines of code. I’ve seen commercial software development programs with 500 developers and millions of lines of code with less management and oversight. Besides a willingness to accept extraordinarily slow delivery of software, this approach so burdens each line of code with overhead, that the world of defense IT has developed bloated expectations for what things cost. The kind of overhead burden that makes quotes like “you don’t understand the pressures we’re under, we only have a budget of $250M” seem to make sense.

When it comes to IT, we in defense systems development need to move past this industrial age systems engineering choked approach and get to something that is agile, fast, and more cost effective. Just make it look like this:



  1. Kit Plummer - March 21, 2008 @ 4:43 pm

    Great post. I completely agree…and, would probably assert that the QA/SA part is even higher than architecture in some CMM-high environments.

    There is a huge push to establish reference architectures and models that could potentially generate code…rationalizing your first graph. The problem with this is that thinking generated code is something that will pass performance, security, or even integration profiles is absurd. This path puts an enormous burden on the actual integration process and requires way too much glue. Needless to say there is absolutely no agility in that.

    Again…very insightful post.

  2. Custom Software Development - March 24, 2009 @ 1:50 pm

    I still don’t understand DoD completely, but I’m trying to.

Leave a Reply

Your email address will not be published / Required fields are marked *