Hero Development: Sucking Up Project Disasters

In my first few years as a developer it was common to work an hour or two extra hours per day. Me and my colleagues were all around the same age and young, free and single so it wasn't really work but just a continuation of our hobby.

Fast forward a few years and you settle down, kids come along, you find your perspectives changing. You become wiser with age Looking back there are always lingering questions:

• What did      that extra work achieve?
• Did it      make you happy?
• Did you      get compensated in any way?
• What did      you miss out on?

Unfortunatley history has a habit of repeating itself. We had an impossible deadline. The estimates were wildly inaccurate. The start date had passed by weeks yet the project hadn't started. How do you start work on a project when you know, almost for certain, that you're setup to fail.

It is inevitable, you have to suck it up.

This is okay for a bit, but as the weeks and extra hours pass by. The early mornings and late evenings arent even noticed as you churn out code. Code that is riddled with bugs. The spec isn't followed, shortcuts are taken. All these issues make the project longer as well as your love for the job begins to fade.

A better way?

I did work for a company that had a decent work life balance. We hardly ever had to work any extra. In fact, it was even encouraged to leave early.

How could one company be so different to the others?

As far as I can tell, it's as simple as planning, telling the truth and team work.

Planning

To plan well you need to do a lot of work up front. No coding, but perhaps some prototyping, dicussions and drawings. Coding at this stage will be wasted, you will just endup coding and fixing!

Truth

What do I mean by telling the truth? For starters, there's no point over promising. It's better to be honest - saying "no" rather than yes to something impossible. This is where using scrum estimation cards (Planning Poker) come in handy. Everyone can be involved in the estimates and dates are discussed. The responsibility of estimating when a piece of work will be done should not be taken by one person. In fact, that is ridiculous. Even talking of dates is old fashioned and silly because anything can happen. This is why Scrum and Agile are so popular. Their short development spans allow planning and estimating to be done realistically. Meaning the customer is not let down at each failed milestone.

Team Work

Team work is not just about your team of colleagues, but must include your customer too. If they are not part of your team then there is no hope. They must trust you and you must trust them. If you start working against each other then quickly you'll find politics, accusations and sniping become frequent problems. Work with the customer and be honest.

Project Management

Good project management is hard. Keeping everyone happy is hard. I've found that by working together and saying "no" when appropriate is a good start to a successful project. Scum and Agile methologies are great, but many old fashioned companies still rely on code-and-fix style management. This just leads to you having to sucking up all those extra hours.

Plan better, with smaller pieces of work and being truthful are a good start to a successful project and not to sucking up loads of unplanned hours.