StartingTheArchitectureSessionEarly

Let's begin the architecture session (SessionTwo018) before we are physically present in Phoenix.

I want to create a workshop where we can help one another with strategies for building ourselves as better architects / designers / leaders. Some of us may have current career or other challenges that we would like help with. Others of us may have wisdom and experience that we would like to offer up. In this session, I am hoping that we can connect up ourselves so that useful exchanges happen.

So, think about these rhetorical queries...

Have you finished the job of growing yourself as an architect?
If not, do you want to advance your growth?

Write down current career or other challenges you are facing that you might want help with - either here online or on paper to bring with you into the session.

And, write down areas of particular wisdom or experience in which you can offer assistance, again either here online or on paper to bring to the session.

I hope that we can begin to form groups form early - either directly via discussion here or virtually in our collective mind's eye - so that when we get together in Phoenix our workshop is already started.

Thanks, BobKing

Back to SessionTwo018

Bob, I'm currently likely to miss the session due to conflict with Jean's session. However, I'd like to at least virtually attend. One of the pieces of wisdom I've found is that architects need to transcend the "just now" of requirements and visualize how the requirements are likely to morph over time. Preparation for this includes some stints on mature (legacy?) systems in maintenance, and preferably the opportunity to follow at least one system through initial development into later maintenance. This gives the deep understanding of essential vs. transient requirements.

Living through adapting systems after chaotic change (a merger, acquisition as a field-developed product, etc.) or at least studying the effects. This helps make visible assumptions of "that's unthinkable".

An architect should seek retrospectives like a magnet.

A challenge faced by large system projects: their completion times are so long, you can't get many under your belt. Since archtects grow more important as the system complexity & project size/duration increases, these are the learnings that are hardest to gain direct feedback experience from. A friend pointed out in 1989 that you only get a chance to experience a limited number of big projects. What can we do to teach the big complexity dynamics experientially?

I'm also quite interested in the integration of "Agile Methodologies" with the viewpoint and function of Architect. For instance, XP is explicitly (so far) for projects in the small to medium, and doesn't encourage specialized roles. Some of the Scrum projects have been massive and appear to depend more on architecting and strong tech leads to partition the problems into agile development.

--BobLee 2002-10-04

Fantastic - Bob, thank you for your wisdom. I will miss having you in the session, but appreciate your virtual participation.

Perhaps a step further is for an architect (designer?) to stay close to those who are reaping what he has helped sow...to listen to what coders and testers say as they develop, test and maintain in the frameworks provided by the architect.

I have been wondering lately if, as I help architect and design an application, I should also carve out a piece for me to develop and implement as well. I think this would help me anchor my thinking in a more practical way as I work across the multiple pieces of an application. But there is only so much time in a day.... BobKing 2002.10.04

and Bob, you inspired another thought about the structuring our virtual session. I will mine this discussion for threads and place them on the session home page (SessionTwo018) BobKing 2002.10.04

Another issue I'd like to gain wisdom in is gaining trust and good working relationship between managers and architects. While I believe they are complementary (maybe even complimentary sometimes...BK), there seems to be difficulty in hiring / interviewing. I believe that managers can find architects scary to engage -- "Hey, this guy knows more tecnical stuff than I do -- can't afford that on this project!" -- BobLee 2002-10-04

One of the problems I have seen most often is a reluctance to have all the groups who work on a system represented from the beginning of a project to the end. For example, there are often no testers on a project until development is nearly complete, while business analysts and architects (by some definitions) are often gone long before we arrive. Yet when we overlap, the different perspectives help us all. What can we do to increase our understanding of the other perspectives, so that the effect on the system is not as serious? (Yeah, OK, my preferred option is to have all of us there at once, but I would like a second best alternative.) SherryHeinze 2002.10.05

I have often wondered about the relationship between the project manager and technical leader on a project - in fact, Steve, Esther and I hosted a session last year with this as the topic. One of the things I remember from that session is that often the technician and the manager are very different and do not go far enough in trying to understand the other person. Many assumptions are made on both sides which can lead to misunderstandings that can have a bad impact on a project. On the other hand, I remember being struck by how close each others' objectives and even methods meshed - even though that was obscured by the assumptions made on both sides.

