“While an architect spends their entire life learning less and less about more and more, until eventually they know nothing about everything.” 

adapted from Charlie Alfred's blog post

On being promoted to one's level of incompetence (about HP's CEO, Mark Hurd):

"Our theory on people was that you give them responsibility," says Gilbert Williamson, a CEO of NCR during Hurd's rise. "To my knowledge, every time we threw Mark out the window he landed on his feet. So we moved him up a floor..."

Mark Hurd's Moment, CNN 2/27/09 (and Fortune magazine, 2/2009)

The differences between the genders leave a lot to laugh about! 

"Thought for the Day: Married men should forget their mistakes. There is no need for two people to remember the same thing."

This one is good for talking about the importance of visualizing/drawing:

Sir Ken Robinson's "drawring" joke is great too, and it works for architecture—you know, when you're sketching your architecture live, you can tell the joke and follow it up with "but no-one knows what the system will look like" and "they will in a minute." And then you can talk about the setting in which the joke is told—the setting being a child's willingness to take a shot, to be wrong, and set your audience up to give you input because you have shown boldness in taking a shot, but also humility and a willingness to be wrong.

On visualization and perspective:

where the course gets tougher

Quotes about humor and leadership:

Liven up a meeting with funny signs:

Allen Klein, an award-winning professional speaker and author of The Healing Power of Humor. His favorite funny sign: "Never wrestle with a pig. You both get dirty, and the pig likes it."

— 19 Ways to Enhance Your Sense of Humor, Reader's Digest, 12/1/08

I read through several jokes on the Reader's Digest joke site, and this one tickled me:

It is so rare to be offered a meal on airlines these days that I was surprised to hear the flight attendant ask the man sitting in front of me,

"Would you like dinner?"

"What are my choices?" he responded.

"Yes or no," she said.

You want a tech joke—try this one. And funny stuff on this site—including engineer jokes like this one:

"Normal people ... believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features yet."

And all because "we're going to be dead for an awfully long time!"—we might as well have some fun while we're still here. Actually, I'm hearing from various sources (Don Norman, Tim Brown of IDEO, etc.) that play, fun, humor is important to creativity. And creativity is important to innovation--in the large, and in the small.

4/3/09 HP's Hurd

On time management and doing what's important:

'As it turns out, Hurd can tell you exactly how much time he spends with employees, customers, shareholders, and so on, thanks to that spreadsheet he keeps to manage his time. In fact, he can break the "customer" category down by segment and by what portion of the "total available market" he personally has approached. The point, he says, is to be mindful of his scarcest resource. "I only have a certain amount of time to spend," he says. He doesn't read books, has played golf only three or four times in his life, and devotes the rest of his leisure to playing tennis, watching sports or movies, and hanging out at home. His customers in Phoenix were dejected that he wasn't joining them for the All-Star Game. Said Hurd: "I've got a family."

Customers still feel loved, though. "He is personally self-effacing, modest, unassuming, and, I dare say, shy," says Jeffrey Katzenberg, CEO of DreamWorks Animation, which runs its digital studio on HP gear. "But you get him talking about his business, and he explodes." Hurd also is attentive. Christian Anschuetz, chief information officer for Underwriters Laboratories, says Hurd was quick to send a congratulatory note when Anschuetz took a new job. "There are people below him that are far less responsive than he is," says Anschuetz, adding, "I have two large outsourcing contracts I'm planning to put out for bid. You'd better believe I'll make sure HP gets on the list."'

Mark Hurd's Moment, CNN 2/27/09 (and Fortune magazine)

If you get push-back on spending time at (potential and angry) customer sites, just point to Hurd. If he can make time to pay personal attention to (selected) customers, so can architects—and so should architects. Hurd needs this access to customers so he can have good intuitions about priorities. Intuition—or the subconscious working of the mind—is absolutely vital when it comes to tradeoffs. Yes, you have to have good intuition about the technical ramifications of your decisions! And good intuition about the ramifications for customer value, for creating engagement and delight. 

4/3/09 Roadmaps, Projections and Scenarios

Often when people talk about roadmaps they're talking about product/portfolio roadmaps, which are used to track and manage feature releases and make visible, and so better manage, internal and external project dependencies. Architects use and contribute to these roadmaps, tracking technology/infrastructure dependencies and planning for capability development.

