Last week I gave a talk at Agile Austin entitled “How does design get done on an Agile Project?” The slide deck can be downloaded here, and, thanks to Chad Myers, you can watch the video feed on Viddler. (There is content in there after I get done being hamhanded with the A/V stuff).
Major points and questions:
What do you mean there isn’t an Architecture Phase? When does design get done? All the time. Continuously. Design is too important for the success of your project to be restricted to a brief “architecture phase” anyway. Design is all around us. Design surrounds us, penetrates us, and binds the system together. No seriously, design is happening.
Can this work? Yes, it can, if you have good people with solid design skills who can also communicate their ideas and thoughts to others. People are still the most important factor in a project.
Who does the design? Every single coder on the project. Oh, your senior guys are going to make most of the decisions, but every single developer should be participating in the design and be able to explain the design. Developers do much better with a design if they understand how it came about. The best way to understand how it came about was to be there at its creation. At a bare minimum, the worst developer on the project team should at least be a source of feedback for the design. “This is hard to code this way” or “I don’t understand what I’m supposed to do here” from your junior most developer is still a sign that something might not be right with your design.
Anyway, enjoy Chad’s camera work, and here’s some relevant links.
Links:
Is Design Dead? – Martin Fowler in one of the most quoted papers of all time
A Microcosm of Agile Design – but, but, but Web Services are easier than they used to be. I don’t care if it’s easy to build a web service. It’s still more mechanical work to build a Web Service than a library that runs in process with the rest of your code. The automated tests run slower if there’s SOAP in there anywhere, the deployment is a bit more work, and it’s just more friction all the way around.
First Causes: Reversibility. But it’ll be cheaper if we do it now! We should just build the web service/caching infrastructure/generalization now while we’re in the code! It’ll be harder later! We have to get it right upfront, or all hell is going to happen. All those fears are valid, but we can eliminate the cause for concern by paying attention to the reversibility of our design decisions.
“Code Complete” is a lie! Done, done, done is the truth
The Last Responsible Moment – Make decisions at the right time. Sometimes delaying a commitment to a design until you have more information is the best course of action.
Ordering Code Construction Tasks – Work vertically by feature! Don’t schedule your development in terms of infrastructure or technical layer. Everything follows from a business goal.