The Old Joel on Software Forum: Part 3 (of 5)

Doomed from the start

Here's a quote from a Joel article: "When I'm behind schedule, I feel doomed and depressed and unmotivated."

We are starting a new project and the deadline is handed down from the owner of the company. Just looking at the requirements makes me feel "doomed, depressed and unmotivated". There is a constant dirge in the back of my mind when I work. It beats out a slow rhythym: "doom... doom... doom... doom."

I am not going to quit, find another job, change careers, etc. I'm also not terribly concerned about job security. What I am looking for is a mental (psychological?) approach to this "doomed project" that will help me feel motivated. In short, what did _you_ do to get motivated on a doomed project?

Thanks,
Doomed

Doomed
Monday, December 15, 2003

"If a man believes he is going to die, he will make it happen." I believe a wise telepath once said that. The best psychological motivation I can think of to offer is basically modularization; make sure even if the rest of the project dies, your part should be the greatest success.

Sorry if that sounds glib.

Andrew Burton
Monday, December 15, 2003

Lately, I've been trying to do "The right things" like Joel suggests even when no one else will.

For instance for our latest release I wrote my own specs (we never have any) and kept them updated based on the requirements (hand written scratch, hallway meetings, phone conversations, emails).

I also spent some extra time thinking of architecture and the best way of implementing the changes for the release. (Most of my fellow programmers just sit down and code with no design). I also created UML diagrams to understand better what the projects are really doing.

Overall, I feel a lot better about the project. My code is cleaner & generic. The docs I created have helped me remember exactly what we have done and why!!!!

GenX'er
Monday, December 15, 2003

Baby steps. Make short term goals and focus on them. Don't worry about things until you have to.

"If you fail to plan, you plan to fail."

Wade Winningham
Monday, December 15, 2003

In this situation one encouraging strategy is to get a slice of the system working from end to end, and then add features onto it.

This helps both you and those over you. You get to demo the working slice (UI to data storage) to your 'superiors'. Your superiors get to see that progress is really being made, and that you aren't just a stick in the mud who is unwilling to do anything other than proclaim doom and despair :-)

Scot Doyle
Monday, December 15, 2003

I'll second Andrew's thought that what you believe will happen, will happen.

There are quite a few stories along the lines of "we had an impossible deadline, and I never thought we'd make it, but we did!" (generally accompanied by essays on team motivation and project management)

The *important* thing for project management to do is go back to the CEO and ask how important the dead line is, and is he willing to commit the resources necessary to make it?

Remember, you can only have two:
- Fast
- Good
- Cheap

If the company is willing to commit what's necessary to maintain team morale, then often what seems impossible may just be doable.

Most importantly, deadlines may turn out to be flexible, providing the stakeholder is happy with what he sees. In other words, do your best to make it, do your job well and show progress. Then if you speed past the deadline at 90mph, don't worry about it - just get it done.

Philo

Philo
Monday, December 15, 2003

That has happened me before, I think I won't even get this done in a few weeks. I half panic, then get down and dirty and just start, now just sometimes, at the end of the day you'll think about all that you have done, and think about how you never thought you could do that in a week, and it works and everything (tm).

I'll wish that on you, and if it doesn't work out, sorry for giving you any hope, ha.

fw
Monday, December 15, 2003

Following up on Philo's comment. Figure out if you are really feature driven or schedule driven. If you ask the boss, it's probably both, so ignore him. I assume for your sake, there is a minimum level of quality.

If it's really schedule driven figure out which features are going to get cut and put minimum effort into them. If it's feature driven, work out your own, private schedule and work to it.

There is some wiggle room if resources are added or removed, but this doesn't have that much an affect, in my experiance.

pdq
Monday, December 15, 2003

I think I'll have to agree with the two recurring themes here:

1. If you assume you're doomed, you're doomed. If you don't assume you're doomed, you'll accomplish more. Give it a try and see what you get done. I'm not quite with those who think this could work. I trust your judgment that you're doomed. But there's near miss failure, and there's miserable, utter defeat failure. If you shoot for success, you'll get closer to a near miss.

2. Do your little corner of the world the best you can, and just trust that that will make some small difference in the overall effort.

To those, I'll add: do a model (I'm a UML geek, so I prefere a UML model), and derive an estimate from that. Take the time to do the estimate right. This will let you know just how doomed you are; and maybe, if you're lucky, it will let you find a minimum subset you can actually succeed at.

Finally, remember the good-money-after-bad school of management. When you miss the deadline, they're going to scream; but there's some window after that where they'll keep pushing, before they finally give up and cancel the project. THAT is your real deadline. Sure, you'd like to meet the deadline that won't have them screaming; but that's out of your control. You know today that at a certain date in the future, they're going to scream. Accept that, be ready for it, and try not to let it stop your real progress.

I don't envy you. But then again, I've been there so many times, I'm a bit callused about it to.

Martin L. Shoemaker
Monday, December 15, 2003

Divide and conquer - simple.

Realist
Tuesday, December 16, 2003

I second the "get a simple working system and add features to it" point.

Do iterative development. At any given point in time, (after the first 3 weeks or so), have --something-- ready to ship.

That way, when you hit the deadline, you can say "I have a working system and it does foobar and fizzball and goofinkle, but not wawa."

Your boss is much more likely to accept that than "I'm still coding. I might have something in a couple months", or, the more likely "Well, I just finished coding and I haven't tested it ... I suppose we could move that into operational use."

BEWARE those last two quotes.

Oh, that reminds me: Test as you go. Don't do testing at the end. Write test cases before you write code. automate them if you can.

good luck!

Matt H.
Tuesday, December 16, 2003

Thanks to everyone for the responses. I'll summarize what I am hearing:

- Attitude is everything. I agree, and know motivation comes with the right attitude. But the question is how to get a positive attitude. Read on....

- People can get pissed off, but when push comes to shove they will often give you more time. Well, what I wanted to do was prevent the unpleasantness of dealing with pissed off people. But that's not likely to happen, and it's not under my control. What _is_ under my control is what I can do to mitigate the "disaster". I can make the project successful at *some* level by the deadline, and then go hat in hand and ask for more time to finish it. I can also make an effort to make sure that my part smells like roses, even if the rest smells like fresh fecal matter.

- Schedule vs. feature driven. I know from past experience that we are 60% schedule-driven, 20% feature-driven and 20% quality-driven. (Roughly.) I'll do my best to steer development according to this.

- We're doing iterative, test-driven development. Once the deadline looms, we should be able (within one or two iterations) to do final documentation, cleanup, testing and packaging. And then ask for more time.

Thanks again for the helpful responses!

(Not quite so) Doomed

Doomed
Tuesday, December 16, 2003

"In this situation one encouraging strategy is to get a slice of the system working from end to end, and then add features onto it.

This helps both you and those over you. You get to demo the working slice (UI to data storage) to your 'superiors'."

Depending on who's in charge of the project, demoing this seemingly working system can backfire in that it may cause your 'superiors' to believe that you've almost got the whole project finished and all that remains are the last few finishing touches. So, be careful! It's still a good idea to develop the system this way, but depending on who's running the show, you may want to opt out of actually demoing it for your 'superiors' and demonstrate your progress by some other means. For example, you could print out your source code to show that you've done something and when they ask how much longer it will take to finish you can indicate how much thicker the stack of paper will be when the code is done. At the very least, if you are going to demo it for non-programmers you need to make it crystal clear that this is just a preliminary stick figure sketch and you have a long, long way to go before it becomes a Mona Lisa.

Are we there yet? Are we there yet? Are we there yet?
Wednesday, December 17, 2003