Member Login

Lost your password?

Registration is closed

Sorry, you are not allowed to register by yourself on this site!

Can you write software by planning everything up front?

Image: nut­takit /

Tra­di­tion­ally soft­ware was designed as a large up-front plan­ning task, using tech­niques such as the water fall model of soft­ware devel­op­ment. In these approaches the entire sys­tem was analysed and the soft­ware and hard­ware com­po­nents archi­tected up front, cul­mi­nat­ing in a com­plete design that just needed to be acted on by pro­gram­mers to deliv­ery the entire work­ing system.

This is actu­ally the way that most projects are planned in the non-software world, for exam­ple, when a build­ing is con­structed the plans are approved up front, the mate­ri­als are cal­cu­lated and plan for the con­struc­tion is pro­duced. Then it is just a mat­ter of fol­low­ing the plan, with the right indi­vid­u­als for the job, with the right mate­ri­als, in the right order, and the build­ing gets built.

Of course, inevitably prob­lems that occur in the deliv­ery phase; some­thing wasn’t thought through prop­erly, some mate­ri­als don’t per­form as planned, the envi­ron­ment doesn’t behave as expected, the exter­nal depen­den­cies don’t come in on time. This means that even when all the plan­ning has been done in advance, even to a high qual­ity, there is still a large uncer­tainty around deliv­ery dates, and over­all cost of the project. It is rare that a project can be deliv­ered with­out some form of re-evaluation of the design axioms emerg­ing from knowl­edge encoun­tered dur­ing delivery.

Things get inter­est­ing when you begin to really take on board that how­ever much you believe it can all be planned in advance, the real­ity is that you moment you make any changes to the sys­tem, new infor­ma­tion emerges that wasn’t present when the orig­i­nal plan was made.

I chal­lenge you to recall any cir­cum­stance in which you planned every­thing first, and then imple­mented the entire project with­out mak­ing any changes to that plan on the way. I bet you can’t!

Tags: , , , ,

