On Architecture: The dubious joy of system architecture revision

Lately, I have had the rather dubious pleasure of reviewing some of our existing systems and find a plan for improving the maintainability of these systems. I have not done much work like this before, and I came in unprepared for the experience.

Most systems that have been maintained for a number of years have a maddening complexity, especially if they include a range of technological elements. Cramming the systems into my head completely enough to not make recommendations that are counter productive when they are faced with reality requires me to digest a lot of detailed information from many sources.

Here is a description of a typical day of architecture review: 1. Get up late (due to reasons that will become obvious). 2. shift around documentation, code and notes for a few hours, while consciously and guiltily thinking about definitely non-job-related issues. Being disturbed by emails inquiries every fifteen minutes. 3. A one to two hour interview with one of the experts on the system, which usually ends with me claiming that they all hate me and want me to have a heart attack (I really could handle that better, my sincere apologies to those who have had to suffer through it). 4. Late lunch – the paper shuffling + interview made me forget to do lunch at normal hours. 5. Actually burrowing down into the documentation, code and notes, while still being disturbed by an urgent email every fifteen minutes, so the house of cards that is my understanding of the system collapses into a sorry mess. 6. Writing a few lines in my final report, deleting them, writing them again, screaming loud in frustration with the insufficient expressiveness of the written word and UML diagram (luckily, by this time, everyone has left work). 7. Find some lame excuse to go out with friends and get hammered. 8. Go to bed drunk and exhausted by 2 am, and reading printouts for another two hours before going to sleep.

I think the distracted, messy, unconcentrated process is necessary for me to actually digest and process the information. I am always able to come up with a plan for improving the system, although I usually find it extremely hard to express it in the report, and I underestimate how long it will take. By the time I am done, I am a depressed, alcoholized, distracted wreck. But the recipients are usually happy. I am not sure I’m cut out for this.

There must be a better way. If I find out, you will be the first to know.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Software Development. Bookmark the permalink.