Wednesday 11 January 2017

The Dark Path

Over the last few months I’ve dabbled in building in doing my accounts using a spreadsheet (Google Sheets and Excel). The similarities are so stark that I wonder if this isn’t a new trend in managing accounts. If so, it is a dark path.
Both tools have integrated some functional characteristics. For example, they both update automatically to reflect changes in values. This is a good thing, in general. 
My problem is that both tools have doubled down on automation. Both seem to be intent on forcing me to write references to every needed cell in the spreadsheet!
Now I don’t want you to think that I’m opposed to automation. I’m not. I use pen and paper, I use tools. I have a slight preference for pen and paper, but I'm using a spreadsheet too.
It’s not the fact that spreadsheets automate that has me concerned. Rather, it is the depth.
Previously, I'd created tables in Word. I can structure it so that it's correct; but I can also violate many of the "rules" whenever I need or want to. Word underlines some bits in green/red and throws up a few roadblocks; but not so many as to be obstructionist.
Google Sheets and Excel, on the other hand, are completely inflexible when it comes to their rules.  For example, in Google Sheets if I sum up a column then by God every thing in that column and all the dependent references have to be adorned by being a "number". There is no way, in this tool, to silently ignore me mistaking a string for a number!
Now, perhaps you think this is a good thing. Perhaps you think that there have been a lot of bugs in systems that have resulted from un-coerced numbers. Perhaps you think that that if you aren’t escorted, step by step, through the dependent cells it would be risky and error prone. And, of course, you would be right about that. 
The question is: Whose job is it to manage the "numbers". The tool? Or the pen and paper?
These so called "spreadsheets" are like the little Dutch boy sticking his fingers in the dike. Every time there’s a new kind of bug, we add a feature to prevent that kind of bug. And so these tools accumulate more and more fingers in holes in dikes. The problem is, eventually you run out of fingers and toes!
This is the wrong path!
Ask yourself why we are trying to plug defects with tools. The answer ought to be obvious. We are trying to plug these defects because these defects happen too often.
Now, ask yourself why these defects happen too often. If your answer is that our tools don’t prevent them, then I strongly suggest that you quit your job and never think about use a spreadsheet again; because errors are never the fault of our tools. Defects are the fault of users. It is users who create defects – not spreadsheets.
And what is it that programmers are supposed to do to prevent defects? I’ll give you one guess. Here are some hints. It’s a verb. It starts with a “T”. Yeah. You got it.TEST!
You test every number is indeed a number. You test that your formulas refer to actual elements; not empty cells. You test that you've recalculated everything!
Why are these spreadsheets adopting all these features?
We now have spreadsheets that force us to adorn every function, all the way up the dependent cells, with number. We now have spreadsheets that are so constraining, and so over-specified, that you have to specify all the elements that they refer to!
All these constraints, that these spreadsheets are imposing, presume that the user has perfect knowledge of the system; before the system is written. They presume that you know which number is a number. They presume you know to not to mix different units. They presume you know which input should link to which output. They presume you know what units a result will come back in.
And because of all this presumption, they punish you when you are wrong. 
And how do you avoid being punished? There are two ways. One that works; and one that doesn’t. The one that doesn’t work is to design everything up front before starting. The one that does avoid the punishment is to override all the safeties.
And so, you write everything on paper and you leave these so called "spreadsheets" alone.
Why did the nuclear plant at Chernobyl catch fire, melt down, destroy a small city, and leave a large area uninhabitable? They overrode all the safeties. So don’t depend on safeties to prevent catastrophes. Instead, you’d better get used to writing lots and lots of tests, no matter what spreadsheet you are using!
Of course, this is just early morning unfunny parody of an article by Bob Martin, The Dark Path.
I strong disagree with the sentiment expressed in the article. Types are a tool that help you write code safely. Tests are a tool that help you write code safely. Neither replaces the other. 
To suggest that we should abandon static-typing is wrong. If I change something returning type A to returning type B I can see how that might mean I have to change a lot of my code base. That doesn't mean static typing is bad, it could mean anything! 
  • Maybe the design sucks, why does so much of the code know about type A?
  • Maybe it's a good thing - you didn't know everything upfront, an assumption has changed, so you should change the code?
  • Maybe you want to experiment? We should find a way to defer type errors to runtime? 
  • Maybe we should invest in tooling to make this problem more tractable? (Jackpot!?)

We, as software engineers, should be actively looking to advance the state of the art. We should be building tools to support our ways of working, not rallying against those that do.

Radical Focus - OKRs

Radical Focus explains the OKR process with a business narrative (a startup building the StarBucks of Coffee). The story shows how focusing on OKRs supports the team taking the tough decisions (e.g. stopping promising work if it doesn't support an objective) and spending their limited runway of activity on the right tasks.

It's a short read, with some good points but having read the book and watched "The Executioners Tale" ( I'd pick the video next time!

Key takeaways

  • OKRs are great for setting goals, BUT without a system to achieve them you are as likely to fail as with anything else.
  • A mission keeps you on the rails - the OKRs provide focus and milestones.
  • Set only one OKR for the company - it's about focus
  • Timescales should be about 3 months - too long and it's too far away to have impact, and too short and it's not bold enough
  • Objectives are inspirational not metrics
  • Repeat the message. The goal needs to be in front of everyones mind and tied to all activities. - "When you are tired of saying it, people are starting to hear it" (Jeff Weiner, CEO of LinkedIn")
  • Heuristic for KRs - one usage metric, a revenue metric and a satisfaction metric.
  • A good key result should be a bit scary - a 50/50 confidence you can make it is about right.
  • Use health metrics to identify areas to protect as you meet the goals (what can't you screw up?)
  • Use the four-square template ( to keep focus
  • Reinforce the message at the beginning and end of the week (Monday discuss/challenge, Friday demonstrate/celebrate)

Tuesday 3 January 2017

The 3X Approach

I watched a webinar recently about Kent Beck's characterization of product development as a triathlon and thought I'd summarize the notes here!

Kent presents product development as a three-phased approach (eXplore, eXpand, eXtract). This really closely models the product life cycle (from HBR).

Kent's insight is that you should act differently depending on the phase you are in.

In the Explore phase (stage #1 above) you can't predict the future. You've no idea how long finding market fit is going to take. It's a high risk activity. The main driver of success is the rate at which you can run experiments and learn quickly. At this stage software quality is irrelevant - the half-life of the code is short. You want a cross-functional, loosely co-ordinated team to deliver this phase.

The next stage is Expand - this is rapid growth, equivalent to the B round of venture capital. You have validated the market, you know what to do and how to do it. Time to scale, develop features and get it in the hands of users and build those feedback cycles.

Finally, you are at Extract. This is where economies of scale shine. Work here is predictable - adding a feature will result in a known about of revenue. You can estimate things well because you've done it plenty of times before. Quality is really important - cutting corners now will cost you because you'll be stuck with it for ever.

Organizations can get tuned to a particular way of thinking and that can constrain. For example, it's easiest to get tuned into the last phase Extract (see Innovator's Dilemma)

Beck states that this is one of the things XP got wrong-  there is no one-size fits all methodology. The 3X model says it's all about where you are on the s-curve.