Design review is not a test of your UML skills

Meiko asked me yesterday "To prepare for the design reviews, do I need to brush up on UML?" 

It's really not such a goofy question.  In Microsoft IT, lots of things are changing.  In this environment, I'm hoping to be one of the many who rally for greater emphasis on excellent design, as my prior posts demonstrate.   So, I champion design reviews, and peer reviews, and peer training like study groups.  And not just a review where untrained peers take a peek at your text and go "nice job," but a real evaluation by architects looking at how well your design reflects tradeoffs, with the teeth to make you change it. 

Hence the question.

Now to be fair to Meiko, she's a young developer.  Smart, but only about eight years out of college.  She hasn't been really challenged in this way before, and she wants to be prepared.  I respect that.  I wanted my reply to show that respect.

"I don't want to pick nits, but in order to design something that someone else will code, you have to communicate in a language they can read.  So, no, you don't prepare for a design review with UML... you prepare for design with UML"

She gave me that look like 'you know what I meant.'  I did.  She's right.  Not fair.

"OK, you want to know what I'm going to look for when I review the design, right?"  I asked.

"That would help."  Arms folded now.  Defenses going up.  I'm missing a chance.  Dang.

I grab the pen and head for a white board.  "Let's say you are in my seat, and you look at a system design that looks like this..."  I start to draw.  Her arms are not folded now.  Good.

I draw a picture of some boxes and some lines.  Nothing special.  A database in the corner.  Everything inside the boundary.  Simple example. 

She smiles, "I'd say the designer was stuck in 1994.  That's basically a three-tier app."

"But is it any good?" I ask.  "How do you know?  What objective criteria do you use to decide if this design is any better or worse than any other?"

She opened her mouth but silently closed it.  We stood still for a moment.  We were standing in the hallway next to a really large whiteboard that was mounted on the only wall large enough to hold it.  I could hear keys clicking as one of the developers in their office was busy typing.  She looked at me for a second.

"Are you saying that you have objective criteria to measure a design?"  She sounded a bit incredulous.  She spoke the word 'measure' slowly for emphasis.  I could see her science training coming through.  She had told me once that her degree was in Physics. 

"Well yes, but I'm not taking credit for writing it.  This stuff comes from the Software Engineering Institute.  It's called the ATAM method.  I'll send you a link."

"Thanks"  she said.  Her reply was small.  I had just told her I was going to 'grade' her using a method that she didn't know, developed by academics known for creating large and unweildy things like the CMM and TSP/PSP.  I had just told her that she was going to have to read boring books to be able to justify what she already does quite well.  Not a good message.

"Wait.  It doesn't hurt.  The ATAM method simply asks you to look at your design from the standpoint of what they call 'System Quality Attributes,' what we call 'the -ities.'  Availability, Scalability, Reliability, Security... stuff like that.  It's just a more organized way of doing what we've been asking folks to do for a long time.  You don't have to prepare by reading a thousand boring pages."

She looked relieved.

"You do have to prepare by making sure your design has considered the System Quality Attributes with respect to the requirements."  I stopped on the last word and repeated it.  "The requirements are what determines if this silo on the board here," I turned to point to the diagram we were ignoring, "is a good design." 

"There are always many ways to design a system, many choices to make."  I said.  She was back with me now.

I continued.  "But each time you make a choice, you trade one thing for another.  You may chose to make a monolithic app, and trade adaptability for a specific model of deployment.  You've been making tradeoffs all along.  We're just going to ask you to describe them."

"In UML?"  She chided.

"UML, English, Algebra... pick your language."  I smiled.  She knew what to do.

.