chris clarke

How many developers does it take to change a light bulb?

Well, you gotta re-deploy the lightbulb application, should take a couple of minutes right? First up you have to upgrade CrappyAppServer because the boss said so. OK, so you install the new version of CrappyAppServer, but there’s a problem, you’ve run out of disk quota. But you can’t increase the disk quota yourself, you have to contact some other guy in some other department. You send the guy an email. Nothing. You escalate it to his manager. You get an email, apparently you have to fill out a form to get the disk quota increased. You ask “Do I really have to fill out the form? I only need a few more gigs and you only have to run one command.”. Yes, apparently without the form and appropriate signatures it can’t be ‘processed’. Now the form requires you to know the physical location of the box but of course you don’t know so you have to contact some other guy in some other department and it goes on and on and on ….

The One Most Important Thing About Software Development

I attended miniSPA this year and at the start of the conference we were asked to come up with “the one most important thing someone should know about software development”. This question has been bugging me ever since until I realised that there is no “one most important thing someone should know about software development”. Pattern languages such as Scrum, and practices such as XP will definitely improve your chances of success but every project has its own unique problems. Unfortunately there is no one true thing that will make everything alright - you just have to address these unique problems that exist on each project - switching to Ruby or Erlang or whatever probably won’t help. Incidentally the audience at miniSPA’s conclusion was “its about people not software”.

Origins of Waterfall Software Development

No-one knows the exact origin of the term ‘waterfall’. It was apparently coined when someone looked at a diagram in Dr. Winston Royce’s paper and remarked it resembled a waterfall. In fact the origin of the entire ‘waterfall model’ of software development is very sketchy. It is said to originate from a misunderstanding of the paper Managing the Development of Large Software Systems, written by Dr. Winston Royce in 1970.

Artists Impression of Dr. Winston Royce.

The story goes that somehow Royce’s initial diagram of a process which did not work was adopted as what we now know as the ‘waterfall model’. And was later adopted as a US Department of Defense standard (DOD-STD-2617) in 1985 and shipped across Europe in to Government and Defence projects though NATO.

From what I understand about the waterfall model, and from what I was taught, you proceed through each of the phases once, and each phase must be completed and perfected before moving on to the next. However, reading Royce’s paper, he makes it abundantly clear, on page 2, that this is not a good idea:

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

Royce then goes on to present five steps which can help prevent such a thing happening:

1. Complete the coding design before analysis and coding begins - The paper was written in a time when there were a lot of technical constraints, on data size, execution time etc… Royce had found that these things had become problems later on in projects so he introduced this stage before the Analysis stage in an attempt to catch these problems earlier. A program designer would take part in the Analysis phase making the customer aware of storage, timing, and operational constraints.
2. Documentation must be current and complete - Royce was a stickler for documentation - he used it to try and control projects and make sure that they met requirements and interface definitions. One interesting thing he mentions is that programmers should not test their own code and in this respect he saw documentation as a kind of acceptance criteria for how the software should behave - so that a separate team of testers could test the software according to the documentation.
3. Do the job twice if possible - Royce advocated the whole lifecycle process be repeated in miniature at the start of the project in order to:
   

   … quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free program.

4. Testing must be planned, controlled and monitored - The previous three steps were targeted at uncovering as many bugs as possible before hitting the test phase. In this phase, Royce recommends some methods of uncovering more problems including code review.
5. Involve the customer - Royce wanted to involve the customer as much as possible to ensure the software was closer to what the customer wanted however, in his diagrams the customer is mainly involved during design and then at the end of the project.

Having read Royce’s paper, I don’t think the document has been misunderstood as stated from several sources, I think the versions of most projects match quite closely to Royce’s guidelines - plenty of documentation, plenty of analysis and design, strict adherance to specification documents and customer involvement missing at important points. I suspect that even ‘Doing it twice’, which seems like a good idea, has been proposed during a waterfall project, but probably dismissed as a waste of time and money.

I think Royce was trying to improve a software development process which was pretty immature at the time. The most common process which people were using at the time, looked a lot like this:

