Well, I have been put straight by an ex-colleague about my not discussing more high level project processes and tools. Hmmm, methinks that this would not be an “aside” but full on work. So, if you like this then I expect to be paid (and I shall collect on my return to Australia) ;-) OK, if this is not to be about that which I do for fun, then I shall have to put my Consultant hat on and pull up a soap box. I shall simply address a greenfield site.
- Rule #1: the project is not well defined. Even if a professional has created a requirement that has been pinned down and signed off with the client, read Rule #1.
- Rule #2: Don’t create a big fancy plan (yes I hate waterfall methodologies) especially considering Rule #1. Consider using Agile methods.
- Rule #3: big teams of lower skilled staff get nowhere fast. Collect together your small crack team, protect them from forces external to the project and make sure they are having fun working hard. And I mean that in the most positive way that nurtures great results by great people.
- Rule #4: keep your client close, show them the list of deliverables, and negotiate items on and off that list as they come to understand what they have asked for. Yes, think about Rule #1.
- Rule #5: review internally on a regular basis, try a half hour nearer the end of each day. If your team is agreeing to delivering functionality on a weekly basis, this will keep them together and focused.
- Rule #6: an automated environment pays dividends, build it quickly. Open Source is your friend. Daily check-ins, nightly builds, review the automated reports. Tests define your work, they are not a bolt on.
OK, now I’m off my box I might sit on it, put my feet up and discuss process and technology.
- Process: yes, know what you are doing and be rigorous. Consider Agile Unified Process or OpenUP. I’m a tad biased as an Eclipse fan, but I recommend the latter.
- Peer review: don’t check-in until you have coffee with a team mate.
- Source code control (SCC): Start using straight away, it self documents developer work progress and protects against foolish coding diversions (VMS was right in giving file versions for those who did not do the right thing). I have been working with CVS recently which is both easy to setup and administer. BUT it is now too old and has design flaws. Use Subversion. Maybe consider Git.
- Continuous Integration (CI): again set up early. It will exercise build and what testing is in your repository, and it’s nice to see that all went well overnight. The reports will save the lead a lot of time. I last setup / used CruiseControl but review your options. Make it deploy automatically to your first test ground – again it is nice to see a development server running correctly in the morning.
- AUTOMATE: yes CI automates but at the nitty gritty level, make/ant/nant are your automation friends.
- IDE: save time and effort (I’ve said enough in my blogs already). Make a template for local development / build / test that can be replicated to each developers system. Yes, systems can break, people can join or leave.
- TESTING: this is a specialist area but I like the V model to keep me (a non specialist) on track. It also points towards more mature development projects (not the greenfield we discuss here)
Well there is my first attempt at talking about what makes a software project hang together. If you have observed Rule #3 then you can leave the detail to your guys – so I won’t have to mention fancier tools, the likes of UML and MDA, for now :-). Oh, and if you have a new role like development manager or project lead, I hope this helps to get you going.
Alex Garrett: Designer, coder, ranter and writer at www.lexecorp.com
Often seen working the crowds (promotions, soliciting, begging,…) but mostly freelance coding for a meager living.