But technology roadmaps can be used as a strategic tool, not just a project planning and management tool. Indeed, this is a great time to demonstrate the value of using technology roadmaps to explore opportunities and threats. Dana Bredemeyer likes to call roadmaps used for this purpose "projections." Of course, the companion tool is "scenarios" a la Art of the Long View — you could call these "what if" scenarios.

Stephen's list of questions (on the Bredemeyer Software Architecture Workshop Alumni LinkedIn group) has primed us for a great set of "what if" exercises. Yeah, it takes time and who has any with shrinking headcounts, but let's put aside the panicky reactions we've been seeing all over the place, and focus on looking forward. It is energizing to be thinking "It's Spring!" (at least in the Northern Hemisphere) and "What are our paths to renewal and growth?". The purpose of these "projections" is to think about what changes should feed back into the product/portfolio roadmap (at least in the form of contingency plan footnotes).

What are the big trends that are going to overshadow all else over the next 2, 5, 10 and 20 years, and how do we position for those? (Is 20 years too far out? Hint: "engineers tend to over-estimate what they can do in one year, and under-estimate what they can do in ten" — I believe it was Bill Gates who famously said that, though he was prefaced.)

• Where does climate change go and what does it mean for various industries? Insurance? Energy? Military? Transportation? Agriculture? How does all that spill over into implications for your industry?
• Where does the "Necessary Revolution" (Senge et al) in cradle-to-cradle production, use, and recycling take us? Are we running out of critical minerals, depleting the oceans, drawing down forests and canopy, putting mercury into our water supplies...? How does all that spill over into implications for your industry?
• How does social networking change the way business is done, and what organizations look like? how products are invented? built? marketed? supported? We see the precursors to a lot of change, and we need to think about how these forces are likely to impact our industry...
• How does the cloud reshape the landscape? Software productivity trends? (So significant threats in a variety of industries can come from under-25s with little to no funding! More and more, the only barrier to entry is not being tech-savvy, and having too much to lose...)
• How does globalization—and deglobalization—change things?
• What are the other big landscape reshapers we should have on the radar?
• And that is just talking about the "big stuff" that is obvious to me. With each trend, we can ask what does this mean for our business? What specific opportunities and what threats do we see emerging?
• How do we get consumers and corporations to take their foot off the spending brake with opportunities so compelling they just have to get excited?

I've been thinking we need to get corporate leaders to talk about their economic stimulus plans... to do that, they need IDEAS—indeed, a projection/roadmap. Yes, yours! (Rah rah! etc.)

And this is not just the bailiwick of chief architects like Stephen, Allister and Charlie. In times like these, we can't afford not to own the success of our companies! (Again, rah rah! etc.)

So, I guess you'll be busy this weekend. :-) But remember, the best projection flavored roadmaps are created in a diverse team. (If you're having a hard time finding girls to play too, I just happen to know one.) And you might want to experiment with de Bono's six hats.

Or, you could just take the porcupine approach.

"Everyone's hurting, but especially companies clinging to old business models."

— Jim Zemlin, interviewed on LinuxDevices.com

4/4/09 Principal Principles

Jeff Wallk suggested the following general themes for EA principles:

• Agility: ensures we can respond quickly to changes in business needs
• Efficiency: ensures we can deploy technology with a low consumptions of resources — human and otherwise
• Adaptability: ensures the technology can embrace change — timely, easily, and where possible w/o human intervention
• Extendibility: ensures the technology can scale (vertically to meet growth volume of data & users, and laterally to meet growth in complexity of functionality)
• Innovation: ensures we can bring new value to the business by identifying new technologies, leveraging existing technologies in creative new ways and pioneering technology where possible through collaboration and by encouraging ideation

I really like that!

4/9/09 Steve Vinoski on REST

I watched Steve's QCon talk on REST on InfoQ last night. Now, Steve is the ultimate in self-effacing, and while the fact that I've long admired him may not impress you, his record should stand for itself. And when he has swung about face on RPC-styled architectures and is pitching REST that means something! Steve (like Charlie Alfred) is championing Roy Fielding's dissertation as a landscape reshaping moment in software architectural history. I strongly recommend Steve's talk, and Roy Fielding's thesis. So, who is designing REST-styled architectures? I'd love to hear how you are thinking about that and see what you are doing.

4/12/09 Happy Easter/Passover/Chocolate Day/Just-Another-Day Day

4/13/09 Wants versus Needs

This cartoon from the New Yorker caught my attention.

While taking a walk on the funny side, this Dilbert is Hagy-good!

4/13/09 You're My Genius!

