CraftConf 15–Takeaways from “Beyond Features”

This was one of my favourite talks at the con­fer­ence and hav­ing seen quite a few of his talks Dan North is always a safe bet!


Rantifesto about Agile Methodology

The talk start­ed with a Rantifesto about the state of Agile.

When the Agile man­i­festo was con­ceived in 2001, it made a set of val­ue state­ments of things that we care about:


How­ev­er, as of 2015, we as an indus­try have come to demon­strate with our behav­iours a dif­fer­ent set of val­ue state­ments:

  • Process­es and tools over  indi­vid­u­als and inter­ac­tions
  • Com­pre­hen­sive doc­u­men­ta­tion over  work­ing soft­ware
  • Con­tract nego­ti­a­tion over cus­tomer col­lab­o­ra­tion
  • Fol­low­ing a plan over adapt­ing to change


Cul­ture eats strat­e­gy for break­fast”

- Peter Druck­er

i.e. you can have the best inten­tions (man­i­festo) but unless you change your sys­tem of work (method­ol­o­gy) it will not make the tini­est bit of impact.


Whilst sup­port­ers of the agile method­olo­gies would say that they opti­mize for qual­i­ty, feed­back, com­mu­ni­ca­tion, col­lab­o­ra­tion, etc. But above all, agile meth­ods are opti­mized for pre­dictabil­i­ty, which was some­thing that was seri­ous­ly lack­ing when the agile method­olo­gies came out in the 90s.

Michael Nygard also touched on this in his Archi­tec­ture with­out an End State talk that, in big enter­pris­es there were these cycles of 3 year plans :

  • orga­ni­za­tion brings in a new CIO who instils a 3-year plan to rev­o­lu­tion­ize the company’s IT orga­ni­za­tion
  • the busi­ness and mar­ket has changed in the mean­time but the plan forged ahead
  • and a new CIO comes in and qui­et­ly kills off the pre­vi­ous regime’s plan and instils his own vision of a 3-year plan


We base Software Engineering on Civil Engineering

After bash­ing on agile method­olo­gies a few more rounds (and it was fun to watch Winking smile) Dan hypoth­e­sized that, per­haps our obses­sion with pre­dictabil­i­ty stems from the fact that for so long we have based soft­ware engi­neer­ing on civ­il engi­neer­ing.

As a young indus­try, where the major­i­ty of us are 1st gen­er­a­tion soft­ware engi­neers, we have been mak­ing things up as we go and we look to civ­il engi­neer­ing for metaphor. I think this high­lights two issues that we should address as an indus­try.

Mentorship programmes

As a whole, an alarm­ing­ly small per­cent­age of devel­op­ers stay in the indus­try for more than 10 years, in part thanks to a lack of career pro­gres­sion at most com­pa­nies. Those few bril­liant minds, who have been in the indus­try for decades and with valu­able expe­ri­ences to share, are often locked up inside com­pa­nies such as Google and Microsoft and are rarely avail­able to the gen­er­al pub­lic.

The inter­net is a great place to find answers to just about any­thing you can think of, but it’s also full of noise and bad advice, not to men­tion a lot of prej­u­dice and judge­ment. I have found con­fer­ences to be a great place to meet and speak to peo­ple who are gen­uine­ly smart, open-mind­ed, and whose opin­ions came from a wealth of expe­ri­ence. But, attend­ing con­fer­ences requires sig­nif­i­cant invest­ment of time and finance, and the peo­ple you need to speak to about par­tic­u­lar prob­lems aren’t always avail­able.

Some form of men­tor­ship pro­grammes would help pass on the knowl­edge and expe­ri­ence to younger gen­er­a­tions and maybe, just maybe, help ease this end­less cycle of rein­vent­ing the wheel.

Easier access to previous bodies of work

Although there is a vast wealth of pre­vi­ous work for us to learn from, they’re often not eas­i­ly dis­cov­er­able or acces­si­ble (e.g. hid­den behind ACM mem­ber­ships) and hard to digest (why are tech­ni­cal papers still pub­lished in paper for­mat when new medi­ums are avail­able is baf­fling).

The sheer num­ber of aca­d­e­m­ic papers that are pub­lished every year can also be over­whelm­ing to those of us not steeped in the aca­d­e­m­ic world. To get start­ed, look for a Papers We Love  meet­up group in your city and go to their meet ups.


In civ­il engi­neer­ing, we have a much old­er, vig­or­ous and dis­ci­plined indus­try where things tend to get done. In civ­il engi­neer­ing, you front-load your risk and every­one has a clear line of respon­si­bil­i­ty in a project:



