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.

Design Pattern Haikus

Singletons

a singleton is

a global variable

sounds a bit better 

A singleton is just a fancy name for a global variable. I like to think of a singleton as a way of warping to another point in space/time, changing the space time continuum and then heading back. You've seen the sci-fi films where this happens, right? It has similar effects on your code, making it difficult to understand what the hell is happening.

Interpreter

interpreter is

domain specific language

that is all it is

Well, there's not much more to say is there? You want your code to be readable in the language of your domain. One way to do this is to make the code look more like the language of your domain. A domain-specific language is one way to accomplish this.

Visitor

multiple dispatch

that is what you really wanted

visitor will do

You've got a function that wants to do different things depending on the types of the arguments. You've got a language that only allows you to do one different thing via polymorphism. You don't want type-switching cos someone told you that was bad.

Assuming you've got those prerequisites then go for the visitor pattern. Alternatively, look at multiple dispatch and see there's no problem there at all really.

Strategy 

functions compose well

classes do not compose at all

love strategy pattern

You want to break apart a set of work into small discrete components (let's call them "objects"). The strategy pattern allows you to plug these together to solve a problem.

Or... You want to break apart an algorithm into discrete functions (let's call them functions). Functions glue together.

Professionalism in Software Engineering

Yesterday, I attended a talk by Bob Martin on Professionalism in Code hosted by Software East at Redgate. I also spent considerable time beforehand working out whether it'd be unfair to introduce Bob as the "Donald Trump of Computer Programming". Sanity prevailed and I didn't. But I just wrote it up there, didn't I? D'oh.

Is the software engineering industry professional? As software engineering professionals we should have skill and good judgement. Does the software engineering industry have that?

Bob gave the famous example [PDF] of Knight Capital and Volkswagen, but there's many more (Therac-25, the F35 and The Chaos Report [PDF]). You could argue that the software industry is in meltdown and developer incompetence / poor judgement has cost the industry billions. I think you'd have a pretty convincing case! Or would you? There was no mention the other side - the tremendous advantages our haphazard industry has made to almost the whole planet (the Internet, mobile phones, communication).

Bob painted the nightmare scenario - regulation. Imagine some time from now, some bug somewhere (a missing ; even) results in a number of deaths. The nuclear reactor blows, the self-driving cars go made on a leap year and start running people over, the planes turn upside down when crossing the equator (etc). The natural result of this is the Government blames us (software developers) and starts to put some regulations in place. Again, this feels believable-ish.

But why hasn't it happened yet? Well, safety-critical systems are pretty regulated. See this lump [PDF trigger warning] from the FAA about how they do things. I'm not going to argue it's perfect, but it's demonstrably good enough to stop null pointers making things fall out the sky regularly.

So what should we do to prevent this threat of regulation? Well, we should:

• Not ship shit!
• Give reasonable estimates!
• QA should find no bugs
• Software should get better, not worse
• Invest 20 hours per week in personal development

Most of this stuff is easy to agree. Of course we shouldn't ship shit - are you insane? Of course we should strive to write bug free code. If you want to explore these ideas more, Bob's book (The Clean Coder) covers the topics in much greater detail. It was a great talk and got the audience thinking.

Are these the right things to make the industry professional? Maybe. Maybe as an industry we should look at other areas:

• Should we write code in unsafe languages like C for safety critical systems?
• Should we put JavaScript on a plane?
• Is that shared mutable state acceptable in my car?
• Languages with null are a billion dollar mistake - outlaw them!
• Should we use test-driven development as justification for using weak languages?

There's a huge space for software engineers to explore about building professional quality software. We're not explored much yet. I'm certainly no historian, but I'd imagine professions like Medicine, Law and Engineering took more than 60 or so years to establish what good looked like.

The deliciously chaotic world of software engineering is going to continue for a while yet!