Slashdot Mirror
Smart Software Development on Impossible Schedules
Andrew Stellman writes "Jennifer Greene and I have an article in the new issue of Dr. Dobb's Journal called "Quick-Kill Project Management: How to do smart software development even when facing impossible schedules." We got a lot of great feedback from our last article on open source development, but there were a bunch of people who wanted to know whether it was really feasible to do planning and reviews on a tight schedule. That's a fair question, and this article is meant to be an answer to it. We pulled out bare-bones project management practices that will help you protect your project from the most common and serious problems, and gave instructions and advice for implementing them that should work in a real-life, high-pressure programming situation."
"Smart ... on an Impossible Schedule" is just management/corporate speak for "How to minimize the crapiness of a project when we know we can't spend the proper time required." You can dress it up all you like with sleak catch-phrases, and call it a rose if you want, but it still stinks.
The appropriate response to any of these is "You should have proposed this project X months ago (where X is a conservative estimate."
Religion is a gateway psychosis. -- Dave Foley
Pick two. If you are so lucky.
A truly impossible schedule is by definition impossible to meet.
An extremely-difficult-but-possible schedule is by definition makeable if the correct resources are applied... correctly.
If management is giving you an impossible schedule, they are either idiots or setting you up to fail or both.
If they are giving you a difficult schedule and refusing you the resources you need, or do not have the authority to give you those resources, see above.
If they are giving you a difficult schedule and you haven't requested the necessary resources, then they are testing you and you've failed the test.
--
What do I mean by resources? I mean anything that can make the project go faster without sacrificing quality. This may mean additional manpower, the authority to say "no" to new feature requests, the authority to make feature cuts, or the reassignment or hiring of people with key skills to your project. It may also mean late-night pizza parties and family-support to the "code widows" until the project is complete. It can also mean additional or extended time off for the entire team after the project is shipped.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
2) Make sure you only work on things that you need to ship version 1.0 of that.
3) Make sure you keep the prototype running always.
4) Show Demos every few days to make sure noone is confused about what is going on.
5) Tell them they can ship it whenever they want, they write the check.
6) In the meantime, work towards the goallline like a football player, do not circle it like a lion waiting for it to die.
7) Don't make any project your time to show how clever, cute, or interesting you can be...
8) Keep Teams/Egos/Methods/Files/Modules/Projects/build times small. Small is good.
9) If someone is not clicking with the rest of the team:
- talk to them privately
- reassign them
- if this person is you, read #11, and consider if you want to build this project, or do something else. Follow your heart.
10) Do the riskiest part of the project first.
11) Remember that the enemy of the better is the best.
12) Don't worry about it. If you are working hard, and follow 1-11, you are doing your part.
That's enough to chew on. As homework, go build a paper mache model of the project, complete with testers whizzing around, filing bugs that are actually feature requests.
Seriously, doubling the time is NOT enough.
;-)
Top 12 - Rule of thumb says:
1) Triple the estimated time + 10%.
2) Add 2 weeks to that amount for a complete code review.
3) Any changes by the customer means "adding 2 weeks to the schedule", even if it's one line of code... why? because, it must pass documentation, Q.A., validation and be reviewed by the entire department, without accounting for "double bug", bug induced by another bug and stuff like that or bugs that are in the core library and means retesting "everything", "every module", etc.
4) Any changes must be approved, reviewed and means adding delay (normally a big NO-NO) and therefore, 99% of the case thoses changes are left for future phases or abandonned by the client when they realise the implication. If not, it's your objective to discourage them or force them to reconsider by any means. =P
5) Don't give any feedback to the customer unless you must! If you do, downgrade any progress to minimum to reduce expectation and refrain the customer from adding new stuff to the TODO list.
6) Which means, each phase must be clear, consise, humble, realistic, feasible, with lots of buffer time for fixes, reviews and testing. Exagerating how complicated it is to a customer is always a good idea, because in the end, everything that seems easy is actually very difficult.
7) Do minimum documentation, UML to get started... They'll get rewritten at least 30 times, before everyone in the group agrees after what 40 meetings?
8) Once the phase somehow works and the thing is somehow settle, start documenting it, so you don't forget. It's actually a very good way to detect logical mistakes, misbehaviors, bad coupling, bad cohesion, missing corner cases, bad design choices, usability problems, etc.
9) Best teamwork is small team of 3-5 senior people working toghether hand-in-hand, sometime helped by 1-2 junior, which can do much better than 120 junior who are completely clueless and never deliver on time...
10) For big projects split things up in component and/or phases that a small team of 3-5 people can do, keeping in mind of the big picture so its scales up, but ignoring any meaningless future details that don't matter "right now".
11) Rush the people to do it in "the simple 1/2 time delay", keeping in pocket the "double time" remaining for any arising issue and reworking the core libraries, overhaulin the code, reviews, fixing bugs, etc. This means that if you are really late, you are actually late on your "buffer time". If things goes well, then the project will be done before it's expected, which will impress any client.
12) Finally, but not the least, there's no such thing as a bug, it's just a "small improvement", a "new feature", "code overhaulin", "mispelled requirement" or a "security enhancement". It keeps customer smiling, it's less depressing for everyone and overall keeps the mood up on everyone face with a laugh or two!
Furthermore, no ones want to hear that the code is "full of bug", but saying that a group of people are always "enhancing, overhauling and improving the code base" also means bigger bonus! =)
Hope it saves you from any future project delay or cost overrun!
From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)
The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.
However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.
A few more gems in Peopleware:
- Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
- Overtime is only productive for one week.
- Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?
Peopleware is rather sobering. Every other page you think "wait - we're doing exactly what is being described here." The good news is that you can do something about it once you can recognize the signs.For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:
- Human task switching considered harmful
- Joel's test to identify bad software companies
As far as the TFA goes, once you've accepted an impossible schedule you're already hosed. If you can't push back, leave. The job market is good right now.If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):
Learn to use copy and paste
Nooo!
I wish I could beat with a crowbar all the cut-and-paste programmers who make my life difficult - I have to maintain the piles of repetitive crap code that they produced - they knew how to use Ctrl-C and Ctrl-V but could not or did not bother to do the most basic of programming taske: eliminate repetition by factoring code into meaningfully-named, paramterised procedures. This was best practice in 1970 already but so many people still don't get it.
My Karma: ran over your Dogma
StrawberryFrog
"...take the time to do things right...."
It's this notion that not going off and making a total ass over end cock up of a project, and "taking the time to do things right" that is really the problem with allot of developers, and managers attitude to software development.
The quickest way to get a project done is to do it right ONCE! Not five times badly. At developer meetings I've often heard managers or developers call UML and other methodologies a waste of time or unnecessary, it always flabbergasts me to hear such ignorance.
I've been in a situation where an (un)manager told me "We don't have the time to do document and do things the right way", my response was "No, we don't have the time not to do things the right way". We only had 6-8 months to get a large project out, with four programmers, a business analyst and two DBA's. I was told I wasn't to spend time in UML and documentation land, and you know what, I ignored him and spent 3-5 days creating high level class diagrams and interaction diagrams, the core of which lasted us through the entire project.
Any project that you forecast is going to take longer than 3 man weeks ie 120 hours needs some sort of design in place to ensure that the major architectural constructs are already decided before coding takes place.
The key to employing methodologies in projects successfully is unfortunately experience. It takes experience to use methodologies successfully, it takes experience to create good designs for applications and to judge when a design has become mature enough to allow development to commence without the risk of major refactoring later on in the project.
It does in fact take time to acquire this experience (years in fact), but it does not take time to employ this experience once it has been acquired. If you feel like your project needs some sort of methodologies in place, but "you don't have the time", the answer is simple, it's not that you don't have the time, you don't have the right personnel. It's true if you have no one with the experience of delivering the architecture required in a professional and timely manner then taking on methodologies new to everyone on the team is going to take time and lots of it. A good manager however will make sure that the project is correctly resourced.