Would you like to go back in time and tell your younger self what to do to succeed and what perils to avoid?
This is what Tom Gilb did for me today.
As time travelers usually go, he spoke in cryptic ways, poured a lot of knowledge and had to leave quickly. He left me with the glimmer of hope that the Software Industry can achieve a 100% success rate instead of the abysmal 20% of today.
Tom struck me as what I would call a software architecture scientist. He is among the few to work in IT since the 60's and has a scholarly approach and detachment. He worked for major companies and helped steer very large boats to clear waters. Despite this, both he and his son display a norwegian humility and openness coupled with the desire to spread their knowledge.
At a first glance what they presented seems to be just common sense. Focus on stakeholders and end users. Make sure requirements are clear and refined. Define clearly measurable quality attributes. Be concise in expressing architecture. Use Agile, but not as a silver bullet. Start delivering value in the first week. Reasess and learn during each iterative cycle... not only in development but in project management and architecture.
Sounds like bits and pieces of every other software development advice? The biggest "twist" is thinking about architecture in an engineering way. "Real" architects and civil engineers have long enjoyed the respect and trust from people of all walks of life. Houses, bridges and so on have been built for hundreds of years without fail. Yet we struggle to keep our systems up almost every day.
Parallels and highlights
"We're proud that Agile has reduced a 40% failure rate to 20% failure rate. In other words we're proud that we only kill one pedestrian at each crossing instead of two".
"One of the biggest failures is not filtering/sorting/correctly quantifying the stakeholder values BEFORE the team starts developing"
"The human body manages all kinds of systems and if one fails, we die; we should engineer our systems the same way".
"Notes actually do mean something. They have power. I think of notes as being expensive. You don't just throw them around. I find the ones that do the best job and that's what I use.".
In software, a 200 pages document will never be read. Every architect should go through the exercise of expressing a complex system on one page. The bad version of this is "The more I write the wiser I will seem".
Each line in the architecture must address or refer to a quality attribute. I read last week Kurt Vonnegut's 8 tips on How to write a great story
"Every sentence must do one of two things — reveal character or advance the action."
Why not try to write your architecture so it is a great story?
Architecture that never refers to necessary qualities, performance characteristics, costs, and constraints is not really architecture of any kind This reminded me of a Ken Levine tweet which I can't find at the moment. Paraphrasing:"Oh you have a great game idea? Come up with a great idea that gets the whole team on board, can be done within budget and fits a large enough audience to make a profit... and then we'll talk".
Few speakers imparting such wisdom are backed by experience and proven track record. When you see projects all around suffering from lack of goals, platoons of developers trudging along without raising their sight and yelling "Why are we doing this?" to have someone tell you 100% success rate in software is possible is, if not a time traveler, an alien from a distant planet. I thought this is impossible, after seeing the diamonds in the presentations, diamonds present since the 70's I wondered why are they not implemented all around us?
I realised after the talk that to fully understand Tom and Kai's methodology you need to: have participated in at least two projects that failed; been in direct contact with a software quality and measurement practice such as CMMI; worked in at least two Agile projects (can cross with the ones that failed); having been in the frontline for gathering requirements from the client; and of course, being in a role where you define software architecture. That is a whole lot of IT-related experiences to go through.
This, coupled with the fact that software is invisible and software cities crumble all around us makes customers and CEOs afraid of fully trusting yet another methodology.
I've been on more than one occasion in the following dialogue. "What do you do?" "Oh I'm an architect"; "Ohhh, really?"; "Yes, a software architect" ; "Ah... I see". This drives me up the walls. I've shared with Tom my frustration that we software architects are not as respected as architects, lawyers or doctors even though we can affect larger numbers of people. Tom smiled and said: "I give us 50 to 100 years before we achieve this".
Time traveler indeed.