One evening last week, I unwound watching TED videos on creativity-related topics. Elizabeth Gilbert talked about where creativity, or inspiration, comes from, and relayed the ancient Greek and Roman thinking on creativity:

"But, ancient Greece and ancient Rome — people did not happen to believe that creativity came from human beings back then, OK? People believed that creativity was this divine attendant spirit that came to human beings from some distant and unknowable source, for distant and unknowable reasons. The Greeks famously called these divine attendant spirits of creativity "daemons." Socrates, famously, believed that he had a daemon who spoke wisdom to him from afar.

The Romans had the same idea, but they called that sort of disembodied creative spirit a genius. Which is great, because the Romans did not actually think that a genius was a particularly clever individual. They believed that a genius was this, sort of magical divine entity, who was believed to literally live in the walls of an artist's studio, kind of like Dobby the house elf, and who would come out and sort of invisibly assist the artist with their work and would shape the outcome of that work.

So — brilliant — there it is, right there that distance that I'm talking about — that psychological construct to protect you from the results of your work. And everyone knew that this is how it functioned, right? So the ancient artist was protected from certain things, like, for example, too much narcissism, right? If your work was brilliant you couldn't take all the credit for it, everybody knew that you had this disembodied genius who had helped you. If your work bombed, not entirely your fault, you know? Everyone knew your genius was kind of lame. And this is how people thought about creativity in the West for a really long time."

transcription of Elizabeth Gilbert's TED talk 

So, it occurred to me—you are my genius! Anything good I write is entirely up to you! I'm pretty good at configuring words, and you're the genius on the front lines of learning about architecture. It is all so much clearer to me now, thanks to Elizabeth Gilbert! Of course, if my work bombs, I won't say my genius was lame! Still, you know and I know it's all up to you. 

4/14/09 Technical Debt and the Cost of Quality

Martin Fowler has a nice post on technical debt. It might be worth pointing out that while some people manage their finances carefully without even giving it a lot of thought, others get themselves into crippling debt and leave the rest of society to pay the price of their indiscretions.

Bad code becomes a broader societal problem and we need to start to take our systemic impacts into account! This isn't just true for embedded systems code, though I want to be sure that my steering and brakes are going to work all the time, under any conditions that might be thrown at them. It is also true, though perhaps not life-threatening, for web applications. Perhaps. If I had a short fuse and was prone to hypertension and suffered from high cholesterol, some of my experiences with time wastage and lost data might have put my life in jeopardy... Nonetheless, some of these experiences have cost the vendor in question business, and others have tarnished their image (which may cost future business). That's what bleeds out in terms of direct impact to the customer of unintended (so hard to "test out") consequences of technical debt.

It can help to visualize the technical debt, using tools like Sotoarc, Lattix or NDepend. And it helps to be self-disciplined, not incurring wanton debt for the sake of short-term gratification and unscrupulous excess.

So much for the debt analogy. It is useful, but perhaps it puts the attention in the wrong place—we start to wonder how much debt we can live with.

Because there's debt, and then there's risk, and the lessons from the quality movement apply here. First, the "cost of quality" refers not just to the cost of finding quality issues (reviews and testing) but also the cost of un-quality--the cost of defects or quality issues including those that impact product/system, and ultimately brand, integrity.

The quality movement recognized that the cost of finding and fixing defects together with the cost of defects that leak through all the test barriers and reach the market can be so high as to warrant process improvements to reduce the number of quality issues created in the first place. Well, that's in manufacturing. In development, we also need to do what is reasonable to avoid creating defects. But some of our quality issues relate to uncertainty and the concomitant chance that we make choices that turn out to be ill-advised, so we seek to discover quality issues as early as possible, to remove them before their effects multiply. But we recognize that this must be an ongoing process, as we learn and resolve some of the uncertainty. 

Quality issues that are architectural, typically carry the highest cost of change because they have systemic impact—if they are not discovered early. Architectural issues that creep up on the system, like increasing coupling and dependencies, increased duplication of code, etc., bear costs in terms of increasing the likelihood of defects and erosion of the user experience and business value. The defects may be harder to detect and isolate for the very reason that they were introduced--the impact of changes is hard to isolate. If detected late, the cost of refactoring-in-the-large, redesigning a core mechanism, etc., may be high enough that the program management decide not to take the schedule hit and ship anyway—increasing the cost of quality, but pushing out the point at which the price is paid.   