Sherry, yours is a very good point and one that I am running into right now in my job. I am running a project (and I am also the technical lead - more on that in a second) and did involve the testing group as the requirements began to solidify. They were interested and did not have the time then to become involved. I continued to engage them at points through out our effort; they listened intentively and were still to busy to really engage. Now, code is complete and we are behind the 8 ball in testing - will probably end up doing most of our testing in production, unless I can hack together some test data real quick. I did not find a nice second alternative...

Here is a question that I am pondering right now: Can one person do a good enough job of being the project manager and the lead technician on a project?

Sure, if everything goes right. --DaveLiebreich 2002.10.06

Gee, Dave, I would not have taken you for a wild-eyed optimist.

Getting the testers involved early enough is something I have only seen work when a senior testing resource was assigned full time to a project from the beginning to test the analysis and design, review the project charter, & so on. Any time not required for that was spent preparing a test plan, test strategy or any testing documents required, discussing test environments with the technical lead, doing high level test planning stuff. Testers are a lot like developers - most of us are more interested in testing code. (There are exceptions to that rule.) And, if we are working on more than one application, the one about to be released will win.

SherryHeinze 2002.10.06

Sherry, might you be describing a QA/Test Architect? Should certain projects have a team of architects (System, Test, Outbound Marketing, etc...)? And maybe I should have written "Sure, iff everything goes right. Which it won't." --DaveLiebreich 2002.10.06

Sherry and Dave, Here's another thought that has been wildly unpopular:

I have always been a proponent of clear, verifiable requirements and involving testers early. The unpopular part has to do with making the people writing requirements do the best possible job they can do and record the relevant detail, where possible. Naturally this will vary from system to system, nonetheless, I am always amazed at how resistant people are to being clear about problem statements and the details implied by that.

Any insights?

- BeckyWinant 2002.10-06

Becky, one problem with capturing detail early is that participants get invested too soon in the details. "That's too hard to review" and to change. For converging on better requirements, you want low-threshhold to reconsidering rather than, "It's unthinkable to reconsider that 150 pages of requirements!"

Consider agility: XP uses index cards to fight the premature lock-on when gathering use cases as user stories. You want low-inertia artifacts to avoid positional in-fighting. --BobLee 2002-10-07

XP also insists that every requirement (use case, feature definition) should be expressed clearly enough that it can be captured in a formal notation. Juxtaposing these two characteristics is interesting, maybe... --LaurentBossavit 2002.10.07

Becky,

Could the resistance be due in part to the fact that many tech folks are not comfortable, and therefore do not like, writing? You, and I, and probably everyone else who has been pecking away at their keyboards filling up this wiki, are in the minority - we do not balk (too much :-) at committing words to paper (or file, whatever). But I think the rest of the folks in the software industry are not necessarily like that.

I don't know any programmers who get paid for not writing! The volumes of code I've seen don't seem to point that way. -- BobLee 2002.10.07

- DaveLiebreich 2002.10.07

Dave, I am very intrigued by the idea of a project with many different architects with varied skills. I would like to try that. I am also very interested in the concept of a QA Test Architect.

I think we have here a group in need of a project, but I am not sure where we can find a project. There is some work here, but almost no development projects yet.

Becky, a couple of years ago I worked on a project that had many changes made in a 2 week period to a 200 page requirements document, because the client decided to do serious revisions. The project manager got hard nosed & insisted on change requests for all changes. We ended up with 51 Change Requests (with costs) and over 150 Clarifications (no charge, but a change). We came in on time & on budget. We tried to introduce an Agile methodology after that.

SherryHeinze 2002.10.07

Bob,

participants get invested too soon in the details. "That's too hard ro review" and to change.

Hmmm. To me this begs another question: how do we make "requirements" a less daunting process and easier to change? XP provides much of the answer, as methods are explicitly flexible. A plus.

Given that not all software problems/systems involve human interaction, how do we deal with self-contained systems that people depend on? Example: You have to define the requirements for software to control the engine and transmission functions in a vehicle. The pressures are cost containment for testing and manufacturing. We don't want to put software out that hasn't passed some rigorous test already. Software that isn't specific won't even drive the engine or vehicle! And, there is the risk factor. If we don't get it right - really right - we could be in for some lawsuits (Welcome to America). How could you not want to be a clear as possible and complete as possible (knowing that 100% is impossible) up front?

