When I first saw Kevlin’s session description I was very skeptical, I initially choose another session to go in this slot but the speaker had an emergency so I decided to go. The reason for my skepticism was that the session description kind of made the argument of “beat up the architect”. This session was nothing of the sort, it was very good.
There is always an arhictecture and one or more architects
Kevlin argued that there is always an architecture in your system. The big difference is in how you think about it or come about it and how is responsible for it. In smaller teams and some systems there is no need for a designated “architect”, while in others it makes sense to have a person that focuses on the big picture and tries to hold all the pieces together. In his point of view, this architect should be involved in implementing the architecture in code but not put them in the critical path. This is the only way for an architect to see and feel the pain of the decisions made.
Technical debt
Technical debt is something that all systems have more or less. The big difference is how you handle them and how they came about. He showed a four corned diagram that categorized how debt usually come about.
| Reckless (deliberate) | Prudent (deliberate) |
| We don’t have time for design | We must ship now and will deal with consequences later |
| Reckless (inadvertent) | Prudent (inadvertent) |
| “What’s layering?” | Now we know how we should have done it |
It’s quite obvious which of these reasons are the more sane then the others. In Kevlin’s opinion; the only time Technical Debt is ok is when you have a process where you handle bugs and technical debt directly after release so they don’t stack up indefinitely.
Patterns
In his talk, Kevlin also talked about patterns and how they could be in the way of a good architecture. He talked about a workshop they’ve done to find patterns in their own software that resurfaced in more places then one and learned from that. He argued that the purpose of patterns was to “uncover better ways of developing software by seeing what others already have done”. A view I really like and hope I already live by. Patterns are there to help you cut through the woods and get to the meat, not to win a code-beauty contest.
In summary
Kevlin’s view of an architect was more that of a leader. A leader that gives people a sense of progress and helps in delivering software with good quality. It’s a healthy position. I liked his talk, it gave me inspiration and reinforced how I see on my own role at Sogeti as the Lead Solution Architect for Microsoft Practice and will certainly color how I work in that role. Thanks Kevlin.
