Deadlines
Sunday, March 12 2006
“Many deadlines are totally and completely artificial, and I was tired of that bullshit.”
I think part of the problem is that without some sort of deadline most software developers will waste way too much time on one of the following things:
1) Building Frameworks
2) Making ambitious technology decisions (lets modify NHibernate to work with web services as the persistence layer!)
3) Constantly switch technologies to whatever is "hot" (Lets rewrite our 2000 tests to use mbUnit because we like it better)
4) Over-engineer (we need an abstract factory factory!)
Of course there is a balance, overly ambitious deadlines usually cause equally bad decisions to be made to meet the date… but not having some sort of deadlines is not the answer.
-James
Comments
- #1 Haacked on 3.12.2006 at 11:55 PM
-
Well I do believe in deadlines. However, deadlines should be set based on realistic deadlines in which the developers give input and feedback. A deadline should really be an agreement between developers and management.
"Artificial" deadlines are those that are not informed by realistic estimates, but by wishful thinking. - #2 Epsilon Aurigae on 3.13.2006 at 1:03 AM
-
Intersting post. Do you have a deadline looming? Are you feeling the pressure? The end of June will be here before you know it. Will you get it done? Or will it just be vaporware?
- #3 James Avery on 3.13.2006 at 1:27 AM
-
Actually my post was pointing out that deadlines are important. I think we will be just fine, thanks for your concern. (clever name though)
- #4 Rajeev Gopal on 3.13.2006 at 2:12 AM
-
Deadlines are important, as said. In technology companies, technologies are more realistic that that made in a business driven environment. That is what I have seen. This might not be 100% true, but...
Clients are dealt by mostly business analysts, who may or may not have programming background. "You want this to be done by next Tuesday? What about this Friday?"
Result? Programmers burning midnight oil.
This case would not be seen when BAs involve programmer leads in their deadline decision making... - #5 Richard Jonas on 3.13.2006 at 10:06 PM
-
I think the key to avoiding your four problems is to make sure you add a new feature that means something to end users every week or so. If you show these features to your users as you develop them the business analysts will know how fast you can work and be more realistic.
- #6 Jeffrey Palermo on 3.15.2006 at 3:17 PM
-
Deadlines are just one point in the triangle. If there is a business deadline, the scope of work and number of developers have to be adjusted to make it fit. If the development team is constrained, the feature set has to flex. If X feature just HAS to be there, then that's when you throw out the deadline and estimate your real deadline.
We do that every day. Given a scope, we have 4 developers. We estimate how long it will take us and give three dates: 50% probability, 70%, and 90%. The 90% date is the date they can actually count on unless something external delays us. We tell the higher ups that this is what they are looking at. They appreciate the analysis, and they've never said "screw you, meet my date".