14 Responses to “Can you write software by planning everything up front?”

  1. Liam Kurmos says:

    im actu­ally being my home along much more agile lines

  2. Liam Kurmos says:

    not sure what the plan­ner might think of this though

  3. @Liam, how do you mean?

  4. Liam Kurmos says:

    my bad spelling again…i tend to build­ing things roughly and quickly and then try them for a bit before i improve or some­times scrap them. applies to rooms, sur­faces even staircases

  5. Dave Hawes says:

    In the world of soft­ware and specif­i­cally exe­cutable uml mod­el­ling the basic idea was that the plan would proven before any imple­men­ta­tion (or trans­la­tion as they called it) took place.

  6. I find that in prac­tice nei­ther pure water­fall nor pure Agile really works all that well, but a lot of it depends on the project and the integrity of the require­ments. Agile is won­der­ful from a developer’s per­spec­tive, but the pow­ers that be (i.e. the peo­ple with the money) like to see up front cost esti­mates and mile­stones. I find that a hybrid solu­tion works well in many sit­u­a­tions, and have been apply­ing this for the devel­op­ment of med­ical soft­ware where you have all kinds of process-related reg­u­la­tory bits to worry about, too. Look­ing for­ward to which con­clu­sion you will be tak­ing this series!

  7. @Liam, that’s the other approach isn’t it? Con­tin­u­ous devel­op­ment; iter­at­ing over and over, refin­ing and improv­ing until it begins to take shape. That approach on it’s own isn’t suf­fi­cient, to build some­thing high qual­ity, but it is necessary.

  8. @Dave, you spent a lot of time work­ing with case tools, didn’t you? What in your opin­ion pre­vented this dream of being realised?

  9. @Willem, there’s been a lot of atten­tion put towards “Agile” in the soft­ware com­mu­nity, but just because you call it a duck don’t mean it is a duck. A lot of soft­ware houses do what they call Agile, but really all they’re doing is estab­lish­ing a new set of dog­matic prac­tices. There are loads of peo­ple sell­ing the buzz­word, either as books or soft­ware, with the promise of “just fol­low this and it will all work”. Sadly it doesn’t, and the more pre­scrip­tive it is, the more unlikely it is for the sys­tem to be able to deliv­ery it’s max­i­mum poten­tial. On the other hand, there is a dance to get­ting it right, and the steps need to be prac­ticed. How­ever, when it works really well it’s like a freeform impro­vi­sa­tion, not a pre-choreographed structure.

    And, I don’t dis­agree that from the out­side look­ing in a plan needs to be in vis­i­ble, so that other activ­i­ties can be struc­tured; like mak­ing the cash avail­able on time, or meet­ing the regulator’s time tables. How­ever, oper­at­ing hon­estly, this plan can only be con­sid­ered a work in progress and a just view on the state of the project, not a dog­matic pre­scrip­tion of how it will be done. Fail­ure to take this per­spec­tive always leads to pain as real­ity diverges from the “plan[tm]”.

    What replaces the plan are a set of care­fully cho­sen met­rics which allow all play­ers to under­stand the risks, diver­gences and con­ver­gences, and change the pri­or­i­ties as flex­i­bly as pos­si­ble to meet the require­ments in the order that gives most value.

    Given the med­ical area that you are work­ing in Willem, how much do you find that the reg­u­la­tory bits influ­ence the process? Has it sig­nif­i­cantly changed the way that you think about deliv­er­ing software?

  10. Liam Kurmos says:

    @jo. what’s the flaw in pure con­tin­u­ous developement?

  11. @joe, will you be talk­ing about these “care­fully cho­sen met­rics” in a future blog post? Peo­ple (espe­cially non-dev types) like to see plans, because that’s what they’re used to; which we as devel­op­ers then have to some­how live with. But in my expe­ri­ence what they actu­ally like to see even more is mile­stones. At the moment, the way I present our soft­ware devel­op­ment to the other stake­hold­ers (clin­i­cal, reg­u­la­tory, com­mer­cial) is by way of a high-level plan, bro­ken down into iter­a­tions with mile­stones. The plan is not rigid, but the mile­stones are. Attached to these mile­stones are deliv­er­ables based on high­est pri­or­ity require­ments (which are re-assessed after each iter­a­tion) which can be quite high-level and there is there­fore sig­nif­i­cant room to wig­gle in case of an unex­pected issues dur­ing devel­op­ment. What goes on under­neath though, is largely invis­i­ble to the outsiders.

  12. Argh, I hit . Any­way, I’m ram­bling. To give a brief answer to your reg­u­la­tory ques­tion. The reg­u­la­tory bits can add some pretty severe con­straints to the devel­op­ment, depend­ing on the risk clas­si­fi­ca­tion of the device. But mostly, the reg­u­la­tory aspects spe­cific to soft­ware force you to really think about the life­cy­cle processes you have in place. They also force you to be dis­ci­plined in adher­ing to your processes.

  13. @Liam, first we have to be clear that we’re talk­ing about the same thing. The term “con­tin­u­ous devel­op­ment” in itself is just a place holder for a num­ber of dif­fer­ent prac­tices, each of which can be done poorly or in a way that is high qual­ity. When you think about this kind of devel­op­ment, what qual­i­ties do you asso­ciate with it? Are these qual­i­ties emer­gent auto­mat­i­cally, or do the devel­op­ers also have to attend to them in a par­tic­u­lar way for a high qual­ity output?

  14. @Willem, I def­i­nitely will. It’s going to take me a lit­tle while to get to met­rics, as there are some things around feed­back and inter­ac­tion that I want to cover first I think, but you can expect some thoughts on this area.

    When you’re putting together your high level plan with the asso­ci­ated mile­stones, how do you know how real­is­tic it is? How do you go about edu­cat­ing your stakeholder’s expectations?

Leave a Reply