The amazing thing to me is that even though you would think that different systems would naturally elicit different mind sets, the reality is that even in some engineering situations (trains, planes and automobiles), people still resist detail.

Perhaps, instead of requirements (as if this is "it"), we should call the first stage: Expectations. Would this change things?

- BeckyWinant 2002-10-7

Laurent,

XP also insists that every requirement (use case, feature definition) should be expressed clearly enough that it can be captured in a formal notation.

Thanks for that reminder. I agree with your thought that there is an interesting juxtaposition.

-BeckyWinant 2002-10-07

Dave,

Good observation about writing. Many people see this as torture. In fact, if I am expected to produce a "perfect" document, I would see it as torture, too!

I think one of the reasons I drifted into modeling was in an attempt to express something more simply and clearly than words. That and I've always understood pictures better than words. However, my experience says that words and pictures are both abused about equally.

Along with Sherry, I like the QA/Test Architect idea, too.

- BeckyWinant 2002-10-07

Becky,

My experience in IT at a shop that had grown up in embedded systems, made it clear to me that the two domains differ in essence in requirements dynamics. Embedded system economics and degree of isolation seem to thrive with early, exhaustive (to the state level) requirement specs. IT systems thrash and fail given that treatment. The new hybrid systems like cell phone designs with internet connectivity suffer from both dynamics and probably are poorly served by either crowd.

One technique doesn't fit all.

An architect needs to understand the dynamic/static trade-offs of the domain - failure to do so (by someone in control) leads to expensive requirements fiascos.

--BobLee 2002.10.08

I am not surprised that a discussion on software architects started with testing and moved quickly into requirements. Having started as a developer, I have found myself moving ever closer to front of the process as my career progressed. I think, in many ways, Agile and XP are reactions to same dynamic of having less than workable requirements. Having workable requirements is a necessary condition for success in software development. As an architect (or lead technical person) I find myself first figuring out if these exist and if not ensure that they are developed. BobKing 2002.10.10

Bob, you were wondering about how an architect might (periodically?) ground him/herself by taking on detail implementation tasks. I think that a good way to do this is to take on an occaisional small project, where the architect role becomes more of a tech lead role. My sense is that the bigger the project, the more specialized behavior is called for. Participating in a smaller project could help avoid fossilization:

