Image: nuttakit / FreeDigitalPhotos.net
Traditionally software was designed as a large up-front planning task, using techniques such as the water fall model of software development. In these approaches the entire system was analysed and the software and hardware components architected up front, culminating in a complete design that just needed to be acted on by programmers to delivery the entire working system.
This is actually the way that most projects are planned in the non-software world, for example, when a building is constructed the plans are approved up front, the materials are calculated and plan for the construction is produced. Then it is just a matter of following the plan, with the right individuals for the job, with the right materials, in the right order, and the building gets built.
Of course, inevitably problems that occur in the delivery phase; something wasn’t thought through properly, some materials don’t perform as planned, the environment doesn’t behave as expected, the external dependencies don’t come in on time. This means that even when all the planning has been done in advance, even to a high quality, there is still a large uncertainty around delivery dates, and overall cost of the project. It is rare that a project can be delivered without some form of re-evaluation of the design axioms emerging from knowledge encountered during delivery.
Things get interesting when you begin to really take on board that however much you believe it can all be planned in advance, the reality is that you moment you make any changes to the system, new information emerges that wasn’t present when the original plan was made.
I challenge you to recall any circumstance in which you planned everything first, and then implemented the entire project without making any changes to that plan on the way. I bet you can’t!
Tags: design, feedback, iteration, planning, programming
im actually being my home along much more agile lines
not sure what the planner might think of this though
@Liam, how do you mean?
my bad spelling again…i tend to building things roughly and quickly and then try them for a bit before i improve or sometimes scrap them. applies to rooms, surfaces even staircases
In the world of software and specifically executable uml modelling the basic idea was that the plan would proven before any implementation (or translation as they called it) took place.
I find that in practice neither pure waterfall nor pure Agile really works all that well, but a lot of it depends on the project and the integrity of the requirements. Agile is wonderful from a developer’s perspective, but the powers that be (i.e. the people with the money) like to see up front cost estimates and milestones. I find that a hybrid solution works well in many situations, and have been applying this for the development of medical software where you have all kinds of process-related regulatory bits to worry about, too. Looking forward to which conclusion you will be taking this series!
@Liam, that’s the other approach isn’t it? Continuous development; iterating over and over, refining and improving until it begins to take shape. That approach on it’s own isn’t sufficient, to build something high quality, but it is necessary.
@Dave, you spent a lot of time working with case tools, didn’t you? What in your opinion prevented this dream of being realised?
@Willem, there’s been a lot of attention put towards “Agile” in the software community, but just because you call it a duck don’t mean it is a duck. A lot of software houses do what they call Agile, but really all they’re doing is establishing a new set of dogmatic practices. There are loads of people selling the buzzword, either as books or software, with the promise of “just follow this and it will all work”. Sadly it doesn’t, and the more prescriptive it is, the more unlikely it is for the system to be able to delivery it’s maximum potential. On the other hand, there is a dance to getting it right, and the steps need to be practiced. However, when it works really well it’s like a freeform improvisation, not a pre-choreographed structure.
And, I don’t disagree that from the outside looking in a plan needs to be in visible, so that other activities can be structured; like making the cash available on time, or meeting the regulator’s time tables. However, operating honestly, this plan can only be considered a work in progress and a just view on the state of the project, not a dogmatic prescription of how it will be done. Failure to take this perspective always leads to pain as reality diverges from the “plan[tm]”.
What replaces the plan are a set of carefully chosen metrics which allow all players to understand the risks, divergences and convergences, and change the priorities as flexibly as possible to meet the requirements in the order that gives most value.
Given the medical area that you are working in Willem, how much do you find that the regulatory bits influence the process? Has it significantly changed the way that you think about delivering software?
@jo. what’s the flaw in pure continuous developement?
@joe, will you be talking about these “carefully chosen metrics” in a future blog post? People (especially non-dev types) like to see plans, because that’s what they’re used to; which we as developers then have to somehow live with. But in my experience what they actually like to see even more is milestones. At the moment, the way I present our software development to the other stakeholders (clinical, regulatory, commercial) is by way of a high-level plan, broken down into iterations with milestones. The plan is not rigid, but the milestones are. Attached to these milestones are deliverables based on highest priority requirements (which are re-assessed after each iteration) which can be quite high-level and there is therefore significant room to wiggle in case of an unexpected issues during development. What goes on underneath though, is largely invisible to the outsiders.
Argh, I hit. Anyway, I’m rambling. To give a brief answer to your regulatory question. The regulatory bits can add some pretty severe constraints to the development, depending on the risk classification of the device. But mostly, the regulatory aspects specific to software force you to really think about the lifecycle processes you have in place. They also force you to be disciplined in adhering to your processes.
@Liam, first we have to be clear that we’re talking about the same thing. The term “continuous development” in itself is just a place holder for a number of different practices, each of which can be done poorly or in a way that is high quality. When you think about this kind of development, what qualities do you associate with it? Are these qualities emergent automatically, or do the developers also have to attend to them in a particular way for a high quality output?
@Willem, I definitely will. It’s going to take me a little while to get to metrics, as there are some things around feedback and interaction 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 associated milestones, how do you know how realistic it is? How do you go about educating your stakeholder’s expectations?