Architects and accountants have something in common, which is that they need to understand their organizations assets and liabilities. For an accountant, these are fairly understood. For an architect, one might think that they are as well. Your assets are you IP and processes that add value, that enable your organization to out-pace its competition. And your liabilities are those that don't. We have a special word in architecture for IP liabilities: it's call technical debt.
Technical debt is a great opportunity for architects to benefit their organization, and here's why: it's something that is already costing your organization in terms of resources and credibility. You can probably count the defects in the package, the tech support calls raised, the number of open customer issues that are due to technical debt. You can put a very clear value on it, which makes it a great candidate for reducing cost. It isn't free, but it is often quite worthwhile.
How do you do it? It's pretty simple -- pick a mess and clean it up. I don't just mean pick the stuff up off the floor either, like your teen would clean their room. At the very least, polish it like a fourth year recruit at West Point. At best, remodel, and I mean completely remodel or rebuild -- like Grahame Grieve did for HL7 Version 3 creating FHIR. The corollary to "if it ain't broke don't fix it" should be "if it keeps breaking, stop fixing it and replace it." When car repairs exceed the cost of payments, it makes sense to get a new car (unless you are talking about something like a 69 Pontiac LeMans*).
It's painstaking work. Usually messes like this accrue because code becomes fragile, knowledge gets lost, nobody knows quite how that works (or doesn't). And yet there is still some underlying value to the code because it does something important and cannot be otherwise expunged, so some extra effort is needed. It's like the antique in the attic that just needs the right refinishing to become an awesome heirloom. This is frustrating work, often risky, and sometimes it's downright boring and tedious (ever read through nearly a thousand different logging messages). On the other hand, the value of the work can be made very clear and well defined.
The biggest challenge you will run into in trying to take on work like this are people who are concerned about the risks you are taking on. The biggest tool you have to combat risk is knowledge, and sometimes that means making the time to obtain more. The most fragile software components are usually the ones where the least is known about them. Go learn it. In the end, you'll be glad you did, even though getting it finished wasn't the most glorious thing you've ever done.
-- Keith
P.S. As a teen, I spent the better part of a winter replacing an engine in a 69 Pontiac. It was cold, it was hard, it sucked. It was my ride to school, and I learned a ton. It looked something like the picture below, but was black.
Technical debt is a great opportunity for architects to benefit their organization, and here's why: it's something that is already costing your organization in terms of resources and credibility. You can probably count the defects in the package, the tech support calls raised, the number of open customer issues that are due to technical debt. You can put a very clear value on it, which makes it a great candidate for reducing cost. It isn't free, but it is often quite worthwhile.
How do you do it? It's pretty simple -- pick a mess and clean it up. I don't just mean pick the stuff up off the floor either, like your teen would clean their room. At the very least, polish it like a fourth year recruit at West Point. At best, remodel, and I mean completely remodel or rebuild -- like Grahame Grieve did for HL7 Version 3 creating FHIR. The corollary to "if it ain't broke don't fix it" should be "if it keeps breaking, stop fixing it and replace it." When car repairs exceed the cost of payments, it makes sense to get a new car (unless you are talking about something like a 69 Pontiac LeMans*).
It's painstaking work. Usually messes like this accrue because code becomes fragile, knowledge gets lost, nobody knows quite how that works (or doesn't). And yet there is still some underlying value to the code because it does something important and cannot be otherwise expunged, so some extra effort is needed. It's like the antique in the attic that just needs the right refinishing to become an awesome heirloom. This is frustrating work, often risky, and sometimes it's downright boring and tedious (ever read through nearly a thousand different logging messages). On the other hand, the value of the work can be made very clear and well defined.
The biggest challenge you will run into in trying to take on work like this are people who are concerned about the risks you are taking on. The biggest tool you have to combat risk is knowledge, and sometimes that means making the time to obtain more. The most fragile software components are usually the ones where the least is known about them. Go learn it. In the end, you'll be glad you did, even though getting it finished wasn't the most glorious thing you've ever done.
-- Keith
P.S. As a teen, I spent the better part of a winter replacing an engine in a 69 Pontiac. It was cold, it was hard, it sucked. It was my ride to school, and I learned a ton. It looked something like the picture below, but was black.
I really appreciate your work and very amazing and important information about the GE Centricity which have share in this blog.
ReplyDeleteGE Centricity