Quality issues that reach the customer have all kinds of costs that run the gamut from safety or hassle factor/productivity hits to lost business and damage to reputation/branding. The cost to Microsoft of Vista crashes is un-estimable, and the cost to users? I can't even imagine! Vista is an easy target, and I have a love-hate relationship with it—mainly, there's a lot to love, which is part of the problem. It is easy to take pot shots but one has to remember that Microsoft faces a unique problem which is rooted in its success—the user base is incomparably huge and so varied, and then there's all the backward compatibility demands, and on and on. Twitter too ran into the price of success—how much did Twitter lose when it could not scale/saw service outages? Perhaps it was just some temporary egg of their face, but perhaps it also pushed untold numbers of users Jaiku's way. At the very least, it caused the question "Who is Twitter's competition, anyway?" to be raised.

We need to broaden our quality frame from bugs that cause partial or outright system failure and specifically include design flaws and missed market targets ("requirements" or functional design flaws) into our quality considerations. Yes, these costs are hard to measure (shading into opportunity cost, which can only be estimated). But so is the cost of system failures in the hands of users. Design flaws run a spectrum from design issues that cause inconvenience, frustration or productivity loss (slow startup times come to mind) to designs that simply don't deliver the value the user seeks (the IRS modernization case study teaches by counter-example).

When design and implementation are conflated, some things become easier, and some harder. With agile, "the customer" gets a feature/story/piece of the working system to respond to, and then more, etc. Where this all fits in the systemic picture of structural integrity and system fit to context and to purpose, however, is harder to assess if no-one—not "the customer" nor the development team—holds that "big picture." Then it is up to evolution to manage the random walk that tunes out and tunes up until a dominant design emerges from all the experiments. The question then is—can this evolution be speeded up? If so, it must be speeded up in terms of finding the high payoff market target and the architecture that is a good match (fit to context and to purpose) for that conjoint value set.

Quick-and-dirty experiments (using thought experiments with hand-drawn sketches, for example) that illuminate architectural flaws early are invaluable, because the same flaws may not be found during early tests as these tend to be local (component, service and feature-centric), not systemic. 

