Audio Postmortem: Modern Groove - The Ministry of Sound Edition

The Idea

Moderngroove's simple yet innovative concept was to make a be-your-own-VJ product set to the music of the Ministry of Sound. The idea was to bring the sights and sounds of club life into your own living room.

It took a long time to convince the Ministry of Sound to use their music since they were used to a much higher profit margin on their CD releases. In the end, it all worked out and we ended up with five hours of exclusive DJ sets from one of the most popular super clubs and dance labels in the world. It also took a few months to secure our publisher, UBI Soft, since we had the resources to hold out for a good contract.

When we started Moderngroove in September 2000, we had approximately two months to complete the project. Everyone knew the timeline was silly, but tasks were scheduled to fit the development time anyway. This is definitely one of the most common errors in management and scheduling: making the tasks fits the timeline rather than making the timeline fit the tasks. This had the unfortunate side effect of making us very reluctant to schedule later on in the project. We felt that it only resulted in us feeling bad about missing self-appointed deadlines and wasted time continually adjusting for arbitrary slippage and delays.

	Tall Paul appears as one of the five DJs from the Ministry of Sound

We continually believed that we could heroically manage the project as a team, which further extended the development time and stress on the team, especially the lead coder. I believe that a good manager with experience in similar small projects might have saved us a bit of time and a fair amount of stress, but I also believe that the project's schedule would have still remained largely unchanged and unmanageable. This was due to the sheer number of unknowns: new team, new company, new development environment, new workspace, new tools, new hardware, new product and so on.

Our basic problem came from a continual slippage of our ship date. Each month, from November 2000 onwards, it slipped a month until we finally shipped. To the team, we always pushed for the next final date, seemingly always just out of reach. We amassed many hours of overtime, which took its toll on us physically and mentally in the long run. We were quick out the starting gates with a simple prototype, but we eventually burned ourselves out. In hindsight, we could have likely gotten the project done sooner with less stress by working regular hours towards a more realistic final ship date.

Unfortunately, for small developers, there seems to be a lack of good management theory available. This is partly due to the fact that larger teams require more management, but more likely due to the fact that larger companies, universities and government agencies have the luxury of more time and money to spend on researching and documenting their process. In a small company, it is difficult to get paid to do proper software engineering since one is usually too busy trying to show how much stuff (coding) is getting done rather than concentrating on less quantifiable tasks like design, documentation and process analysis.