Category Archives: LifeUniverse&Everything

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

Max de Vries Interview – What every project manager should know

I was recently fortunate enough to catch Max de Vries on a trip to the UK. Max has overseen complex IT projects in Europe, Asia and the US, in finance, public sector and now games for over 20 years, most recently being in charge of Popcap’s Plants vs Zombies franchise, overseeing the launch of PvZ 2 and PvZ-Garden Warfare. I managed to fire off two quick questions before he had to go:

Q: What are the top 3 things every project manager should know?
Who to trust; how to communicate; and what would success look like.
Q: What are the common mistake that inexperienced project managers make?
  • Not realizing they are inexperienced
  • Making estimation a political process
  • Miscalculating the cost of saying no vs the cost of failure
  • Not thinking about the critical path hard enough
  • Thinking that people know what they want
  • Underestimating the value of a high functioning team
  • With agile processes: Modifying a process without understanding the reasons why the process works and doesn’t work

So now you know.

Improving the accuracy of software project estimates: multiply everything by 3

I found about 10 years ago that everything I delivered in software took me three times longer than I expected.

Eventually I realised that my ‘gut feel’ for estimating a coding task was ‘about how long will it take me to code this if I make no errors & get it right first go’. Which is a good starting point for an estimate, so long as you then go on to add testing, debugging, changing or misunderstanding requirements and time to release. So if you have stable requirements and a pushbutton deployment toolchain, then x3 is about right. If you haven’t, x5 is probably closer.

I note that others have found something similar. I’m please to find that multiplying by 3 puts me about 4.7% ahead of the curve – http://alistair.cockburn.us/The+magic+of+pi+for+project+managers.