Whilst metaphors can be use­ful to help us make sense of unfa­mil­iar things, but we can then over-extend them.

And since we think soft­ware engi­neer­ing is like civ­il engi­neer­ing, so oth­er char­ac­ter­is­tics of civ­il engi­neer­ing that has noth­ing to do with soft­ware sud­den­ly becomes more per­va­sive too.

Ulti­mate­ly there are many places – e.g. the need for a quan­ti­ty sur­vey­or to pro­vide esti­mates for mate­ri­als and costs – where the metaphor starts to break down.

Dan hypoth­e­sized that the rea­son why we’re so hung up on fea­tures in soft­ware is because in our metaphor, civ­il engi­neer­ing, the big­ger is bet­ter.


Whilst attack­ing this fix­a­tion on fea­tures from a dif­fer­ent angle, Melis­sa Per­ri described the ten­den­cy many orga­ni­za­tions have of keep on build­ing fea­tures as The Build Trap.



Intu­itive­ly we all know that in soft­ware engi­neer­ing, the big­ger is not bet­ter, in fact, the oppo­site is true.

So what if civ­il engi­neer­ing isn’t an appro­pri­ate metaphor for soft­ware engi­neer­ing?


Software Surgery

Ear­li­er in the open­ing keynote Com­plex­i­ty is Out­side the Code Dan and Jes­si­ca Kerr said that the goal of soft­ware engi­neer­ing should be to sus­tain­ably min­i­mize lead time to busi­ness impact.

Lead time to some­one say­ing thank you is the only rep­u­ta­tion met­ric that mat­ters.

- Dan North

Lead time is most­ly made up of hand­offs, so even if your devel­op­ers and testers are very effi­cient in their siloed tasks, the hand­offs are still going to hurt you. A typ­i­cal work item spends 90% of its life not hav­ing stuff done to it – most­ly because it’s wait­ing in the queue.

Then Dan the­o­rized that, maybe, soft­ware is more like surgery instead of civ­il engi­neer­ing. Maybe, the way we approach and con­sume soft­ware, is very sim­i­lar to the way we approach and con­sume surgery.

No one wants surgery!

Just as no one wants to go under the knife for fun, nei­ther do busi­ness­es want soft­ware for the sake of hav­ing them – they want solu­tions to prob­lems and it just so hap­pens that in this day and age that solu­tion is often made up of soft­ware.

But if I must have a surgery, I want to have the min­i­mum amount of surgery pos­si­ble (i.e. small is beau­ti­ful).

I want the most com­pe­tent and expe­ri­enced pro­fes­sions to oper­ate on me. And I want them to use estab­lished, proven tech­niques, and yet, still pre­pared for the unex­pect­ed and ready to use more exper­i­men­tal approach­es when required.

But most­ly, I rather not have the surgery, I just want to be well!

Features + Discovery + Kaizen

Just as surgery is more than just cut­ting peo­ple up, there’s more to soft­ware than fea­tures.

In the con­text of surgery, there is also dis­cov­ery,  which is about the indi­vid­ual patients and explor­ing what prob­lems they have by using blood tests and oth­er explorato­ry steps.

For this to work there is a trust rela­tion­ship between the patient and the sur­geon. Where­by the patient allows him­self to be vul­ner­a­ble and have faith in the surgeon’s knowl­edge of the domain and pro­fes­sion­al­ism to make him bet­ter.

And then there’s Kaizen. In med­ical sci­ence, the use of anaes­thet­ics, wash­ing your hands before surgery, etc. are all about improv­ing the process of surgery and help reduce the mor­tal­i­ty rate of patients.

We need to re-engage

Dan used the civ­il engi­neer­ing metaphor once more to describe how, by not engag­ing with the busi­ness to find out what prob­lems they’re try­ing to solve, we have allowed our­selves to be the order tak­ers who sim­ply react to the list of fea­tures we’re hand­ed.

Instead, we should aim for a more con­sul­ta­tive rela­tion­ship like the one between patients and sur­geons.

We also need to re-engage with the IT man­age­ment whom has been steeped in the civ­il engi­neer­ing metaphor for so long. We need to think about what it means to lead and gov­ern an IT orga­ni­za­tion in which less is more. We need to help them help us.

And we need to re-engage with our­selves. The craft of surgery is not about cut­ting peo­ple up, it’s about sav­ing lives. The craft of soft­ware devel­op­ment is not about pro­gram­ming, it’s about cre­at­ing busi­ness impact through soft­ware.


Fea­tures, Dis­cov­ery and Kaizen are all first class work, you need to sched­ule, mea­sure, track and show­case each and have some of each in flight at all times.