Learning to Lead

The Economics of Design Complexity

Evan Hoff — Sun, 05 Oct 2008 23:26:22 GMT

This isn't specific to software. This works for pretty much anything large and complex (i.e. electronics).

First, there are two milestones of complexity.

Size - Designing an item which cannot be designed by a single individual.
Knowledge - Designing an item which cannot be understood by a single individual.

The first often shows up in typical "business app" developments. The second, however, is much more rare (in my experience). I would guess it's typically exemplified by large code bases (greater than 500 KLOC) or complex problem domains (military and scientific domains, some finance, etc).

Regardless of whether we are talking about software or some other complex artifact, there is one shared economic factor. Given either milestone, there becomes a need for a coordination mechanism among the designers.

The economics of designing a complex artifact are directly tied to the efficiency of the coordination mechanism of its designers.

If you want to reduce the cost of producing complex artifacts (i.e. software), you have to focus not only on raising the productivity of the individual designer but also on the efficiency of coordinating those designers.

In small development teams, this comes mostly in the form of communication. Better and more frequent communication typically provides better coordination among designers (developers).

You see this embodied in many of the practices of a highly efficient development team: the team room, the information radiator, kickoff meetings, retrospectives, and customer demos (to name a few).

When remote developers are in play (i.e. offshoring), the economics and coordination mechanism change (unless the entire team, including stakeholders, is offshore).

When multiple teams of developers are in play for a single artifact, this also changes the coordination mechanism. A good architect will know that based on the communication obstacle associated with having multiple teams, each team will work better if loosely coupled from the others. This means employing a loosely coupled design boundary between the design artifacts owned by each team.

That's an odd thought the first time it comes across. The communication structure of the designers should be embodied in the design of the artifact. But after a while, it quickly appears to be common sense. This could actually be phrased more as a law than a principle, because the communication paths of the designers will be reflected in the work they produce. Either account for it in the architecture, or let it show through later (in the form of bugs and issues).

Another interesting area to explore in software is readability. In codebases and teams steeped in Domain-Driven Design, for example. The code itself becomes a communication mechanism. This is where qualities such as readability and comprehensibility are both prioritized.

MDA: Model-Driven Ambiguity

Evan Hoff — Fri, 26 Sep 2008 03:27:34 GMT

I've collected a few bounded contexts on the usage of being "model-driven":

Model-Driven Design: being driven by the need to capture a model of the problem space in the structure and elements of a software system (see: Domain-Driven Design)

Model-Driven Development: allowing the process (activities/workflows) of forming software structures to be largely driven by a model (i.e. a Use Case Model) of the desired deliverable (see: Unified Process, Rational Unified Process)

Model-Driven Architecture: allowing the platform-specific implementation (i.e. c#, .NET) to be driven (or generated) off a Platform Independent Model (PIM) captured in UML (see: Model-Driven Architecture or Model-Driven Software Engineering)

With the big push for Oslo, we will have another major "model-driven" initiative in play. I'll be interested to see which of these definitions (if any) align with Oslo's goals.

Free Hosting and CMS for UGs

Evan Hoff — Thu, 18 Sep 2008 00:37:48 GMT

I just ran across this offer for User Groups, so I'm definitely going to have to investigate.

Telerik (the controls guys) are offering a free standard license ($899) along with free hosting from discountasp.net for user groups.

And I do have to say that the showcase sites don't look half shabby:

The Nashville user group has had its web site under overhaul for way too long, and this might be just the thing to get the site knocked out (look Ma, no code!).

I've had great experiences with discountasp.net in the past, so that's a definite win.

I originally had intentions of moving the site to Community Server but recently learned that CS + discountasp.net is a bad combination. Without any load, CS eats about 100MB of memory, causing websites to hit their memory usage threshold at the hosting provider (and having their App Pool recycled). That's just nasty.

Maybe Sean (a Los Techies rock star) will some day fix this for us. :-)

The Google Bus

Evan Hoff — Thu, 18 Sep 2008 00:15:05 GMT

Living in Nashville, Tennessee, I don't see a lot of swag from the likes of Google, Yahoo, or the other big techies out in California. Today, however, I managed to bump into the Google bus parked outside P.F. Changs. Way cool!

Apparently, they are on a cross-country campus tour.

That Architecture Thing

Evan Hoff — Tue, 16 Sep 2008 01:57:42 GMT

I'm going through the Patterns and Practices Application Architecture guidance. The first place I'll start is with the Architecture and Design Guidelines.

Let's start right at the top:

Software Architecture is often described as the organization or structure of a system, while the system represents a collection of components that accomplish a specific function or set of functions. In other words, architecture is focused on organizing components to support specific functionality. This organization of functionality is often referred to as grouping components into “areas of concern”. The following diagram represents a common application architecture with components grouped by different areas of concern.

I want to hone in here on the word "component." It's true that the architecture of many systems is composed of components, but is that really the best way to describe it?

Component-Based Development

Judging by the rest of the document, the word component here has a very specific meaning. This meaning comes largely from the practice of Component-Based Development. I don't want to go into specifics on this here, but I will point you to a couple resources for more information.

There's a good podcast on this topic from Software Engineering Radio.
There's a classic book written by a Microsoft Researcher on this topic.

One of the key things to remember is that CBD guys see Components as an evolution of the Object. I'm not going to say their perspective is wrong. It's just important to realize that it's *different* from many of us still writing object-oriented systems. This includes everyone from Martin Fowler and the DDD crowd to the growing crowd behind Rocky Lhotka and his Business Objects.

The other thing to notice is that we don't have to agree on everything, but that the Component line nicely divides most developers that care about such things into one of the two camps.

Back to that Definition

So the question is, how do you address a topic such as architecture in a way that doesn't clearly identify with one of the two camps?

Luckily, this has already been done for us. Indeed, it not only works for both design camps, it works with all the others as well (such as the growing crowd of functional programmers).

From the book, Software Architecture in Practice:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

You'll notice we've swapped the word "component" for element. This covers us for all crowds: components, objects, and functions. In addition, we've introduced the notion of "externally visible properties" into our definition.

At first glace, this may look like black magic, but after deeper digging, we learn that the "externally visible properties" of the architecture are really its quality attributes: availability, modifiability, performance, security, scalability, testability, usability, etc.

While I don't expect a guidance document to fully describe the use of these attributes to design our architecture, exposing these properties of any type of example architecture does two things:

It draws some type of line for where the architecture should not be used
It gives markers for a developer reading the document to find his own way or look for reference material for additional clarification

P&P Recommendation: Reword this document so that it's less specific to components (as much of the content already is). If a sample component architecture is desired, move the component-specific stuff into it. Be careful of labeling component-based development with a guidance label (sans "sample"). Otherwise the community *will* use it as the defacto standard.

Back to Business

Evan Hoff — Tue, 16 Sep 2008 01:01:18 GMT

For the recent past, I've been sporadically posting over at Los Techies. The keyword in that last sentence was "sporadically."

I've come to the decision that I'd like to refocus my efforts on blogging. As part of that decision, I'd like to move back to my own domain.

I do, however, want to thank the great guys over at Los Techies for hosting me. They have a rock star blog lineup, and if you don't subscribe, I'd highly recommend it.