Monthly Archives: November 2013

If they can do it, why can’t we?

Sooner or later, but inevitably, this questions seems to come up  when developing digital services:  someone requests a feature,  the team responds that they can’t easily implement it, and the requester states: “Well, website xyz has this feature, why can’t we have it?” Things rapidly get worse when an implication of incompetence is perceived.

Whenever this question comes to mind, it might be useful to ask ourselves a few questions:

  • Are xyz working in a similar context?
  • Are xyz pursuing a similar purpose?

Context may include organisational policies, available technology and the ease of changing this context. Purpose may loosen or tighten constraints on available funding or the selection of (potentially controversial) means. (Dean Bubley tweeted about context and purpose in networking, I touched on it here.)

It might be beneficial to remember that we usually don’t have any idea how much it cost xyz to implement that feature, or how long it took them. It is also not clear that xyz’s feature, i.e. a solution to one of their problems, is necessarily a good solution to our problem.

So, if we really want that feature, we need to sit down with the team and take the time to truly understand what makes it difficult, slow or expensive to build. Often we might be able to clarify goals or accept constraints that will make implementing (a version of) the desired feature feasible. Or, together with the team, we might discover other, perhaps even better, options.

Let’s just not assume the team is full of half-wits.

Advertisements

Going with the flow

A few weeks ago I joined an up-and-running software development (and service operations) project together with a few other people. The team had already launched the first version of the product successfully. We had heard that huge effort had been put in to achieve this success and we had a hunch that the team would likely benefit from a renewed emphasis on certain lean & agile practices. We also had a hunch that the team wouldn’t benefit from us showing up and starting to lecture from the latest Scrum book or so.

I consider us extremely lucky to work in an environment in which we are free to choose our working practices (obviously within reason). I also consider us extremely lucky to work in a great team willing to own their work — and to put themselves on the line every day trying to improve our performance while at same time having to deliver against high expectations.

Listening to the team and the people around us, and establishing a shared understanding of our goals (including trade-off priorities; hat-tip to Alistair Cockburn) and the forces acting on us seems to be the essential foundation for our learning. After that, getting out of the way seems to be the best thing us management types can do. Every so often, we can provide some support and advice, or offer some re-assurance and confirmation. But mostly, it seems to be about getting out of the way and keeping the way clear of other obstacles as best as we can (we have way to go on that one).

Our work practices seem to become more lean & agile by the day, and I think our performance is improving. This post makes reality probably sound easier than it is, but I feel things are going so much better than whenever I’ve seen project teams being instructed to “be agile”.

Consequences of yet-another-architecture-definition

I described my evolving thinking of what architecture is here and how someone called an architect could add value to a team here.

What consequences does this mindset bring about?

  1. Architecture is not a tangible artefact, but a social construct. (See note below.)
  2. Architecture cannot be created directly, but is the result of other activities (i.e. planning, designing, building and sustaining a system).
  3. The team creates the architecture through interaction. Someone called an architect doesn’t create the architecture by drawing diagrams for the team.
  4. Someone called an architect could promote the shared understanding of a system through conversations with fellow team members and potentially creating supporting artefacts.
  5. Someone called an architect may well contribute to making significant design decisions (sometimes called architecture in the sense of a system’s significant design decisions).

Note: I didn’t come up with the notion of “architecture as a social construct” myself. But then again, I don’t seem to be able to find a single source, so I probably mashed up some ideas from the sources on architecture I mentioned before and the notion of “software as a social construct”.

Updates

2013-11-24: Added note on “architecture as a social construct”.

Different to a human, but not to a computer

We were discussing different ways of modelling information about two different concepts. One of my colleagues observed:

Concepts X and Y look very different to a human, but they don’t look all that different to a computer.

He suggested (looking further into) representing these two concepts using the same entity in the system.

A number of things struck me as noteworthy: I think it might be beneficial to more frequently distinguish conceptual models and implementation models (or conceptual and implementation concerns) in design discussions. I’m glad this happened here. Relevant concerns in a conceptual model don’t necessarily have the same relevance in an implementation model and vice versa.

We frequently still seem to draw on sub-classing as the mechanism of choice for distinguishing different types / categories / kinds of things in our models. Other mechanisms such as type attributes or type objects may yield much better results in many situations.

My colleague’s description of this thinking (looking different to a human but not that much to a computer) seems so much better than my ramblings about conceptual and implementation models.

Martin Fowler’s Analysis Patterns book contains a wealth of ideas on this and related topics — it’s highly valuable and relevant 15+ years after its first publishing. Get a first look here and here. Look for discussions of the knowledge level vs. the operational level in models.

What does an architect do?

I’m still uncomfortable with job titles such as architect used in software-related contexts. Nonetheless, it is difficult to ignore the fact that this title is used and adopted with apparently increasing enthusiasm.

So what do I think an architect does? Or, perhaps better, how do I think someone having the architect job title could provide value to the people she works with?

Against this mental model of architecture, Bob Marshall’s antimatter principle led me to this:

An architect attends to the architecture.

A little longer:

A system’s architect attends to folks’ needs by fostering the shared understanding of this system’s purpose, context, function, form, structure and characteristics.

How do you do that? Well, it depends…mostly on folks’ needs.

For those who’d rather be something than do something: An architect is an attendant to the architecture.

I like this definition of attendant: “a person employed to provide a service to the public in a particular place”. And I like to understand to attend as to look after (source).

Updates:

2013-11-30: Added form, made function singular.
2013-11-08: Added characteristics to definition.

Separate concerns…but not too much!

Separation of concerns is a fundamental design principle whose application can provide significant benefits (also in fields far beyond software). But these benefits become smaller the more we apply this principle and at some point we may actually cause damage.

An example: Categorising things can help us to achieve a better and/or quicker understanding of the situation at hand. Initially, introducing additional categories improves understanding. As we add more categories, the improvements of our standing become smaller while the difficulties of deciding which category the thing at hand belongs to increase.

With separation of concerns (as with many other things) too much of a good thing can actually be pretty bad.

Yet another architecture definition

A system’s architecture is the shared understanding of this system’s purpose, context, function, form, structure and characteristics.

A system’s architecture results from planning, designing, building and sustaining this system.

In hindsight, mental model probably would have been a better term than definition.

The above was inspired by the thinking behind http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf and http://en.wikipedia.org/wiki/Architecture.

 

Updates:

2014-04-26: Gene Hughson wrote about Architecture vs. Design at Iasa Global and Like it or not, you have an architecture (in fact, you may have several) at Form Follows Function.
2013-11-30: Added form, made function singular.
2013-11-09: Added characteristics to the definition. Stated mental model may be a better term than definition.

Requesting contribution from others

“I don’t know what you think about this point, but I think <lots of opinion here>…” to me isn’t an effective way to request contribution from others. To me, it can be considered a violent act, especially if others are one’s subordinates.

“What do you think about this point?” at least opens up space for a contribution.

“Would you be willing to share your views on this point?” might be even more effective.

Making good decisions oneself doesn’t scale…

…and usually doesn’t lead to the best decisions the team could make. Enabling others to make good decisions instead (and accepting others’ help in making good decisions oneself) is likely to scale better and to lead to better decisions.

If this works on a nuclear submarine, chances are it works pretty much everywhere else.

I saw the leader-follower mindset in action again. It wasn’t pretty. I intend to do better.