We have to get PEOPLE to build this stuff


I started to write a long comment in response to a post on my friend George Fairbanks blog, but when it got above three paragraphs, I decided to move it over here. The question was whether or not data modeling should be considered part of software architecture.

The short answer is, “Yes” but my reasons why may surprise you.

I’ve sat in many a team meeting where early design decisions are being made. Nothing helps engage the team better, than settling on a data model. At levels above that, where you just say, here’s an employee, here’s a customer, the team will just nod and agree to whatever the architect/design lead/etc. is saying. It’s only when you start to ask, “How are we going to represent these objects in the system?” (and really only after you discuss which objects go in which tables), do you start to get folks to actually think about (and commit to) building it. I’m not sure you have to go down to the data modeling level all the time, but for many situations you have to do it to get the team engaged.

Developers won’t require that you decide in the meeting whether or not it’s a varchar or a string(20), but they may not engage unless the conversion includes things like, “Are we going to use the same table to store customers and employees.” That’s when you start to ask questions like, “Is an employee ever going to also be a customer? If so, is it OK for them to have two separate entries in the system? How much data is in common between the two? How much is different?” This does get a little close to George’s fear about discussing N-th normal form but there it is.

But that wasn’t the original question. Nobody is saying that data modeling isn’t useful. We’re just asking whether or not data modeling should be considered part of software architecture.

Never forget, we have to get PEOPLE to build this stuff. The single most important driver for the success of a software project is the commitment of the people doing the work. If the coders think that the plan was pulled out of the air or the design is wasteful, pipe dreaming, or otherwise deficient, they will passive aggressively kill your project. If you’ve ever been part of an effort where the folks on keyboards think, “the PowerPoint architects who designed the systems are idiots”, you understand what I mean. So the number one priority is to get the developers to say, “our design”. If they ever think, “his design”, you are much more likely to fail.

The architect’s job is to get the team to commit to a good design. It’s not to deliver a good design to the team.

And the only way to be certain, that the team has committed to it, is to get them to find it themselves. You can tell them until you are blue in the face that you have analyzed this nine ways to Sunday and you are convinced… blah, blah, blah. I repeat, the only way to convince them, the design is good is for them to come up with it on their own.

As a great architect, you should have already walked through the issues yourself. Certainly, you’ll use the higher level abstractions that you are writing about, George, to think things through. But you can’t stop there. If you throw your design over the wall at that point, who knows how it will turn out. And don’t tell me that you sent it out for comment. Nobody reads that stuff. You have to host a meeting or a series of meetings, preferably with a good facilitator/coach (like me 🙂 or Noopur Davis, who does this better than anyone I know). You go into the meeting with an architecture in mind and probably even well documented, but don’t hand those documents out. Start with a blank whiteboard. Add a simple block diagram and proceed from there with the Socratic method. Someone will suggest something you’ve already rejected and you’ll say, “Sounds reasonable, but what about foo?” They will then either 1) reject it like you did; 2) suggest a creative way around foo; or 3) convince you why your assumption or priority is wrong. Every time, I’ve seen this done, the architecture is different coming out of the meeting than going in. Sometimes the improvements are minor and might have happened anyway during implementation. More often, the changes are major.

If the architecture is for a large system of systems, then you may only have sub-team leads/architects in the meeting and they will probably not want to talk at the data model level. But when architecting for a 2-pizza team you better be ready to go down to the data model level.

You should of course follow up the meeting by delivering back to the team, the architecture that they came up with in the meeting. If it’s close to what you had already documented before the meeting, so much the better. To do this effectively, you may need several meetings at different levels. Don’t worry about the cost/time. If you delivered a finished architecture, you’d have to spend time training them on it anyway. This is just a fun (and much more effective) way of accomplishing that goal of them understanding what they are going to build. Your biggest problem will be resisting the temptation to share your wonderful architecture with the world and get credit for it. Your best approach is to make sure the team gets all the credit.

