Coordination takes time from developers, so we have to find an effective solution. This is a short story on how we have proceded this far.

One person is in charge of overall coordination of all projects. This person is the program director (which happens to be me). My initial job was to write about the common motivation for all projects, and a little more specifically about each project. Just a few short sentences.

The next step was to appoint project leads for planning each project that had dependencies. Our principles for project leaders are simple.

We trust you. Go ahead, be a dictator, make decisions.

So, you start out with trust. Trust is good. We are a competent set of grown-ups. To keep this trust during the project, and to avoid any doubts and second guessing at the end of planning, we encourage the following process.

• Listen to opinions. All perspectives are valuable. (Customers and co-workers alike) This means that you have to seek these opinions out early in the process, before establishing assumptions and making decisions.
• Disregard opinions if you have to. If there is a very specific opinion that you’ll like to disregard, document the opinion and the reason why you disregard it.
• Inform, but don’t stop and wait. No approvals needed, we trust you, remember?

Consider the figure below.

Think of each colored circle as an opinion. It’s a good quality that there are difference of opinions due to differing perspectives. (Completely overlapping circles signals group think, be alarmed, be very alarmed.) The area where all opinions overlap are the design by committee area. This is the crappy solution where no-one disagrees, but no-one is happy. Have no doubt about it, design by committee is what democracy looks like. It is safe and, it is steady, and slow, and populistic. It’s good for society, but bad for risky innovation. Democracy is modus operandi for many companies, and they’re usually stuck.

Then, there’s the workshop

Interrelated topics requires a lot of back-and-forth coordination, and a workshop is a great arena for resolving these issues, as well as exploring more opinions.

We’ve recently gathered at a workshop, and each project has presented their current planning status, and then proceeded to address open questions and dependencies. This requires a bit of going back and forth between topics, but at the end of the workshop (we spent 2 days), there has been so much information and clarification back and forth, that the project leads are able to go back to the drawing board, and make wise and informed dictatoral decisions for the final stages of the design and planning.

We expect the dictatorship part to work, as it relies on trust, and is time-boxed. You’re not a dictator for life, just per project. If you get corrupted by power, and ultimately lose the trust of your peers, you will not be able to lead future projects with any efficacy.

We expect some controversial areas in the final designs.

The figure below might represent the different forms of decision making:

We’re not done with these designs quite, yet. So let’s wait and see how this goes before we congratulate ourselves too much.

(And if you’re left thinking that the process described above is what good leadership is all about: listening, careful intellectual consideration, but also being able to make the best informed decision regardless of some unresolved controversies, then you’re right. Easier said then done, though.)

A definition of art is definitively in order. Defining it to simply mean “to make something look great” have caused many a disaster while combined with the profession of an architect. Some architects — or even quite many, it may seem — evidently do define their work this way. A few take it one step further to the definition “Make a great looking building AND make sure it does not collapse”, but it still just won’t cut it. It’s not good enough.

In 1997 BBC aired a series about buildings called “How Buildings Learn” (links at the end). A study mentioned in these series states that only 1 in 10 buildings are revisited by the architect upon completion. They don’t go back. “It’s just too discouraging” as one architect was quoted saying. If architects show no apparent interest in how people experience their buildings, how do we expect them to improve in making usable housing? I have already asserted that without feedback, there is no improvement. Not going back is a bad mistake, at best. Poor sons of bitches.

A Set of Qualities in the Art of Software Engineering

When we define ourselves as artists, within the business of software engineering, we also stand the chance of making similar mistakes. We will have to define the universe within which we wish to be artists. The universe must not be too big, and not too small.

I would like to define our universe as a set of software qualities.

1. Usability – The art of making something that is a blast to use.
2. Reliability – The art of making something that works as it should, consistently.
3. Efficiency – The art of creating software that is lean; it economizes running time and space consumption.
4. Modifiability – The art of making something that can evolve with time, that is maintainable.
5. Testability – The art of creating software that is easy to test.
6. Portability – The art of creating software that is easily moved about, when needed.
7. Understandability – The art of creating software that another engineer actually can comprehend.

If all of these qualities are met with elegance, we consider ourselves to have created a true piece of art. And notice how the user is considered right there at the top. Our main goals must always be to leverage the user, and to solve his most important problems first (i.e. what do you need an unusable but reliable and efficient application for?)

Also, I reckon that considering the color and shape (design) is an outright insult, if not all of the above qualities are given careful consideration first.

But I am digressing, we were talking about architects, weren’t we?

Qualities in the Art of Making Buildings

Architects do not seem to present their customer with a clear list of requirements that they have to consider, and this is a root cause for a lot of wrath. I thought I’d help them out in starting a little brain-storming on the subject.

So what does an architect need to consider while architecting and designing a building?

Usability

Usability in buildings is best described by elevators having enough capacity, that it’s bright and pleasant, that stairs are easily accessible and that people generally feel comfortable moving around and being stationary for hours on end in this building.

Minglability

Yes, I’m making these words up. Get over it. The building from which you run your business should be designed so that even though your business occupy a lot of floors, or even all floors, people should run into each other in chance encounters where the micro-meetings takes place and information is distributed informally and organically.

Maintainability

The building is easy to clean. Repairing the electrical wiring, adding more wiring, fixing pipes, replacing broken walls etc. is, if not straight forward, at least possible.

Modifiability

No building must be expected to be built just right at once. The human activity taking place inside the building is far too complex to fully predict ahead of building it. (Notice the analogy to software engineering and the failure of deterministic, up-front planning). Thus the building should be able to adapt to changing requirements. I guess this means that walls can be moved, piping can be re-routed without demolishing core structure of the building, storage areas can be turned into offices and the other way around. A lot of the construction will (and should) take place after the building is “done”, and thus this should be facilitated by the architecture and design.

This is the very minimum of quality attributes that should make up the universe within which the architects should be calling themselves artists. (I know, I know, engineers should also be involved in constructing a building, but we need someone to hassle about this, and the architects are just such an easy target for this discussion. But, please, include engineers as well.). The main point is that forgetting the important requirements, oversimplifying the complex task of creating usable buildings that evolve, leaves you with too many constraints, and a building that is potentially inhabitable for anyone trying to run a serious business, or live a happy life, in general.

When all else fails

If few or none of the requirements above are met, there’s a way out. It’s not lean, but sometimes it has to be done.

Let’s hope the next time, the architects behind these buildings do a better job.

References

1. BBC Episodes on “How buildings learn” are found on the (stinking) Google Video service: Episodes 1, 2, 3, 4, 5, 6.
2. List of qualities inspired by Facts and Fallacies of Software Engineering, by Robert L. Glass)
3. Kevin Kelly’s original story on the episodes in True Film.