Participate in the details of a new technology.
Reexperience the loosening of specialization that a small project generalist plays with.
Get a chance to explore new process ideas - like pair-programming.
Recalibrate your estimating with more current tecnology and process affordances. (But don't fall into the linear complexity trap!!!)

--BobLee 2002.10.11

I'd like some feedback on this agenda... As part of expanding my role at my company, I plan to start a discussion group on software design (noun and verb), tools, and so on. I hope to find a meeting room where we can arrange our chairs in a circle.

introductions - names, then have people stand up and arrange themselves according to:
1. new-ideas eager/reluctant
2. details-first / big-picture-first
3. preference for introversion/extraversion
describe participatory meetings, consensus voting
group defines charter of group norms
group defined charter of group and individual goals
if enough time remains, pick a topic for discussion (example: "pipes and filters" design pattern
pick topic for next meeting

possible topics:

design patterns (or some particular design pattern)
design notation (UML, Booch, other?)
designing using CRC cards
object oriented design in c, c++, etc.
modules and layers
design tools (particular tool - rational rose?)
separating gui/platform-specific and non-gui/platform-indepedant code
OO design principles (Robert Martin papers)
test-driven-design (regression/unit tests are a pleasant side-effect)
improving the design of existing code (refactoring)
design reviews of various projects

--KeithRay 2002.10.13

Keith,
How will you sell the sessions? Will attendance be voluntary (self-selection) or mandated? You'll need some time to get through part 1, to explain the significance and obtain their buy-in. Do you expect to have more than about 1 hour per session?

Suggestions:

These sessions will work best if we all participate rather than sit back and wait for some maestro to pour wisdom into our heads as we sit passively.
We learn best when we are free to make mistakes (without career limiting consequences) and learn from those mistakes. That requires a safe and forgiving setting.
We want everyone to engage, not just those who talk the loudest or have the most rank.
To establish our learning laboratory let's explore our differences and plan to accommodate those differences as we share and learn. It's more efficient to be able to learn from anyone's mistakes, rather than each experience all mistakes first hand

Let me paraphrase your first exercise:

Build safety and trust to allow the group to try things and learn from mistakes

Regrouping to visually recognize MBTI type preference dimensions:
- First, regroup by E vs. I - Extraverts vs Introverts discovers who will need extra effort to be heard, so do this first
- Second, regroup by S vs. N details vs. big-picture realistic vs. conceptual
- Third, regroup by J vs. P new-ideas reluctant vs. eager ain't broke vs. so break it
- Fourth, regroup by T vs. F decision mechanism clarity vs. harmony

I suspect that "creating & exploring a learning lab" may take your entire first session.

For the impatient, and for the those who chose to prepare ahead, you might reference Kaner, et al Facilitator's Guide to Participatory Decision Making which explores how groups need to diverge before they can converge on a non-trivial problem. The same applies to experiential learning. I'd also reference an MBTI interaction book such as Type Talk by Kroeger & Thuesen or Work Types by Kummerow, Barger & Kirby.

How are you going to get a return audience for the 2nd session, when you actually pursue a design topic?

You might want to try your exercises on the 2nd session
First, conducting a design topic session
- Insert "watch also how we interact" lead in
- Close with "what could we do to interact better next time?"

--BobLee 2002.10.13

Keith, your list of topics suggests an exercise that Jerry took our SEM group through. Have the group list topics they're interested in on cards (multiple cards per person is O.K.), then spend a bit of time with the group grouping the cards together on the floor, making bigger piles if cards have substantial overlap. Then ask people to stand near the group they're most interested in. This'll give you a quick read on where the group's interest really is, and a first cut at prioritizing topics.

DaveSmith 13 Oct 2002

Thanks for the suggestions... I'm sure the initial attendance will mostly be self-selected.... If the first meeting goes well, then I expect "later-adopters" to join in, and if success continues, then managers might be ordering people to attend. This means that I really want the first meeting to have some success, as well as making people aware of "reasons for disagreement on what constitutes a good design".

Bob: Of the three self-sorts I had planned, I wanted the extra/intra-vert sort to be last because the attendees will be mostly engineers... get them involved in movement around the floor before talking about that "touchy feely stuff". (I'm not expecting managers or HR people to show up for the first meeting, so I doubt there would be many Fs.) I guess I should do all four anyway...

How did you know I was reading Kaner?

It had that Facilitator's Guide ring to it, and the book has had some good recommendations on this Wiki. The cool part about Kaner is that you can copy and hand-out the pages for non-commercial use.--BobLee

KeithRay 2002.10.13

I just started reading Jerry's Exploring Requirements, Quality Before Design (1989), and hit an interesting bit of wisdom on page 90:

If your project seems to hold too many meetings, that may be a symptom of overstaffing. Alternatively, it may mean that the project organization is not broken down along natural lines of cleavage, so that nobody can do anything without affecting everyone else.

Jerry's older books can be hard to find since libraries keep flushing their stock rather than buy new shelving. It took me a while to track down a copy of it. (Sigh!) --BobLee 2002.10.16

Thanks to all for contributing so far! The session is off to a good start.

Any other architecture challenges you are facing that you might want help with? Or, areas of particular wisdom or experience in which you can offer assistance? BobKing 2002.10.24

One of my big contributions to projects is to design for failure. I try and make sure that when expected problems happen there is enough diagnoses so that the problem can be isolated quickly. This includes having readable log files with the right level of detail. This is closely related to designing for debugability.

This effort is part of an over all interest in including the system administrators (I work on "production" systems which have a dedicated staff to keep them running) in the set of customers who must be designed for. Usually the systems administrators requirements are not even stated. As I see it they need to understand the architecture and be able to monitor the bits and pieces for performance and perhaps take a piece of the architecture and bring it back to a previous version which worked better.

--KenEstes 2002.10.22

Back to Build You An Architect - SessionTwo018

Updated: Tuesday, October 22, 2002