If the book you are writing is for software architecture researchers, then you can ignore everything I’ve written. If on the other hand, you are writing something that can be used by practicing architects, then never forget, we have to get PEOPLE to build this stuff.

 

This entry was posted in Software craftsmanship and tagged , . Bookmark the permalink.

4 Responses to We have to get PEOPLE to build this stuff

  1. Hey Larry,

    Ok, you’ve finally convinced me that I *must* write that blog posting titled “Software Architecture is Data Structures”. That title is false, but it is a gateway drug to get people where they should go: everyone is doing architecture, not just the PowerPoint guy or someone in the corner office.

    If we think of architecture abstractions as equally real as data structure abstractions then we are way ahead. Software architecture should be the course that follows immediately after data structures for undergraduates. We must avoid what you’ve described — a division between programmers and architects. Sure, some folks are better at one thing than another — you should hire Greg Hartman to write OS code, not me — but nobody suggests that I should not understand data structures.

    BTW, my book isn’t targeted at researchers. Here’s the first two paragraph ( http://rhinoresearch.com/book ):

    Software systems are larger and more complex than ever, and helpful software architecture techniques have been developed, yet the term “software architecture” is derided by many practicing software developers. How did this happen? I believe there are two primary reasons. First, software architecture is associated with big, high-bureaucracy projects while most developers are seeking agile software development. Second, software architecture is associated with the annoying guy in the corner office, who has the title architect, and draws pictures but never codes.

    This book seeks to change these perceptions and to democratize software architecture techniques for the benefit of all software developers. This book describes a way for you to identify engineering risks and combat them with deliberately chosen engineering techniques. It avoids the “one size fits all” tarpit with advice on how to identify the risks in building your system. Any particular technique mitigates some risks but not others, so you must learn which techniques mitigate which risks, or else you will waste your time on the wrong techniques. Most techniques have a range of rigor from quick-and-dirty to meticulous. There is no need for meticulous designs when risks are small, nor any excuse for
    sloppy designs when risks threaten your success.

  2. Larry says:

    @George Fairbanks
    Of course I knew your book was not for researchers. 🙂 I’ve read the material you’ve posted and I’m looking forward to seeing more. BTW, I think the agile references that you worried about here are fine. However, I do wonder why you want to be associated with the grizzled old coach. Wouldn’t you rather be the winning coach (regardless of age or grizzliness)?

    The post about Data Structures you are proposing is a good idea. However, if you really want developers to read your book, you’ll need a a title that captures the vibe of your meaning and you might even want to avoid the word, “architecture”. The word has connotations that will act as a filter for your audience.

  3. John Owens says:

    In the building industry before a building is ever erected you will have an architect’s plan defining in full each of its facets. You would then have wiring diagrams and plumbing diagrams. Last of all a decoration and furnishing plan. All of this before a brick is laid.

    No builder would consider building a house without all of this information being provided – well no good builder. Why then, in the computing world would a “builder” get turned off by an “architect’s” plan and think it quite unnecessary and restricting?

    In this world the “builders” want to be architects, engineers, designers and builders. No one can do it better! They don’t need all of these silly plans and designs they want to “just get on an build it”. Data Models are for wimps! Is this perhaps the reason why most computing projects fail to deliver the required results?

    People moan and groan about a structured approach and call it bureaucratic. They want ‘rapid’ methods. We used call them ‘back of an envelope’ but they now have exotic names like “Agile”.

    They also want “iterative” methods. This is a euphemism for building the wrong thing first time and then spending these rest of the time putting it right.

    There some excellent developers out there. I have bee privileged to work with some. They can actually get it right first time. But they they are far too few.

    I hate bureaucracy but I also hate the appalling slap dash methods taken by far too many in this industry. It is possible to build quality systems and get them right first time – every time. It’s called Quality!

  4. Pingback: Maccherone » Visibility -> Retrospection -> Adaptation

Leave a Reply

Your email address will not be published. Required fields are marked *

Spam Protection by WP-SpamFree