Geeks With Blogs
A Technical Debtor Toward continuous improvement

One of the things that I failed to mention in yesterday’s post is that this series is going to be descriptive, not prescriptive. The biggest reason for that is that my experience is rather narrow in some regards, and I have some advantages that other developers and architects don’t enjoy. For example, the VP of Software at CCI (who I don’t report to, but who makes the calls about letting me borrow the developers!) was one of the earliest developers on our product… in the days when it was migrated to Access 2.0.

I mentioned briefly an example of what I refer to as “guerilla” architecture – that is, something that can be accomplished by a single person without a great deal of impact on, or effort required by, the rest of the team. (This was the modification of the code generation templates to use inheritance to reduce the amount of duplicated code.)

However, not all problems are this small, or can be accomplished without some sort of tacit approval. So, I’m going to touch briefly on some of the things I did to build consensus for putting such a massive effort into improving the architecture.

One of the things that became apparent very early was that there was an architectural pattern around the data that was causing developers at least twice as much work as was needed. I knew this, the developers knew this, the team leads knew this… but management wasn’t aware of the details. The first thing I did was bring the team leads on board, talking to them about the issue and explaining a proposed solution. This was a long-term effort, with a few words about it here and there. Part of the issue was that it was such a daunting change, and with such wide-reaching tendrils, that it honestly took me about 10 months to have the a-ha moment on how to attack the problem. (I mentioned in another post that I was on salary… it’s a good thing, too… I don’t think many consultants get the opportunity to take 10 months to propose a solution.)

Even before I had the solution in mind, however, I had sent a survey to all our developers. Among other things, it asked what the number one thing was that made their jobs more difficult. It really wasn’t any surprise when the unanimously indicated the very architectural pattern I wanted to change – as I said, pretty much everyone knew it was a problem. However, this gave me a concrete result that I could point to when discussing with management. I also have the benefit of having a leadership team above me that understands, not only software, but what happens when you keep a code base alive for a decade or more. By explaining that the architecture we had made development difficult, and would make maintenance even harder, I was able (along with the survey results) to present a compelling argument for change.

Next post, I’ll talk about what decisions ought to be considered once you’ve got approval to make massive changes.

Posted on Tuesday, July 13, 2010 8:10 PM | Back to top

Comments on this post: Architectural Renovation – 2 of N

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Jeff Certain | Powered by: