Adapt or die: don’t try to re­write your tech his­tory – work around in­stead

There’s more to startup choices than PC ver­sus Mac, but rac­ing ahead can leave ‘tech debt’

Irish Independent - Business Week - - Technology - Richard Rodger

THIS is the third part of a three-part se­ries on the tech­nol­ogy choices that we have made as a startup in our first year of ex­is­tence, and the con­se­quences of those choices. In part one I dis­cussed our key early de­ci­sion: don’t build any tech­nol­ogy and just use ex­ist­ing tools. In part two I dis­cussed our de­ci­sion to build a Min­i­mum Vi­able Prod­uct (MVP) with­out wor­ry­ing about long-term ar­chi­tec­ture.

But now that our MVP is launched and has been up and run­ning since March, and has proven a valu­able sales tool in gen­er­at­ing pri­vate early-adopter tri­als, we need to start think­ing longer term.

One way that we’ve made our lives eas­ier, and given our­selves cover to make more strate­gic tech­nol­ogy choices, is by not open­ing pub­lic reg­is­tra­tions yet.

In­stead, we’ve fo­cused on grow­ing our com­mu­nity and work­ing with them to build a bet­ter prod­uct – the proof of that pud­ding won’t come out of the oven un­til later this year.

Build­ing a busi­ness is all about tak­ing on debt. There’s no other way to do it. You have to in­vest in a mar­ket propo­si­tion be­fore you can reap the re­wards.

A tech­nol­ogy startup takes on ‘debt’ in var­i­ous forms (iron­i­cally, tra­di­tional busi­ness loans are al­most never seen – star­tups are too risky). An­gel in­vestors and later, ven­ture cap­i­tal­ists, in­vest in the com­pany be­cause they hope that it will gen­er­ate out­size re­turns.

Their ‘debt’ is re­paid in the ris­ing value of the shares of the com­pany.

It is also re­paid in the re­spect that the ex­ec­u­tive team must ac­cord to these new share­hold­ers, who must be brought on board (and onto the board) as valu­able mem­bers of the lead­er­ship team. This debt is not easy to set­tle, and in­ter­est will ac­cu­mu­late rapidly if ei­ther side breaks trust.

But another form of debt is known as ‘tech­ni­cal debt’. It is just as real as fi­nan­cial debt, and has a far greater im­pact on the busi­ness. Tech­ni­cal debt is the bal­ance be­tween high-qual­ity engi­neer­ing, and short­term busi­ness needs.

Face­book pro­vides us with a good ex­am­ple. The orig­i­nal ver­sion of the sys­tem was built us­ing a pro­gram­ming lan­guage called PHP (orig­i­nally an ab­bre­vi­a­tion of ‘Per­sonal Home Pages’).

This lan­guage is not seen as ac­cept­able for se­ri­ous en­ter­prise soft­ware de­vel­op­ment. It has many de­sign flaws com­pared to some­thing like Java, or C# (C ‘sharp’), both of which were de­signed very care­fully by tal­ented soft­ware en­gi­neers at Sun Mi­crosys­tems and Mi­crosoft, re­spec­tively. But it was good enough for Mark Zucker­berg to build the first ver­sion of Face­book.

Later, Face­book was stuck with

mil­lions of line of code writ­ten in PHP, and no way to re­verse out the ac­cu­mu­lated ‘tech­ni­cal debt’ that they rep­re­sented. They faced per­for­mance and scal­ing chal­lenges be­cause PHP was weak where they needed it to be strong. A so­lu­tion was ur­gently needed.

At this point, there is of­ten a call in the engi­neer­ing team for a ‘re­write’. Throw all the old stuff out, and re­build from the ground up. It will all be so much bet­ter the sec­ond time around now that we know what we re­ally need – the promised land awaits! If you’ve ever been in­volved in rolling out a new soft­ware sys­tem to re­place an old one, you’ll know how painful that can be. Most of these projects end in ab­ject fail­ure, and many col­umn inches are writ­ten on the hun­dreds of mil­lions of euro, dol­lars and pounds wasted.

As an en­tre­pre­neur run­ning a startup, you will face this choice one day, and you must re­ject it sternly. Such a project will al­ways end in fail­ure.

The es­teemed IBM en­gi­neer Fred Brooks, who led the team that de­signed many of their orig­i­nal main­frames, calls it the ‘sec­ond sys­tem ef­fect’. The ar­chi­tects get so ex­cited by the pos­si­bil­ity of build­ing some­thing new and shiny that they get lost in a maze of their own com­plex­ity.

If some­thing use­ful does emerge, it will be years late, far over bud­get, and barely func­tional. A large cor­po­ra­tion, or a gov­ern­ment body can sur­vive such a catas­tro­phe, but a startup will be long dead.

You are in di­rect com­pe­ti­tion with other star­tups (prob­a­bly bet­ter funded) for mar­ket share. If they can ex­e­cute faster by de­liv­er­ing bet­ter tech­nol­ogy sooner, you lose.

What did Face­book do about PHP? They kept the lan­guage and rewrote the foun­da­tion. They cre­ate a new in­ter­nal di­alect of PHP called HipHop that was faster and more scal­able, and could take them up to bil­lions of users.

Yes, they could hire a lot of PhDs to do this, and you won’t be able to do that, but you can learn a ba­sic les­son: don’t re­write. In­stead, adapt.

Face­book are stuck with PHP, and they will al­ways pay a price for the slop­pi­ness of the lan­guage, but they have mit­i­gated most of the prob­lems by fig­ur­ing out a work­around.

This was the bet­ter busi­ness de­ci­sion, and al­lowed them to keep adding fea­tures and out­com­pet­ing and grow­ing. Growth and rev­enue are great so­lu­tions to tech­ni­cal prob­lems!

Know­ing that you will face this mo­ment, is there any­way to make it less painful, to be slightly more flex­i­ble, so that tech­ni­cal debt does not cost you so much that it puts your abil­ity to ex­e­cute in dan­ger? Un­for­tu­nately, to quote Fred Brooks, there is “No sil­ver bul­let”. This is a fun­da­men­tal trade-off – a busi­ness de­ci­sion you can’t avoid. In­stead, you must ask what the cri­te­ria are for the de­ci­sion?

Do you (a) build as much as pos­si­ble, as quickly as pos­si­ble, tech­ni­cal con­se­quences be damned, to gain dom­i­nant mar­ket share, or do you (b) build a plat­form that gives you many years of flex­i­bil­ity, but means your mar­ket en­try is de­layed so much that oth­ers will prob­a­bly get ahead of you?

With the first op­tion you might gain an early ad­van­tage, but end up los­ing in the long-term when more ro­bust com­peti­tors slowly build up more de­fen­si­ble and deeper tech­ni­cal fea­tures (eg Google – a late comer to the search en­gine space). Or, you could also be lucky, and, like Face­book, end up so dom­i­nant that you can’t be dis­lodged, or with suf­fi­cient mar­ket share to jus­tify a de­cent ac­qui­si­tion by a larger com­pany.

With the sec­ond, you might build the best tech­nol­ogy, but never break into the mar­ket be­cause you can’t get cus­tomers to move to your so­lu­tion (eg Betamax vs VHS – that old clas­sic). On the other hand, if your tech is very much bet­ter, and you can con­tinue to de­liver at high speed (be­cause you have low tech­ni­cal debt), then you can break mo­nop­o­lies and take over the mar­ket (like the iPhone and An­droid-killing Nokia).

Both strate­gies are vi­able, and I think the de­ter­mi­nant has to be whether your mar­ket is new and grow­ing, or old and in need of dis­rup­tion.

Go with (a) if new and grow­ing – an early lead in mar­ket share is pretty much all that mat­ters.

Go with (b) if old and in need of dis­rup­tion – you’ll need great in­no­va­tion and ex­e­cu­tion to dis­lodge in­cum­bents.

We are more b) than a). These are ex­treme end­points of a strate­gic spec­trum. The mid­dle of that spec­trum is not a good place to be – you do have to choose, but there is def­i­nitely tac­ti­cal scope at each end.

In the case of voxgig, our space is tech­nol­ogy con­fer­ences. There are many in­cum­bents, and we think it’s time for a lit­tle dis­rup­tion. But we need to be able to ex­e­cute more rapidly than the in­cum­bents on the tech side if we are ever to ac­cel­er­ate be­yond them. That said, we also need to work with trial cus­tomers to un­der­stand their needs, so we have to build some­thing.

Our tech­nol­ogy choice, post-MVP, is thus to build a plat­form to re­duce tech­ni­cal debt, but not so much as to im­pact our abil­ity to de­liver use­ful soft­ware to­day. In­stead of try­ing to build the per­fect plat­form, and cover all use-cases and sce­nar­ios, we are build­ing a sim­ple plat­form that is de­vel­oped in al­ter­nat­ing stages with fea­ture de­vel­op­ment.

On a project man­age­ment level it works like this: first we build out plat­form in­fra­struc­ture. Then we work with trial clients to build fea­tures. This work iden­ti­fies holes in our plat­form (com­mon func­tion­al­ity that is miss­ing), and then we go back to the plat­form to im­prove.

We’ll con­tinue this cy­cle for the next year. But over that year, as the engi­neer­ing team grows, we’ll even­tu­ally build both plat­form and fea­tures in par­al­lel, and then move even faster. Our plat­form will re­duce the im­pact of tech­ni­cal debt and make this pos­si­ble.

There is still a tech­ni­cal risk here – if we get the plat­form ar­chi­tec­ture wrong, we’ll end up stuck, as it can’t be changed with­out a re­write. Then we’ll slow down in our fea­ture de­liv­ery. This al­ways hap­pens any­way to some ex­tent, but you want to stay flex­i­ble enough to keep ahead of the curve.

One tech­ni­cal tac­tic that we are us­ing is some­thing called the ‘mi­croser­vices’ ar­chi­tec­ture – we break our plat­form into lots of small re­place­able parts. This is very ef­fec­tive at keep­ing tech­ni­cal debt un­der con­trol.

Step­ping back, the key to mak­ing the right tech­nol­ogy choices is not about the tech­nol­ogy it­self at all. It is about un­der­stand­ing the dy­nam­ics of your mar­ket, and you how you will use tech­nol­ogy to cope with those dy­nam­ics. Pro tip: if your CTO isn’t rais­ing this as a key de­ci­sion, they’re not a CTO.

(News­let­ter up­date: 2,935 sub­scribers – nearly at 3,000! Open rate 11pc. Next week I’ll be do­ing a full re­view of our news­let­ter growth strat­egy in year one, and the re­sults – and a ba­sic mis­take I made as a leader.)

There is of­ten a call in the engi­neer­ing team for a ‘re­write’

Richard Rodger is the founder of voxgig. He is a for­mer co-founder of Near­form, a tech­nol­ogy con­sul­tancy firm based in Water­ford.

Mark Zucker­berg used PHP to build the first ver­sion of Face­book, and when it was no longer fit for pur­pose they kept the lan­guage and rewrote the foun­da­tion – some­thing most star­tups won’t be able to do

Newspapers in English

Newspapers from Ireland

© PressReader. All rights reserved.