The Known Unknowns Matrix

I.T. is not the only industry to have happily latched onto the the former Secretary of State's famous phrase, "the unknown unknowns". It's a good phrase if you must plan or estimate anything because planning & estimating always involve risk.

But we should really consider the full matrix. There are pitfalls in at least two of the quadrants:

	Known	Not Known
Knowns	Things we know, and we know we know them	Things we know but don't realise we know them. Tacit knowledge that we take for granted. Becomes a problem if we are responsible, and fail, to communicate them to people who don't know. Also a problem when we start work in a new context and do not realise that what we ‘know’ is no longer valid here, so they become unknown unknowns.
Unknowns	Things we know that we don't know. We can record the risk, and estimate a cost for investigation & discovery	Things we don't know that we don't know. This is the quadrant most likely to shipwreck plans.

Concerning the unknown unknowns, my experience with doing novel software is that when budgeting for development you should estimate for development, plus learning time, plus developing the things you learned about, plus solving problems you didn't know you'd have. A rule of thumb for novel systems might be, multiply your estimate by ten to cope with the unknowns. And/Or, have clear “abandon the project” criteria, even months into the project. Don't be a dupe for the sunk-cost fallacy.

Less dramatically, my takeaway from this is to use this quadrant when listing risks and assumptions. Just having a space for the possibility of unknown knowns & unknowns can be an impetus to discuss, “risk-storm” & consult, to help your team discover the as-yet-unknowns.

P.S.

I've just read the brief and brilliant mcfunley.com/choose-boring-technology which points out that you can't afford too much novelty. He suggests that for any new project you should grant yourself a limit of 3 novelty chips. When you've spent them, you get no more.

Well, not unless you really can overshoot your budget and timescales by over 1,000%.

Kudos

A slideshare by Danni Mannes on Agile Architecture pointed out to me all quadrants are worth some of our time.

Estimates and NoEstimates

We had a debate&discussion at XP-Man on NoEstimates for which I did some notes. Reading the NoEstimates stuff, I was most attracted to the sense of "Let's not be satisfied with second rate" and of a thirst for continuous improvement.
I was left with the sense (possibly because I already believed it) that there are contexts in which NoEstimates works, and contexts in which it doesn't. But I was very glad to be provoked to ask in each case, "What value if any is our estimate/planning effort adding?" and "Isn't there a better way to deliver that value?"

What is an Estimate?

An estimate for a Project is (1) a list of things to work on; (2) a cost-range for those things; and (3) a list of risks, that is (3a) of Dependencies that 1&2 rely on, and (3b) of things that might cause significant change.

An estimate or plan for a sprint is (1) a list of things to work on, (2) a "cost" (eg story points) for those things and (3) a list of things we are uncertain about, or (4) need to get help with.

The value of a project estimate is to feed-in to (1) A go/no-go decision and (2) seeing things we want to see sooner rather than later (e.g. should we hire more people, do we need help from specific 3rd parties, is releasing in time for Christmas possible)

The value of a sprint estimate is, to see things we need to ask for in advance (ie external help or resources); to give everyone a sense of confidence about what we're doing; to fail-faster, that is to see sooner what we can't achieve.

Money doesn’t make the world go round

"Who are we kidding? Apps are built to earn money. They are a product created to generate profit, and there are a number of ways we can get them to do just that. The simplest, and therefore most common method is ..."

So says a typical email in my inbox. But. It ain't true. Apps are also built because people love to build things. Many, many apps – and websites; and Real Stuff; — are built because people love to built things, and if they didn't have to earn a living they'd still be building things. For some people, earning money is the pesky thing getting in the way of building the apps they'd love to build.

Should a Software Architect Code? is the Wrong Question

It's a long-running argument in software architecture and I've seen some quite emotional comments on it. But it's the wrong argument. The right question is surely one about ratios:

"What ratio of non-coding architects to coders will work best for us?"

A ballpark answer to this question would follow logically from calculating how many full-time-developers worth of work results in an amount of non-coding-but-still-requires-deep-or-broad-technical-understanding-and-vision work that adds up to one full time job.

I suggest, based mostly on e-commerce & similar SMEs, something like:
(1) 25 developers' worth of coding results in 1 full-time non-coding-architect's worth of work.
(2) Every team needs at least one coding-architect-or-architecturally-competent-developer per 5 developers

Which gets me to a ratio of

1:5:25

for

non-coding-architect : coding-architect-or-lead-dev : developer

Architecture features plenty of non-coding work. Dealing with people, plans, business change, technical design, design decisions, frameworks, principles, patterns, catalogues, quality attributes... There's more than enough of it if you have 25 coders' worth of development going on.

So in a workplace with 100 developers, you may want a chief architect, 3 or 4 non-coding architects and 20 coding-architects-or-architecturally-competent-developers. But if you are chief architect or even CTO of a company with 15 developers, you probably still code.

There's no right answer to the question, how much coding does a coding-architects-or-architecturally-competent-developers do. It can vary from nearly-nothing to 95% as projects progress. Perhaps 50% is a good average?

Discussions

There having been not one but two still-live threads on this on LinkedIn software groups since 2012:
LinkedIn - 97 Things Every Software Architect Should Know - Should architects continue coding ... ?
LinkedIn - IASA - Should software architects code?
Anthony Langsworth's 2012 post