Monthly Archives: June 2013
The main problem with sharing information, is that most of the time people just don’t listen very well.
“What do you mean the project is late?!”
“Boss, It was always going to be late. It was doomed from the start.”
“So why the hell didn’t you say so?”
“Actually, I did.”
Being a software developer isn’t easy. Working on projects that don’t deliver as expected are common. However, most software projects don’t end up late unexpectedly – they were bound to be late before they even started.
Let me share a few typical reasons:
- The project manager allocates 8 hours of your time to the project each day, even though he knows all too well that you spend 2 and sometimes even 3 hours per day handling support, production issues and answering questions from management and sales. Some days you even have lunch, even though it’s against company policy. Now you’re 20-30% behind schedule already. Swell!
- Someone set a deadline before anyone have a clue what to solve, and much less how. In reality, most deadlines don’t even signify an important event for the project or product. It’s just an artifical date set because the customer decided “It has to be done by December 1st!”. No, it really doesn’t.
- You’re only allowed to spend an absolute minimum amount of time analyzing customer needs. And by all means, don’t attempt to figure out the best way to solve the problem. “The deadline is set already, we don’t have time to sit around thinking and wiggling our toes! Start DOING something, for heavens sake!”
- Management ignores any concern or warning voiced by the development team, and the team accepts any assignment, however unreasonable. “But boss, this is never going to be done on time!” “Well, it has to be! You’ll just have to find a way!” “Oh, okay. I guess we’ll have to figure out a way to deliver everything you’ve promised on our behalf without reducing quality or functionality. I mean after all, we’re basically wizards over here.” No, I’m afraid you’re not.
Bosses and sales people insist that you try to deliver, however unrealistic the goal may be. “We can’t let the customer down!” In the long run, giving in to unrealistic expectations actually hurts the customer. Each time the development team takes on more than it can handle, it compromises either quality or time. More time spent on one customer, means less time spent on another. Delivering bad quality and bugs, means even less predictable availability later on.
In order to satisfy all our customers in the long run, we need to be as effective as we possibly can, and deliver consistent quality at a pace that the team can handle over time. That may mean some difficult discussions and difficult decisions. However, it is better to adjust the expectations of the customer now, than to disappoint him with an inferior product or a missed deadline later.