Following on from a previous post, you’ve probably guessed that I am not a big fan of BIG projects, particularly if it is all new development (I’m not actually much of a fan of ANY big project, but I might get to that some other time). However, I think it is important to keep an image of what you want to end up with. I liken the idea to painting a large seascape – there are certain key elements that are required (e.g. the sea, in some representation), and there are common elements that you would expect to see in the finished picture. There are probably some requirements re overall size of the picture, type of frame etc. Now, what you finish up with may not be exactly the same as you started with – perhaps there’s a lighthouse in there now, perhaps the sailing ship turned into an oil tanker – yada, yada. BUT – you ended up with a seascape with the critical elements in place somewhere.
What’s this got to do with software development?
- You have to have a frame, or constraints
- You have to have a vision of the final result
- You have to be amenable to changes in the required components
And if you are painting this software for someone else, they need to be part of the process (where do you think the lighthouse idea came from!). Even if you’re painting it for yourself (a lot of open source development comes about from programmers scratching their own itch), I’m willing to bet that what you end up with isn’t what you started out to do in every detail.
Is this a methodology? Not really – just an analogy to make sense of where I think programming should be at (or where I like it to be at). If you want methodology, I recommend Alastair Cockburn as a starting point, because what he suggests matches my own experience of both large and small projects. Cockburn is one of the proponents/authors of the Agile Development Manifesto, and a founding member of the Agile Alliance. I also like what he has to say about the value of the people in a development (or indeed, any other) team.