That is, not until Collaborative Software Initiative and the State of Utah open source UT-NEDSS, their web-based infectious disease reporting and management system later this year. Can you get any more vertical than that?

Here’s a quote from a recent press release about this project that I think highlights the value of applying open source approaches to vertical problems in the specific context of infectious disease management:

“The project is a perfect example of how collaboration in software can have an impact on society – in this case, we can help prevent the spread of disease and improve quality of care for patients by developing a system that works for everyone,” said Stuart Cohen, CEO of CSI. “The State of Utah is taking a necessary leadership role to begin the rollout of an infectious disease reporting and management system for the 21st century. We are very excited to enable that transition and to work with other states to deploy this important system.”

???????? ????? ????????

I think vertical open source solutions like UT-NEDSS are going to have a very important role in the overall IT landscape in the future. Enterprising organizations and individuals who can take open source platforms, apply them to vertical problems, and then release them to the programming world are going to be major players in shaping the software industry. I think it’s really cool. And I’m proud to be involved with this project, even if it’s just a minor role.

Hacks create technical debt by ignoring principles of good software development in favor of quick, easy fixes

This is the obvious one because it is the one technical teams complain most about. “I didn’t want to do it that way, but my manager said I could only choose from options that took less than a day to implement,” or some variant of this statement, is the most common answer to the question “Why does X suck so bad?”

So how do developers typically fight back against hacks? With reuse anticipation. Now the bad news.

Reuse anticipation creates technical debt by expanding the supported code base without creating a correspondingly timely value proposition

It’s easy to imagine that the service, component, module, whatever, that you’re building might be used by multiple applications in multiple ways. It only takes an extra YY hours to make it universal, you tell the project manager. And then we’ll never have to write this code again. Sometimes, when you already have “universal” demand for a component, this is a good idea. It’s also a good idea when it is a very specific, low-level technical capability, like dumping a message in a queue or searching a string for a value or something like that. Sometimes it’s a really bad idea – over-generalizing a capability can make it so difficult to “reuse” that no one will reuse it. Either way, it increases your technical debt, because whether anyone reuses it or not, the code you have to support is more complex than it would otherwise be.

Time creates technical debt
There’s a great riddle in The Hobbit, by JRR Tolkien:

This thing all things devours:
Birds, beasts, trees, flowers;
Gnaws iron, bites steel;
Grinds hard stones to meal;
Slays king, ruins town,
And beats high mountains down.

Tolkien might have included code in this list had he been a software developer.

Time has a way of dimming our memories of the code we’ve written, what it does, and why it does it. It is for this reason that development teams often turn to comprehensive documentation to save them.

Now for more bad news.

Comprehensive documentation creates technical debt
Every document you write that has more purpose than helping you figure out how to deliver code NOW becomes another artifact you have to maintain. It adds to your code base in that regard. Now, instead of paying people to maintain the code, the business has to pay someone to maintain the code and the documentation. You just fell further behind.

Documentation typically only has ROI in the short term. It is a very rare document that provides value over the long term. Usually it very quickly becomes a cost with little return of any kind.

Innovation creates technical debt
Einstein said we can’t solve our problems with the same thinking we used when we created them. Sadly, when we continuously apply the same thinking to our code base that we used when we created it, the technology world doesn’t do the same. It moves on, finding better ways to do the same thing. Small changes add up and become big changes, and suddenly there are much more attractive technologies that we can’t use because we’ve fallen so far behind.

When we see the world moving on to bigger and better ways of solving our problems, it’s tempting to say something like this:
“There’s no point putting effort into X, we’re just going to move to Y soon anyway.”

Sometimes this is a good idea, if moving to Y is funded, approved, and making progress. But if Y isn’t approved, giving up on X will only increase the amount you owe, and you’ll feel doubly bitter about it when Y never materializes.

When I see this problem, I think of a line from an old song: “If you can’t be with the one you love, well then, love the one you’re with.”

Technical debt creates more technical debt
With credit cards it is sometimes possible to make the minimum payment without reducing your principal a penny. In fact, you can pay your bill and end up with a higher balance because of this.

It’s the same way with your code base. If you don’t invest in it faster than you are accruing technical debt, your technical debt will grow. Why? Because you don’t have time to make it better, so what are you doing? You’re hacking – cutting corners and doing the wrong things just to get done in time with the resources you have.

Technical debt sucks as bad as credit card debt. I suspect that paying off technical debt is very similar to paying off credit card debt. It’s hard, it requires frugality, and it means shedding everything that isn’t really important. More about that some other time.

Have a nice week.

I was wrong.

I have fallen further behind on my inbox than I have ever been in my entire career. What the heck is going on? I have email at my fingertips, anytime, anywhere. Why can’t keep up with it anymore?

The same is true of every person I know who has a Blackberry. They are the slowest to respond and have the deepest inboxes of all my colleagues.

I think the problem lies in the interaction between my Blackberry and my desktop inbox. I can’t file emails after I respond to them on my Blackberry, so I have to do double maintenance. I read and respond on my Blackberry, forget what I did, then do it again on my laptop hours later, except that I don’t respond again (hopefully). But I do have to read the email, notice that I already responded, and then file it.

My solution to this is to resist the urge to use the Blackberry as an email tool, which sort of defeats the purpose of the product. I am trying to use it solely as a phone and calendar tool, and ignore the email except when I am traveling.

It’s not working so far. I can’t help checking my inbox. It’s like a drug, and even though I know it makes keeping up harder, I check it anyway. I need an intervention. I wonder if there is a self-help group I can attend…

Ironically, the blackberry is great for checking gmail. It works just like the browser, pretty much. It rocks.

Every one of the enterprise trends I’ve seen in my career is in some form of failure. EAI has been dead for years. So has Enterprise data modeling. Enterprise data warehousing, on the other hand, seems to be hanging in there. Maybe it will survive, maybe it won’t.

My opinion is that if you’re big enough to be considered an enterprise, you’re too big to do anything in a unified way without imposing HUGE inefficiencies on yourself. Just putting the word “enterprise” in front of a project increases its cost by at least an order of magnitude. If it costs $1M to implement document management for your billing function, it costs $10M to do it for your whole company.

I think the concept of the enterprise has been largely harmful to the information technology trade, aside from the huge revenues attempts to “rule the enterprise” these enterprise trends have generated for consulting companies.

I think it’s ironic that at a time when business units are trying to develop autonomy, flexibility, brand distinction, and other aspects of their business that set them apart from their siblings in the so-called enterprise, IT continues to try to move the other way.

Is the enterprise dead yet? Have we suffered through enough of these enterprise trends yet? Can we just agree not to buy into any more of them? Is there anyone out there who can just check its pulse and call it dead?