The pragmatic development way
My take on software developmant managment :
- Control scope = risk – beware of over enthusiastic product manager or just too many of them.
- Nothing is going to help a bad design – not agile, not XP or waterfall
- Get QA, Tech Support, Services and Tech Writer involved whenever you can. I found issues just by explaining functionality to tech writer. If I can’t articulate it, it means that something is wrong in the requirements, analysis or design.
- Skilled developer can make up to 10x difference – not my finding (10x Software Engineering ) but I believe in it! I saw it!
- Build supportability in - always imagine the feeling when you get a support call that your system crashed on customer site leaving no logs.
- Track incident/escalated ratio – keep it to less than 10%. More than that will severely impact new development schedule. It is not fun to constantly maintain.
- For an interactive system with lots of simultaneous users or system that is installed on “dirty” environment (like thick client) consider using en escalation team to protect the rest of the development schedule.
- Monitor platform, tools, technologies on a quarterly bases
- I don’t know of any other tool than tracing or logging for troubleshooting concurrency issues. I sometime use WPF Trace Monitor. Feel free to tell me about other tools.
- How do you know that the system is ready to be shipped? – it stops or rarely surprises you!