Tuesday, March 31, 2015

Communicating Design Intent by Sharing the Paths not Taken

If you're even remotely a movie buff then you'll probably really enjoy Tony Zhou's "Every Frame a Painting" series.  His analytical, accessible, and entertaining film studies mini-documentaries are wonderful. Each video in the series focuses on one main idea, often something overlooked or perhaps under appreciated by other films studies enthusiasts (analysts? critics?).  This bit of analysis on what makes Jackie Chan's physical comedy so brilliant is... well, itself brilliantly done.

In this episode of Every Frame a Painting, Tony discusses the idea of showing character choice rather than just talking about it, using Snowpiercer as an example:
In nearly every blockbuster you've watched or tell-tale game that you've played, you've seen moments like this: the protagonist has to make a choice and there's no way to reverse it.
Just to be clear, I think moments like these are great and a foundation of good storytelling but I do wish in movies they weren't presented through dialog.  So today I look at one possible alternative.  In fact it's one of the oldest traditions in cinema.  How do you show character choice?  Left or right.  That's it.
In a similar fashion as many blockbuster and video game protagonists software architects regularly encounter complex choices that often can't be easily reversed. Or rather, the architecture we're designing experiences those complex choices (since in this metaphor we're working behind the camera and the architecture is the character on screen). But, unlike blockbusters and video games, software architects don't have the luxury of an audience that can simply watch the architecture evolve with each design decision made.

Even on small teams, generally only a few people at a time are in the room or at the whiteboard when a key decision about the architecture is made.  In some ways it's as if we are asking downstream designers to watch only the last 10 minutes of Snowpiercer and then try to figure out why it's such a big deal for Chris Evan's character, Curtis, to do what he does.  Without the context of these critical decision points that are constantly happening throughout a character's/architecture's journey, the audience/downstream designer loses significant rationale that could help explain a lot.

Are there methods that architects can use to make architectural choice evident?  The answer to this question is certainly, "Yes!"

Tuesday, March 17, 2015

Agile Software Architecture (with George Fairbanks)

George Fairbanks and I chatted via Google+ Hangout in February 2014 about agile software architecture. I think we found a groove pretty quickly and the conversation overall went great. I've created bookmarks of some of the main topic areas that we covered to make it easier to jump to bits of the discussion you might find more interesting.

During this Hangout we meandered through several topics starting with walking skeletons and leading to...

Tuesday, March 3, 2015

Architecture Haiku

The most effective way to transfer complex, abstract ideas from one person’s brain to another person’s brain is by writing the ideas down. This premise permeates our whole approach to software design.  Entire books are dedicated to creating better documentation!  Following traditional documentation advice inevitably leads to comprehensive, albeit verbose, documents filled with important details that, sadly, too few stakeholders read.  There must be a better way.

Introducing the Architecture Haiku

George Fairbanks originally came up with the idea of the Architecture Haiku as "a one-page, quick-to-build, uber-terse design description."  With only one page of paper (assumed standard, A4) to work with there is no space to be indecisive or indirect.  There might not even be room for diagrams - which at first sounds crazy, but perhaps is crazy brilliant!  We tried this idea on my team and it turned out to be a great, lightweight method for writing down and sharing architecture decisions.

With so little room, picking the right information to include is extremely important.  Here's what Fairbanks recommends:

Wednesday, December 3, 2014

Dante can be Agile too

[I recently gave a talk for the monthly SEI Agile Collaboration Meeting. The Agile Collaboration Meeting brings together upwards of 50 or so agile practitioners from throughout the federal and DoD space including civilian contractors. This post is a summary of the talk I gave at the September meeting.]

When you do a search for pictures of "unrequited love" one of the first images that comes up is this 1884 painting by Henry Holiday titled "Dante and Beatrice."  As Beatrice and Dante were Italians it is extremely important that you pronounce her name in your mind correctly – Bee-a-tree-che – using the Italian pronunciation.  In this painting you see Dante, the poet of the Divine Comedy among many other works, chilling on a bridge as he is snubbed by a posse of three women.  Beatrice is the one in yellow completely ignoring Dante, who probably went out of his way to be in the right place at the right time so he could see her.

In real life, Dante was obsessed with Beatrice.  They met when they were children and their families cruised in many of the same social and professional circles.  Allegedly it was love at first sight for Dante, then age 9.  Both Dante and Beatrice married other people and apparently met only one other time before Beatrice died at the young age of 24. Dante wrote of Beatrice as "his savior" and she was a prominent character in his Vita Nova (a collection of poems professing his love for both the actual and a metaphorical Beatrice) and Divine Comedy (in which she escorts Dante through Heaven).

I propose that there is an unrequited love between the software architecture and agile communities; software architecture is the Dante to an agile Beatrice who simply ignores him.  Certainly if this were true there would be some observable facts to either support or refute this idea.

Dante and Beatrice, painting by Henry Holiday (1884)

Thursday, November 6, 2014

The Case for Minimalism in Software Architecture

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery
I was first introduced to the idea of minimalist software architecture in an article by Ruth Malan and Dana Bredemeyer, "Less is More with Minimalist Architecture" (PDF).  The basic premise is devilishly simple: the software architect's job is to "only do with architecture what is absolutely necessary to achieve key, broadly scoped qualities of your system."  Any design decisions that do not support this goal are left to the discretion of downstream designers.

Wednesday, October 29, 2014

Defect-Driven Process Improvement

Defects can tell you a lot about your team.  And not just what the problems are in the code.  The Team Software Process uses a very simple method of defect classification to unlock hidden insights. My team recently did some analysis on our bug database at the conclusion of a project and unearthed some surprising information about how we deal with requirements as well as some weaknesses we need to work on.

Simple Defect Classification 

The simplest defect classification method involves manually evaluating defects to add contextual meta information.  The Team Software Process suggests some of the following pieces of information as a starting point for creating a defect taxonomy.
  • Related Feature - the feature to which the defect was reported against 
  • Module Discovered - the code in which the defect was found 
  • Defect Type - a standardized description of the defect, such as "assignment," "data," or "syntax." 
  • Reason Injected - why did the bug make it into the software in the first place?    This should also be standardized, for example "education," "oversight," or "mistake." 
  • Phase Injected - what were the activities being performed when the defect was injected?  For example, "requirements," "design," or "implementation." 
  • Phase Discovered - what were the activities being performed when the defect was discovered? These would be the same as the list for phase injected.

This simple method has some disadvantages, the biggest one being that you usually will not be able to understand the reason a defect was injected until after you understand the root cause of the defect. Also, unless you were the one who wrote the code, you can only guess at the reason (was this an oversight, mistake, or education?) the defect was injected. As such, some knowledge of the system is required to perform the analysis. There are other methods for defect classification that overcome this problem but take a little more training and planning to apply well.  One example is the Orthogonal Defect Classification method from IBM Research.

Since the defects in a software system are a direct reflection of the process, knowledge, and skills of the team that injected them, once the defects are classified you have some serious power for enacting positive change.

Wednesday, October 22, 2014

Dealing with Constraints in Software Architecture Design

Definition of constraint (n)

  • con·straint
  • [ kən stráynt ]
  1. limiting factor: something that limits freedom of action
  2. state of restriction: a state in which freedom of action is severely restricted
  3. lack of spontaneity: a lack of warmth and spontaneity in somebody's manner or in the atmosphere on a particular occasion

In software architecture design, constraints come in two basic flavors - technical and business.  On most projects there are only a handful of constraints, but these constraints are a highly influential architectural driver.  Constraints, as the dictionary definition above indicates, are a limiting factor and severely restrict options for making design decisions.  They are also fixed design decisions that cannot be changed and must be satisfied.  You could think of constraints as the ultimate non-negotiable, "must have" requirement.  It is for this reason that architecture design constraints must be created and accepted with care.

Wednesday, October 15, 2014

Architectural Drivers: Building Blocks for Decision Making

Architectural drivers are formally defined as the set of requirements that have significant influence over your architecture.  In other words, there are some requirements that will help you decide which structures to pick for your system design and others that are less consequential in the context of software architecture.  This implies that it is extremely important to get the architectural drivers right early in a project, as architecture structures will become more difficult to change as the developed software becomes more realized.

Thinking about early requirements as "drivers" can also help you to create traceability from stakeholder concerns to specific architectural decisions made.  Having this traceability is great because it helps to promote important qualities in your team, such as agility.  With traceability you can make changes on purpose and with confidence as you understand the genesis for structural decisions.

What are Architectural Drivers?

Architectural drivers have significant influence over the design of a system and are the determining factor over whether one design is “better” or “worse” than another that produces the same features. Architectural drivers are nearly always divided into four categories.  Some people might go with only three categories (talking generally about constraints), and others might include other things as drivers, but if this is your first time working with architectural drivers you should start with these four categories before tailoring.

Architectural drivers can be one of the following.
  1. Technical Constraints
  2. Business Constraints
  3. Quality Attributes
  4. High-Level Functional Requirements
Let's go into more detail for each of these categories.

Technical constraints are technical design decisions which absolutely must be satisfied in the architecture. These are generally fixed from the beginning of a project and may be expensive to change as the project progresses. Constraints, as the the name suggests, cannot be changed.

Business constraints are decisions imposed by business considerations that must be satisfied in the architecture.  Like technical constraints, business constraints are generally fixed from the beginning and have a significant influence on decision making for the design.  Likewise once in place these are considered unchangeable.  An example might be a specific delivery date, budget, or 

Quality attributes, sometimes called quality requirements, are specific criteria by which a system’s operations can be judged – that is, how well a system performs specific functions. Quality attributes greatly influence the design of the system.  In many cases, the same functionality can be achieved in a number of ways and so it is the quality attributes that ultimately determines when one design is better or worse than another.  Quality attributes receive a significant and thorough treatment in Software Architecture in Practice and you can read a sample chapter introducing quality attributes online.  Quality attributes are recorded as scenarios that describes a qualitative response within the context of specific system functionality.  For example, performance is a common quality attribute, but performance when the system is doing what?

High-level functional requirements provide an overview for what the system will do, the functions and features of the system. These might take shape in any number of formats from epics to stories to use cases to ye olde "shall" statements.  While quality attributes might determine specific structures you choose, the ultimate goal of the software you are building is to build achieve some bit of functionality.  From an architecture perspective, you won't go to exhaustive detail, and indeed it's best not to go into too much detail as diving deep too early can seriously delay the project.

What about Non-Functional Requirements?

If you've read any of the software engineering literature, you'll see the term "non-functional" requirements used fairly often.  The basic thinking was that there are these things that are functional requirements, and then there's things that are not functional requirements, non-functional requirements.  Setting aside the fact that calling requirements "non-functional" is completely dumb, this term comes up enough that it's important to understand it in the context of architectural drivers.

Most of the time people are referring to constraints and quality attributes when they talk about non-functional requirements.  Unfortunately, most of the time teams will lump all "non-functionals" into a single list. This is unfortunate because knowing specifically what kinds of drivers you are dealing with gives you a lot of decision making power.

Functional requirements are negotiable and must be shown to be correct.

Constraints cannot be changed once fixed.

Quality attributes imply trade-offs and often can't be directly tested until very late in the system's lifecycle. As a result you will need to find proxies, run experiments, and reason about the structures you've selected to determine whether or not you've promoted the right quality attributes.

Tuesday, May 20, 2014

Five Challenges for a Maturing Discipline

[At the opening for SATURN 2014 I presented five challenges for the software architecture community as a means of kick starting our brains for the conference, but also a serious reflection on the state of software architecture practice.  My hope is that these challenges are something we can work on together as a community and are my attempt at capturing something actionable that we can do to accelerate software architecture's maturation.  On the surface these five challenges are pretty simple. Of course if it truly were simple then it wouldn't be much of a challenge. Think about them. Give some of them a try. Let me know what you think.]

A little less than 20 years ago, Mary Shaw and David Garlan published a book reflecting on trends they noticed were emerging in software development.  The book's subtitle was extremely fitting: Perspectives on an Emerging Discipline. My reaction to the book, having read it for the first time for a software architecture class in 2008, was that it was grand in scope yet unassuming.  Having had the opportunity to meet and work with both David and Mary while a student at Carnegie Mellon, I found that the tone of this landmark book is more a reflection of who they are than anything else.  Essentially they proposed to the software engineering community, "Here are some interesting ideas and trends we've noticed and we think they are worth taking seriously, but these ideas need some further thought."

While Perspectives was certainly intended to be a unifying, landmark work, Mary and David had the wisdom to recognize that this was only the beginning, that this emerging discipline of software architecture must continue to mature, and that others must be responsible for the growth of the practice.

Sunday, March 23, 2014

I'm going to SATURN 2014 and you should too!

The SATURN 2014 conference is taking place this May 5-9 in Portland, OR. You should consider joining me at this essential software architecture conference. Register now online while tickets are available!

After graduating from Carnegie Mellon with a Master in Software Engineering degree, I needed a way to stay relevant on software engineering topics. As great as it would be, taking time off of work to earn a new degree every 5 to 10 years just doesn't work. It’s time consuming and stressful, not to mention cost-prohibitive. Rather than going back for more degrees, I decided that I would attend at least one professional conference every year. Ideally, I also try to present or write at least one paper every year too, but attending at least one conference is the most important goal.

This year my conference of choice is SATURN 2014. I decided to attend SATURN this year for a number of reasons.
  • SATURN is the largest conference dedicated exclusively to software architecture practitioners (not academics) in North America. I will only attend conferences where I can learn something that I can actually use in my job. My expectation is for a high density of practical knowledge.
  • SATURN is one of the few conferences in the world dedicated to software design principles and practices. There are lots of conferences out there on methods. Tons of conferences on programming and specific technologies. SATURN is one of the few conferences that examines these topics from the perspective of architecture and software design. This perspective if desperately needed sorely lacking in software professionals today.
  • SATURN is an established conference. The conference is co-hosted by the Software Engineering Institute and IEEE Software, and this year marks the 10th consecutive conference held. The SEI and IEEE are responsible for having established and promoted nearly every standard practice in software architecture that has ever existed. Their participation in this conference is a strong indicator of the kinds of topics that will be covered.
  • SATURN is attended by the folks who define software architecture. Here are just some of the software architecture thought leaders who are speaking at SATURN -- Philippe Kruchten, Rick Kazman, Len Bass, Robert Nord , Felix Bachman, George Fairbanks, Ipek Ozkaya, Jeromy Carriere, Rebecca Wirfs-Brock, Ted Neward, Linda Northrop, and more…

    If you measure a conference by the number of speakers who have a Wikipedia page, this conference has at least 5. Bonus points if you can find them at the conference.
  • SATURN has a good mix of presentations, workshops, and longer tutorials. The tutorials and classes are top-notch. I personally am looking for advanced tutorials and workshops to attend and SATURN has these. There’s also a couple with introductory information for software engineers just getting started in the world of software architecture.
  • SATURN is hosting a co-located Open Space facilitated by Diana Larsen. I’m an explorer. When choosing a conference I look for opportunities to explore beyond the established program. I love a good Open Space conference and I am very much looking forward to having an Open Space filled with software architects. I am even more excited that Diana Larsen will be the facilitator. She has done an amazing job facilitating at the XP conference in Europe every time I have been.
  • SATURN keynotes this year look amazing. It’s unusual for me to attend a conference based on keynote speakers. Most of the time I’m not that excited about the big speakers and I’m really looking at the overall topics in the conference. That said, the SATURN 2014 keynote lineup looks really solid.
  • SATURN is held in Portland, OR this May 5-9. Timing and location also play a significant role in my deciding what conference to attend. I have always wanted to visit the Pacific Northwest and Portland in particular. I’ve heard so many amazing things about Portland that I really need to see it for myself. May is also a great time for a conference, at least for me. I must admit that if I could afford to go to Europe this year, I am extremely tempted by XP2014 in Italy.
I should mention that I am serving as the technical chair for this year’s SATURN conference. You should view my serving as the technical chair for SATURN as the greatest possible endorsement I can give a conference. Given the massive time commitment required to plan and organize a conference, I can’t afford to spend time on something that I do not feel is massively important to software architecture, and something that is not great. SATURN is important to our profession. SATURN is a great conference. I very much hope to see you there this May.

Other Conferences of Note:

  • Software Architect London -- I would call this SATURN's sister conference for Europe.  I have not attended, but it is pretty close in terms of quality of program to SATURN and a good choice if you are from Europe.
  • XP 2014 -- outside of SATURN XP is my favorite conference after having attended twice.  The biggest problem for me is that it is in Europe.  Like most Agile conferences it is usually light on software architecture (albeit the strongest architecture presence of the Agile conferences I've attended), but the locations, excellent planning, and dedicated research track more than make up for this.
  • Agile 2014 -- Agile has been expanding to include Agile coaches and UX topics, which has shifted the focus away from core software development.  That said, if you pick the right tracks this is a great conference.