If I could draw, this would be funnier. Plus, the area around the Dev View would be strewn with tools and parts.
When a software house tells a client that they are 50% of the way towards the completion of a project, the client seems to assume that they will be able to then look at the product as it stands and be able to play with and test 50% of it’s functionality.
I’m sorry to break it to you, clients. That’s not the way it works.
The first half of a project consists of bedding down build infrastructure, data models, functional area designs, screen designs and testing frameworks. All of the pretty stuff happens right at the end. You need to lay the foundation of a house before you can start decorating the living area.
Images are sourced from good ol’ Google Images.
I’m sorry Jason, but I think that’s the wrong way to build software.
People in the Agile and Lean communities argue that software ought to be built one feature at a time. Many of them have project structures where each month, the customer gets a _useful_ release, the contents of that release being decided by the customer’s priorities and the engineers ability to get work done.
I do like the picture though 🙂
I agree entirely.
Unfortunately, we exist almost wholly in the bespoke tender space.
Getting agile/T&M contracts in that context is hard, but awesome when it happens.
Wait a minute…technically you’re both right. The infrastructure, data modelling, screen design, FA design etc etc is what has to happen before the features can start rolling off the production line – especially once your business rules (often complex, possibly..no, *probably* mutable) make an appearance, or a data migration effort begins.
So once we have our featuresets defined and test cases and all that set up, then we can start to work to a release cycle which produces features A, B and C in month 1, then A’ (bugfix or enhancement due to changed requirements), X, Y, Z in month 2, etc etc.
It tends to be a heavy-weight ramp up time, granted, but all projects have that period of bootstrapping and design specification.
Even when going for narrow slices of end-to-end functionality (implementing a data entry screen, say, which touches the UI, business logic and persistence layers) and then adding on features as they appear in the schedule – even then we still need to have our design, our build / test / deployment infrastructure, our test cases..all of that has to exist first, otherwise we’re stuck with a glorified “Hello World” which looks nice but doesn’t actually resemble the final product in any meaningful way.
Yeah, I guess jml is getting at the fact that in the agile paradigm the jobs that you’ve outlined above all happen in much smaller chunks, much more often. Subsequently, it becomes possible to deliver chunks of functionality to the client earlier than if you were using the normal fixed-price method of delivery.
I think this situation would be improved if companies that utilised the fixed price method organised a company-wide scheme for handling build procedures, test frameworks etc.
Having said that, it becomes difficult to maintain any sort of reusable system due to projects requiring drastically disparate technologies and the pace with which technologies become redundant through obsolescence.
Yeah, I can understand that.
That said, one day the Australian people will get sick of the Government wasting their money on terrible software made with outdated practices.
Hey, less of the “terrible software” stuff 😉
Tom DeMarco (Peopleware) talks about the Agile kind of iterative development practices in an article “Software Engineering: An Idea Whose Time Has Come and Gone?” http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf , and concludes with an opinion (in my interpretation) that iterative development has a better chance of being useful instead of just negligible value over cost.
His thrust seems to be many software engineering practices are aimed at controlling the project, which can run counter to the development of better software. For example, very little experimentation can be done when the software is withheld from use for half the process. Experimentation is the kind of thing suppressed when enforcing greater control but more acceptable in iterative development.
My take is that the client interacting with the software at an earlier point, and in a regular pattern, will influence the design. Those irritating change requests because “d’oh, we built the wrong software” get factored into the a round of the iterative process, and don’t end up at the end.
Agreed but once again, when working in the fixed price field both sides of the fence tend to shy away from experimentation because any changes decided upon will almost definitely fall outside of the scope of the original contract. Change requests are an absolute minefield for all involved. Clients don’t like them purely because they are going to cost them more money and we don’t like them because it almost always turns into a fight over scope.
Part of the problem is that Government clients decide how much they think the project will cost, approach treasury for funding, get told that they’re asking for too much, renegotiate, then publicly tender the project.
Another part of the problem is that as a rule, dev houses don’t like being told how to make their software. As soon as client project teams start dictating technology stacks or doing our design work for us, we get our back up.
I guess my biggest problem with the whole system is the ‘adversarialiness’ that is built into the whole process. It is an us-vs-them situation right from the start. At no stage are we considered two groups of people working together to complete a project. They are the holders of the money and we are the contractors being paid to do a job. At times, I wonder why some of these departments even bother putting their projects out for tender? If they’re going to tear our designs to shreds and try to stretch the scope definition as much as possible, why don’t they simply hire a group of developers to build the software in-house? It’d be a whole lot cheaper.
Fascinating discussion. Great post.
The ideal of piece by piece release and iterative design sounds appealing, but I suspect it that often it will require personal and organisational genius to work in practice.
Mikey, the thing about the “all at once” approach (often called “waterfall” in the industry) is that it requires even more personal & organizational genius to work.
Actually, the waterfall model and fixed priced contracts are two different problems.
We try to avoid the provably horrendous waterfall model wherever possible, while still working under fixed price contracts.
Each of the three parts that make up our teams: Design, Tech and Test are heavily involved in all aspects of the project. For instance, I am the Lead Test for our project and I haven’t done any testing for quite some time. My role now is to evaluate our design process for testability from the ground up. I’m already finding and reporting on problems that would have lead to serious defects further down the track. Our Techs ensure that Design isn’t promising more than we can deliver while getting infrastructure bedded down to make the development process smoother. They’re also working on our automated testing framework to save resources during test and regression. This model works, we’ve proven it before. Frustratingly, due to the fixed price nature of the project, we need to have every single little thing signed off by the client before we can start work on it, our hands are tied. When we explained this to our client, they wanted to know why we weren’t simply using the “tried and true” Waterfall model. Evidently, “Because it sucks balls” wasn’t the right answer.
As you can see, an agile or T&M methodology would be much more effective under these circumstances. Unfortunately, if we were to tender that way there would always be another company waiting to undercut us with a “comfortable” fixed price contract.