Royce exposed a lot of the hidden stuff that happened around this, including important practices such as testing. He also had a lot of the right motivation to catch problems earlier and involve the customer more. Although some of his ideas have perhaps been proven to be not so helpful in the long run.

How can an application or language be Agile?

From Interface21:

… Interface21 has taught Spring and agile J2EE to over a thousand satisfied students.

What is Agile J2EE? I’d really like to know.

If you sign up for a Spring training course, one of the topics covered will be:

Agile J2EE and lightweight containers

So Agile J2EE must be something to do with lightweight containers.

But hang on, there’s all these other things here:

‘agile + with’ at Amazon

The Yawning Crevasse of Doom

Do you want your communication between the two sides to be like a ferry boat or a bridge?

via Marc McNeill and QCon.

Making the date

Having asked the question “Do you have much buy-in to use Agile?” to several non-Agile places, the answer has always been pretty much along the lines of - “As long as we keep hitting the deadlines.” Ron Jeffries has a very good article called suprisingly Making the Date which covers management and developer responsiblities to making the date in an Agile environment, I have to reproduce this brilliant cartoon from Simon Baker because it’s too good not to share:

However, I want to talk more about developer responsibilities in non-Agile places who are looking to make the move for whatever reason (Often because they think it will make them go faster. Doh!).

The second question you might ask is “Where do the features/requirements come from?”. The answer to this is often quite scary - especially when they say “Don’t know.”. But this is where Agile and especially Scrum will help to make those dates - you need to track down the source of features, often there will be many competing sources - which is a problem in itself, and start to find the people who can prioritize and eliminate these features (Because half of them under investigation will add little or no value whatsoever). Quick guide:

• Have a minimum number of feature sources (ideally one Product Owner)
• Have feature sources who most accurately represent the real customer

This is where the “buy-in” question becomes important because you will probably need support to do alot of these things. You need to be brave and be able to say “No” to feature Z or “If you want to add the shiny buttons feature, please talk to our Product Owner”. It’s some peoples job to get their features in the release because they’ve been told to, not because it adds value or is the most important feature, and they will fight very hard to make sure it does get in. So make sure you have that support first, and be prepared for an interrogation along the lines of this.

Making the most of your cheese

I’ve seen a few examples of projects where the primary stakeholders, or the people interested in the project’s success, seem very disconnected or disengaged with the project. I’m not talking about customers or end-users, I’m talking about the big cheese’s - the project/programme managers, the directors etc… You’ve probably seen a few examples of disconnected cheese, here are some tell-tale signs:

• You don’t know who your cheese’s are.
• They are based at a different site/country.
• They rarely walk the floors.
• They sit in an office somewhere and you never see them.
• You only hear from them when things go wrong.

This isn’t a cheese-bashing session however, from my experience the cheese’s are very interested in the project. After all they report to another big cheese who’s also very interested in the project. So, get them in, show them the workplace, show them burn-up charts, tell them how you are doing and any problems you are having. Even if they are in another country or reluctant to come in, just bring them in once an iteration, show them progress and ask them for help if you need it. Your goals and your cheese’s goals should be tightly aligned, make sure you are with the right cheese. In my experience, cheese’s will be very interested in what and how you are doing, and they can even help remove barriers which have been slowing/blocking your progress.

Make the most of a big cheese, they’re often corporate angels in disguise.

Trust me, I’m a Framework

From the Spring 2.0 docs:

You can generally trust Spring to do the right thing.

Iterations from Outer Space

“Smaller, more frequent steps drive a faster rate of learning, help us maintain focus, and give each of us an opportunity to see our latest work fly sooner.”, Jeff Bezos, owner of space travel company Blue Origin.

Storyboard Freeze

I’ve frozen storyboard development and no new features will be added to the old version.

I leave it in an unknown state and am currently rewriting it as you can see from my storyboard:

It shall hopefully emerge cross-browser compatible, with some of Walter Zorn’s fantastic looking DHTML libraries, lovely Enterprisey Xml, user-driven features and a bucketful of ultra-cool stuff. As my old nan used to say: you can’t beat a bit of pomopro.