When you are familiar with the software industry you know that deadlines are always set very tight.  Most are so unrealistically they will never be reached.

But how often is this nothing else then poor management style?  Here is this company with a CTO and three project leads, one analyst, one tester, one GUI designer, two junior programmer, one programmer and three senior programmers.

Programmer A		I predict that the CEO is forcing us to work heavy overtime.
Programmer B		Let the madness begin.
Programmer A		I was afraid of that.
Programmer B		The CTO shifted all of the production dates around for the new contract to accommodate a later start (6 weeks) and roughly the same finish time.
Programmer A		I did see that.  Remember, I said that the CTO will ensure that: a) If it works it was all HIS effort b) If it does not work nothing was his fault, just the low people, named programmers.
Programmer B		You say that that’s Thanksgiving Holiday?  No Problem!  Just make sure that everything’s done a week earlier, so that the CTO and the project lead can go on their respective vacations! [The team wasn't finished a week early, but the CTO and project lead went on their vacations anyway.] No one expects you to contribute to this round.  Lucky You!
Programmer B		Eehh!  Wrong!!  I already got the first request to start working on Monday.  After I announced that I’ll take off until the end of this week because of the new baby.  Two and a half days off are way too much!  I even worked the night before my daughter was born…
Programmer B		Tests?  I know our two juniors will be writing those.  Let the nightmare begin!

How blind can a management team be?  Even the lead programmer admitted in meetings that the programming team would be coding to the deadlines instead of the design.  Essentially that it is a real big mess.

And it was getting worst by the day.  A new compiler version just came out and another one will be out when approaching the deadline.  Tools used were all over bugtrack: Holes here and there.  Did management care?  Nope, they just waited until the customer complained and then management went into the deserved weekend while the plebus worked…

Now let’s take a closer look at this situation:

• The CTO had no idea how to properly plan a project.
  You just do not change one important variable and ignore the influence that has on other project variables.
  Changing the starting date without changing the deliverable date can only mean one of two things: Your initial time assessment wasn’t worth the paper written on or you are just looking to descend into hell.


• The team had a big water-head - why one CTO and three project leads?


• There is no communication happening in the team.  Or if it does the programmers are ignored by management.
  A six week change?


• The team already is in a motivational gap.  
  What does that tell you about the quality you can expect?


• Leave testing up to the most inexperienced developers raises another question about quality.


• Leaders lead by example.
  How can the CTO and one project lead take off while the team is struggling?
  There is no team spirit at all.


• There are two times during the year when you need to keep in mind that your employees - especially family oriented ones - get side tracked a lot: summer vacation time and the holiday season.

Mind you that management decided to lie about the implementation deadlines set from the customer.

Many of the problems could have been easily avoided with more honesty towards the employees and team without the management overhead.