Category: Software Architect

Are your developers performing recurring tasks that needs little thinking? Can you find recurring patterns in the code? Can you spot code that’s been written copy-paste-modify style? If that’s the case, your team is moving slower than they should and oddly enough – you may be the cause.

Before explaining why, let’s agree on a couple of truths about software development:
1) Duplication is evil.
2) Repetitive work slows down development.

As an architect, you set the tone. You’ve got the best overall grasp of the system and you probably wrote a trend-setting, end-to-end, vertical slice of the system that serves as an example for the team – an example that has been copied many times by now. Whenever a developer copies anything – be it a few lines of code, an XML-file, or a class – that’s a clear indication that something could be made simpler or even completely abstracted away. Most often, it’s not the domain logic that is copied; it’s the infrastructure code that just has to be there to make it work. For that reason, it’s crucial that you can envision the effects your examples have. Any code and configuration in your examples will be the base for tens, hundreds, or maybe thousands other slices of the system, which means you have to make sure that your code is clean, intention revealing, and contains nothing except what can’t be abstracted away – the domain problem itself. As an architect, you need to be highly sensitive to any kind of repetitive patterns, since anything you write will (ironically) be repeated.

But that doesn’t happen in your system, right? Take a look at that configuration file. What needs to be different if applied on another slice of the system and what will stay the same? Look at a typical business layer method. Is there a pattern that shows up in other methods as well, containing things like transaction handling, logging, authentication or auditing? How about the data access layer? Any code in there that will be the same except for names of entities and fields? Look broader. Can you find two or three lines of code that frequently seems to go together and even though they operate on different objects, it feels like the same thing? These are all examples of repetition. Repetition in code is something that developers eventually learn to filter out and ignore when reading the code, once they figured out where the interesting variabilities are found, but even if the developers get used to it – it slows them down. Code like that is clearly written for computers execute, not for developers to read.

Your responsibility is to remove it. To do that, you may need to harvest frameworks, create better abstractions, perhaps ask the toolsmith to setup an aspect framework or write a few small code generators, but the repetition won’t go away unless someone does something about it.

That someone is you.

“Architecture is a social act and the material theater of human activity.”—Spiro Kostof

How many software architects see their role as exclusively, or primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions among the stake-holders? How many approach their work in a purely intellectual spirit, without giving proper weight to the human factors of their job?

“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”—Frank Lloyd Wright

What more strongly marks out the architects in your organization: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Under which tendency would you prefer to work?

“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”—ibid

Is the “maintenance” of “legacy” systems anything more than pruning those vines? Would you, as an architect, have the intestinal fortitude to scrap a piece of work that had failed? Or would you cover it up? Wright also said that the architect’s best friend was the sledgehammer. What have you demolished recently?

“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the chair”—Karen Moyer

For “God” read “customer”.

“In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton

When was the last time you saw a piece of software who’s architecture gave you any delight? Do you aim to give delight with your work?

“No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder”—John Ruskin

Does artistry play its proper part in your architecture? Is the assemblage of components to make systems informed by a painterly concern for shape and texture, with a sculptural sense of balance and implied motion, of the importance of negative space?

And finally, no gloss is required on this comment, a sure remedy for the software architect’s most damaging syndrome.

“It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect.”—ibid