Cameron and Tracey Hughes

Dr. Dobb's Bloggers

Here's to the First Responders!

December 09, 2009

We admit to throwing around some pretty charged terms in a loose fashion. Sometimes we forget that not everybody is drinking the koolaid. We [assume] that words like paradigm, architecture, and model mean the same thing to everyone. Of course we are wrong (what they say about 'assume' is still in effect).

We admit to throwing around some pretty charged terms in a loose fashion. Sometimes we forget that not everybody is drinking the koolaid. We [assume] that words like paradigm, architecture, and model mean the same thing to everyone. Of course we are wrong (what they say about 'assume' is still in effect).And it's not that we will even attempt to define these terms now. It's just that since we are both very, very emotional at the moment, we some how just want to keep hope alive or at the very least the fantasy that somebody else is drinking the koolaid. Why get so emotional you say? It's just another software deployment that has been abandoned by the original contractors/consultants. We've seen this a thousand times before (well maybe not quite a thousand). Here's the drill, some consultant group, or contractor agrees to provide a software solution for the ACME company. The ACME company gives the software development group system/software requirements and the group through hook or crook delivers the software and with the appropriate salesmanship and marketing assures the ACME company that the software is exactly what they asked for. There is ultimately a little haggling, some patches are made, and a few tech support calls are placed over the next 9 months or so. But by and large there is a sign off on the project. Now, because the consulting/contracting group can't survive on maintenance contracts alone, they have to focus their attention on newer, greener pastures. It takes the group longer and longer to respond to ACME's support calls. Eventually ACME is so fed up with the response time, that they decide to find another software group that can fix their problems and address their needs. So ACME divorces the original group leaving behind veiled threats of lawsuit and places an emergency call to a new set of developers.

It's always fascinating to hear the new set of developers (the first responders) describe the state of the software project that they've just inherited. The first responders arrive on the scene of the emergency. They first have a few initial meetings with the purse string holders who they try not to insult by criticizing their first choice of consultant and then they move on to end users and the source code.mEventually, they get around to asking the end user if they can take a look at the documentation that the original consultants/contractors left behind. The end users eagerly point out a couple of pdfs and a little web material. The first responders take a look at these materials and their next question is:

Is this everything?

The end users respond:

We believe so. Oh yeah, Patty in the service department did take notes the entire time the developers were here. But she's on maternity leave now. You're welcome to look at her legal pads.

So naturally there's no real software engineering documents left behind (that's just not how things are done). There are no:

Detailed design documents

UML

Structure charts

Flow charts

Theory of operation

Just a few in-line comments in the source code here and there. So the first responders have to use their previous experience with software that has a similar architecture or paradigm. There's a lot of eyeballing the code at first but eventually the architecture or model that was used starts to take shape and then the first responders have some idea of where to begin. This works because many of the models and architectures deployed have become true and tried over time:

Client-Server

Webserver/Browser,

Servlet/Applet

Boss/Worker

Peer-to-Peer

Consumer-Producer

Web Services

Database/Report

Transaction Processing

Host-Remote

So if the first responder has been around awhile they will recognize one of these architectures (more or less) if they surface and they will know what to do from there.

But what brings us to tears at the moment you say? Well, we arrived on the scene of the emergency and like all good first responders we had the obligatory (it's not your fault) conversation with the purse string holders. After a day or so of excavating the source code, we eventually stumbled on what looked to be an accident in parallel programming. Many types of wheels were reinvented in this code. There was some attempt to use one of the new parallel programming tool sets but it seems like the original developers hit a wall and started alittle (we're running out of time) improvising. And from what we could tell there was a great deal of multithreading trial and error at work. And as of 2:00 p.m. today no clear parallel programming architecture, paradigm, or model has surfaced! Now one may question whether it is the responsibility of the original software development group to leave behind coherent and complete documentation. But in this case, I really don't think it would matter because there was no recognizable architecture or model at work. Maybe it's just us but it seems like the only thing worse than a poorly documented software system that has no recognizable architecture is a poorly documented software system that is multithreaded and that uses no recognizable architecture.

Our hearts go out to all those first responders that are faced with abandoned systems that employ home-made, undocumented, multithreading techniques. Today we feel your pain. Our hope is that the software development community will adopt a common vocabulary and set of models and architectures that are particular to parallel programming and multithreading that once true and tried will be used in all relevant software development efforts. Models, architectures, and paradigms can be used to help us navigate the treacherous waters of parallel and multithreaded programming. We can communicate through models and architectures. We can share knowledge through models and architectures. We can make the lives of the first responders just a tad bit easier if the original software development group leaves a note (somewhere) about the model or architecture used. If the original software development group could only leave a few kind words about the theory of operation, it would be so much appreciated. Even a simple UML diagram showing an overview of the software architecture would go a long way. And if we can't help the first responders, all is lost. Keep hope alive!

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!