1. Talk to the users / Fully consult the users;
2. Let user interface people and psychologists in there;
3. Let not have the engineers only have a say;
4. Get people who like what they’re doing. Have a core team of smart, motivated developers;
5. Take away budget pressure and let people do *good* and sustainable work;
6. Make them “own” their project. Give them responsibility.
7. Burn up all documents;
8. Find out use cases. Discuss them. Jot down drawings of all sorts of things on whiteboards. Take photos of that;
9. Use a big wiki thing for documentation;
10. Don’t implement features nobody wants because they are buggy and hard to understand;
11. Deliver often;
12. Have more chocolate;
13. No #13;
15. Make the system testable;
16. Test a lot / Automate testing where possible;
17. Work on the system in one team across contractors.
18. Have managers who understand software and give the developers time and space to do what they need to do;
19. Have enough money to sustain an environment where people don’t keep leaving (for example, like Google, encouraging people to start their own mini-business/project inside the company).
The biggest problem is that the people who pay for (and therefore control) the development work don’t have the opportunity to learn how complex the system really is, and assume that it can all be written in a week. It needs to be user-led, rather than imposed upon them from upon high.
Get a real idea of how/what the system is expected to do. And only then start thinking of what technologies are needed to implement it.