VAP applies agile principles to architecting, to concurrently explore the value profile of stakeholders and the architecture that fits that value set. The key ideas of experiment and adaptation are driven earlier, to increase the rate of learning about the fit of the value set and design to the market and the organization sponsoring the development as well as the development teams. This learning, assuming a process that keeps the people involved flexible and open to changing the design (both in terms of the value propositions and function, and in terms of structure and system behavior), is central to adapting, and we have built mechanisms into VAP to foster learning and flexibility (countering the tendency to get one's ego locked in on an approach, and addressing the inherent filtering/bias problem).

When just enough design is done to have a good enough sense of the value propositions, system concept and architecture, the agile cycles can switch from experimenting with models and thought experiments, and proof-of-concept mockups and prototypes, to building out the system. There is still a good degree of experiment and innovative problem solving to be done, but the target (in business value and structural terms) is in the sights of the team.

Of course, once a system is fielded, the degrees of design freedom become more limited, but the market is generally better understood by that point too. 

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan

“With good program architecture debugging is a breeze, because bugs will be where they should be.” — David May

Some Twitter scaling references:

• Twitter, Ruby, scale and speed: 5 Question Interview with Twitter Developer

More IRS modernization references:

• Developing Software, The Economist, 11/25/2004
• Could George Washington Have Saved the IRS' IT Systems?, Software Magazine, 2/2004 by Jim Johnson

Collection of links and observations on software failures:

• Software failures, Resources for Software Architects (bredemeyer.com)

4/14/09 From Organic Architecture... to... The Grim Reaper (a.k.a. the Justice Department)

I stumbled upon and read Tom DeMarco's article "On Systems Architecture." Written in 1995, it provides a great window on history, and DeMarco's perspective on it. The "box whallah" story is a great example of an (organizational) organic architecture. Some of DeMarco's observations are grounded in his definition of architecture:

"An architecture is a framework for the disciplined introduction of change. This is also a pretty good definition of design. The difference between the two is that design, as we commonly use the word, applies to a single product, while architecture applies to a family of products."

For example, DeMarco's estimate of the cost of architecture is based on his definition—the architecture for a product family costs more than architecture for a single product.

I like this insight:

"Design is always concerned with capacity to accommodate change. This is true even of the extreme example of a system which is to be run once and then thrown away. It still makes sense to design such a system, because it still has to be able to accommodate one change, specifically the change that is the implementation process. (Here I portray implementation as a change from concept to reality.)"

In other words, design (first in models and mock-ups, then in code) helps us implement a system! This is something we've been losing track of, to some extent, in the agile movement. Models help us think! They help us deal with separate concerns separately. They help us deal with abstractions in terms of abstractions. Models are not the holy grail. Actually, nor is code! Value is the holy grail, and models (with descriptions, explanations, justifications, defenses, etc. in words—i.e., documentation) and code help us find our way to the holy grail!

[4/16/09] I watched Tim Brown (of IDEO) talk about creativity and play (video on TED). Tim makes the point that "thinking with your hands," for example by building low resolution prototypes (e.g., using masking tape and children's clay), stimulates creativity. It helps to quickly get your thinking into the real world so you can test ideas much more quickly with users. We tend to think that because code is so malleable, and because we do have very productive prototyping languages, it is the best route to these early experiments. Surely it is a good one! But therein lies the danger. We tend to overlook other "hacks"--a cereal box or storyboard, role play, pictures, brainstorm lists... Creativity needs a palette of more colors than black and white! Think "and."

4/14/09 Software Architecture and Reuse

• Variability in Software Product Lines, Bachman and Clements, SEI Tech Repot, 2005

4/14/09 Dalgarno Links

These posts by Mark Dalgarno are useful:

• When Good Architecture Went Bad (I like the idea of case studies like those MD used for our "architecture deployment" module of the workshop)
• Snowflakes and Architecture: layers considered harmful

And this by way of Mark Dalgarno:

• Architecture Analysis, Bernhard Merckle on Software Engineering Radio

Architecture analysis tools may cover:

• consistency: check the existing architecture (the code base) against the intended architecture; you describe the architecture in a language which is tool specific, stating rules/constraints from the architecture and the tool checks these against the code. You can then do refactoring in the large. Note: tools give an awareness of problem areas, but you have to define the constraints and you have to fix the problems. You can do virtual refactoring—that is, you can simulate refactoring by moving the packages or classes in the tool to see the effect without changing the code.

• rating: says something about internal software quality, like high coupling or bad smells. The tools generally come with predefined set of bad smells/anti-patterns; it makes you aware of the problem, and you fix it.

• discovering your architecture: This applies, for example, when there is no good documentation. In some of the tools you get a graph layout and you can see which interfaces are not used at all, etc. Q: You want to rediscover the intent, and that is not in the code. So how good are these tools? A: They use intelligent layout and apply graph algorithms and you see essential abstractions on one diagram. They give you a good visual clue as to what is going on!

• metrics: measure the real facts—"you can't control what can't measure." Measures include complexity, instability, and number of overridden methods. The challenge is to select the right metrics! Q: Is the value of metrics not the absolute value but rather how they evolve over time? A: The trend is also important but the absolute number is important—e.g., look at outliers.

• monitor changes over time: coupling increasing? —find out while there is a chance to reverse the trends. Most of the tools do monitor over time so you see the trends. That way you can catch and deal with a trend before it is really burnt into the project. Outsourced projects should have trend monitoring, for better project control.

Structural analysis tools:

• Sotograph

• Bauhaus 

• SonarJ 

• Structure101

• Lattix

• Klocwork K7

• XRadar (opensource), JDepend

Closing thoughts: You have to enforce the architecture, and the tools help you do this.

— Bernhard Merckle and Markus Völter (interviewer), Software Engineering Radio

4/15/09 Analogies and Metaphors

• heartbeat metaphor in system (health) monitoring: SDL Design Patterns and Components — Watchdog and Heartbeat by C. Webel, I. Fliege. See also general purpose watchdog, heartbeat in Linux-HA (high-availability architecture), OpenSSH heartbeat/watchdog patch, (related: watchdog timer guidelines)

4/16/09 Taking On Too Much

The tipped donkey image used on this post is great! It reminds me of an archman picture Sara drew... must scan in... must scan in... it relates to agile development. And may do a better job than the pyramids...?

4/16/09 Complexity — Simplicity

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.” — C.A.R. Hoare

“You know you’ve achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.” — Antoine de Saint-Exupery, Wind, Sand and Stars

"A child of five would understand this. Send somebody to fetch a child of five."  — Groucho Marx

"A man must be able to cut a knot, for everything cannot be untied; he must know how to disengage what is essential from the detail in which it is enwrapped, for everything cannot be equally considered; in a word, he must be able to simplify his duties, his business and his life." — Henri Frederic Amiel

"Everything should be made as simple as possible, but not simpler." — Albert Einstein