QCon London 2015–Takeaways from “Small is Beautiful”

From the first day of QCon Lon­don, I real­ly enjoyed Kevlin Henney’s Small is Beau­ti­ful talk. Titled after E.F. Schumacher’s book (below) of the same name, the title itself should give you a pret­ty good idea of what to expect from this talk.

image

 

I’m a big fan of Kevlin, and his “Sev­en Inef­fec­tive Cod­ing Habits of Many Pro­gram­mers” talk at Build­Stuff was the inspi­ra­tion behind my par­o­dy post for the F# advent cal­en­dar last year. And as ever, Kevlin has plen­ty of well-applied, mem­o­rable quotes, start­ing with this one:

Sus­tain­able devel­op­ment is devel­op­ment that meets the needs of the present with­out com­pro­mis­ing the abil­i­ty of future gen­er­a­tions to meet their own needs.

- the report of the Brundt­land Com­mis­sion

when applied to soft­ware devel­op­ment, my inter­pre­ta­tion of it is : “don’t take on more tech­ni­cal debt than you can rea­son­ably pay back in the future in favour of short-term gains”. Which is nice­ly backed up by this tweet:

image

 

On the oth­er extreme of the spec­trum, you have peo­ple who are so con­cerned about future needs they end up com­plete­ly over-engi­neer­ing their solu­tion to cope with this uncer­tain­ty and end up with projects that are delayed or worse, nev­er deliv­ered.

image

 

You should think of soft­ware as prod­ucts, not projects.

If soft­ware are projects then they should have well-defined end state, but most often, soft­ware do not have well-defined end state, but rather evolved con­tin­u­ous­ly for as long as it remains desir­able and pur­pose­ful.

 

Despite its naivety when it comes to mea­sur­ing com­plex­i­ty, lines-of-code is still a good met­ric to con­sid­er as it fits nice­ly with our main con­straint as devel­op­ers – our work­ing mem­o­ry.

image

There’s a learnt com­pla­cen­cy amongst many devel­op­ers that has allowed them to rest on their lau­rels and accept large code­bas­es as a real­i­ty that can­not be chal­lenged.

Kevlin showed a per­fect counter-exam­ple of a com­put­er chess pro­gram that is less than 512-bytes! Even the Unix 6 OS was less than 10k lines of code long, which is a frac­tion of the size of many mod­ern day soft­ware.

image

(from Alan Kay’s 2011 talk, Pro­gram­ming and Scal­ing)

 

Cre­ativ­i­ty needs a bound­ary. With­out any bound­aries, a painter might be lost if you just ask him to “draw a pic­ture”, and would you cre­ate any­thing more than a “hel­lo, world!” appli­ca­tion if asked to just “write a pro­gram”?

As Den­nis Ritchie and Ken Thomp­son point­ed out, size con­straints played a key role in encour­ag­ing their cre­ativ­i­ty and come up with designs that are both ele­gant and small:

There has always been fair­ly severe size con­straints on the Unix oper­at­ing sys­tem and its soft­ware. Giv­en the par­tial­ly antag­o­nis­tic desires for rea­son­able effi­cien­cy and expres­sive pow­er, the size con­straint has encour­aged not only econ­o­my but a cer­tain ele­gance of design.

- Den­nis Ritchie and Ken Thomp­son

The UNIX Time-Shar­ing Sys­tem”, CACM

One rea­son for sys­tems to become large is because we expect them to be that way with­out chal­leng­ing that belief, putting bound­aries push­es us to chal­lenge those com­pla­cen­cies.

Kevlin also point­ed out anoth­er good point – the more time you spend work­ing on a project, the more the endow­ment effect kicks in and we become less inclined to change.

 

Conway’s law

orga­ni­za­tions which design sys­tems… are con­strained to pro­duce designs which are copies of the com­mu­ni­ca­tion struc­tures of these orga­ni­za­tions.

- M. Con­way

tells us that, anoth­er rea­son for sys­tems to become large is because of the way they are staffed. Iron­i­cal­ly, staffing deci­sions are usu­al­ly tak­en at the point of your great­est igno­rance – at the start of a project.

In oth­er words, if you hire 100 peo­ple to work on a sys­tem, then you put in motion the events that will result in a com­mu­ni­ca­tion struc­ture con­sist­ing of 100 peo­ple, and the size of the sys­tem you get at the end becomes a self-ful­fill­ing prophe­cy.

 

Soft­ware devel­op­ment does not have economies of scale.

Devel­op­ment has dis­ec­onomies of scale.

- Allan Kel­ly

image

 

You should be aware of code that serves no pur­pose.

Car­go cult pro­gram­ming is a style of com­put­er pro­gram­ming char­ac­ter­ized by the rit­u­al inclu­sion of code or pro­gram struc­tures that serve no real pur­pose.

Car­go cult pro­gram­ming can also refer to the results of apply­ing a design pat­tern or cod­ing style blind­ly with­out under­stand­ing the rea­sons behind that design prin­ci­ple.

- Wikipedia

What fol­lowed was a hilar­i­ous exam­ple of “enter­prise” code at its finest – FizzBuzzEn­ter­priseEd­i­tion, seri­ous­ly, check it out, I guar­an­tee it’ll be the best thing you’ll see today!

 

Kevlin then retold the well-known tale of how Knight Cap­i­tal Group lost $460 mil­lion in 45 min­utes from a dif­fer­ent per­spec­tive to high­light the poten­tial dan­ger of leav­ing old code that no longer serve any pur­pose around.

A clas­sic case of “what’s the worst that could hap­pen?”

image

And if you need any more con­vinc­ing about remov­ing redundant/unused code.

Our task is not to find the max­i­mum amount of con­tent in a work of art.

Our task is to cut back con­tent so that we can see the thing at all.

- Susan Son­tag

A design­er knows he has achieved per­fec­tion not when there is noth­ing left to add, but when there is noth­ing left to take away.

- Antoine De Saint-Exu­pery

image

 

And final­ly, Kevlin’s offered one last bit of insight – sys­tem fail­ures don’t usu­al­ly hap­pen because of one thing, they usu­al­ly occur as the result of mul­ti­ple fail­ures.

This is, inter­est­ing­ly, echoed by none oth­er than Man Utd’s leg­endary man­ag­er Sir Alex Fer­gu­son who once said that goals are usu­al­ly con­ced­ed as the result of mul­ti­ple fail­ures through­out the build-up play even if it ends with an individual’s error.

Links

Slides for Small is Beau­ti­ful