Group of Programmers

What to do with a Group of Programmers at the start of a project?

December 2002

This was a 5am thought when I was thinking about my current staff levels, memories of a classic cartoon (you lot start programming and I'll go upstairs and see what they want) and readings such as McConnell's Rapid Development.

A common problem is lack of clear or any requirements at the start of a project but, for political or budgetary reasons a group has to be hired or deployed on the project. The Staffing Curve is kinda square.

Another problem, particularly with guys just out of college is lack of empathy with end users.

Ideas to get the team busy, help refine requirements and improve their general attitude and awareness, not in any particular order of priority:

Put them on the support lines so they learn the common problems customers have with the existing products.
The classical - put them on the factory floor (ie: alongside real users) as if they were new hires, so they learn the complexities of the business. Depending on the level of experience at which you hire development staff, they may never have had a job, or a non-programming job.
Have them write user documentation for the existing system (including non-computing procedures).
Testing the existing system - have them walk through it, possibly writing test procedures if they aren't documented. If they are trying to break the system this will bring home the quality level they need to exceed and give them empathy for users.

Note: this is not the same problem as the classical wandering in the fuzzy front end as best summarised by this Dilbert where management delays mean the project doesn't get started until too late. I'm just talking about what to do when you are forced to hire a team and don't want them sitting around going stale.