Jason Fried has written the beginning of a series on a development process he calls Getting Real. I'll be interested to see how the rest of the series pans out, but I don't think his process is any major improvement on the "backwards" route taken in other projects. Unless his approach includes a focus on small feedback loops and working code above pretty models (yes, even UI models), the improvements won't be significant.
Jason describes the first step in developing a software project as the user interface (UI) design. He goes on to summarise:
Bottom line: We want to build something we can all start looking at, using, clicking through, and “feeling” before a line of back-end code is written. We want to be in front of the customer experience for as close to 100% of the time as possible.
We were forced to use a similar model for a university project in a team of 10. User interface design came first, followed by the "semantic mapping" of user interface objects onto database tables. Code was written to uh, glue the user interface together with the data model and then the whole kit was "tested". Of course, the test scripts were based solely on the user interface design, we didn't test all the business logic in the code.
What was the outcome of this approach? All the complexities of what the software actually does were left to the "coding" stage at the end. We had a great idea of what sort of interface we wanted, but just going from one screen to the next, and storing the information shown on each isn't the only thing a system does. Its interactions with other systems weren't fully considered in the UI design stage, nor the data processing done by the system when not visible to the user. Clever breakthroughs of innovative ways to display the system information was not possible, because everything was planned up-front.
Luckily for us, university tutors have even less attention to detail than the typical student, so a cursory look at the beautiful user interface left a good impression. Unfortunately, real customers aren't so simple. They actually want their software to work!
So what's the alternative? Instead of pushing just the user interface design to the front of the development cycle, push the coding there too. Use the "story" model Jason proposes to capture the requirements of the software, and get working on the first version of it. When you've been working on it for a week, and you've got a little bit of code, a little bit of database, a little bit of user interface, show the customer. Take their feedback at this point and make appropriate changes.
You may need to change the user interface because it doesn't fit the requirements of the application. This is good. Business users aren't user interface designers, and noone can design a good interface without a lot of information about the system at hand. Whatever you do, don't make develop something early in the piece, and refuse to change it -- code, UI, design, whatever. You're tying yourself to a sinking ship.
Implement a policy of extensive testing from the start of development. Make it a priority by making your coders write automated tests, and having your customers test the system from the get-go.
It will be interesting to see the completion of this series. But judging from the first article, it's yet another attempt at big design up-front. It just doesn't work.
