Smart Software Development on Impossible Schedules 225
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."
Tried and true (Score:4, Insightful)
Techniques don't make up for a bad schedule! (Score:5, Insightful)
In the real world, no amount of tips and tricks is going to make up for a bad schedule. We end up doing code reviews while are software is in verification and validation. Is that smart? No. But when you need to get features done, that takes priority. As for documentation, that always falls to the wayside as well. The truth of the matter is this. The only way to make schedule is to totally inflate your time estimates on the project. We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late ;)
http://religiousfreaks.com/ [religiousfreaks.com]Smart? (Score:5, Insightful)
Why do people buy into this nonsense? (Score:5, Insightful)
"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.
Good On Paper (Score:4, Insightful)
So yes, the article does make some good points, but they only go as far as the factors covered are under your control. Even in the best circumstances, a poor programmer or a less than perfect team lead can hamstring the whole team. In the end, I think that the only benefit that articles like these have is to make you really think about process. Process might not save you in the end, but at least going through the effort should make you a better developer.
Getting back on track (Score:5, Insightful)
Step 1: Admit being late as early as you can. If people start ranting, keep cool. Tell them that ranting won't fix it. The sooner you admit to being late, the sooner you can stop screwing around and start getting the project back on track.
Step 2: Help management prioritise what they want and what can be delivered when and what options are available. If they want a product to sell, they'll need to make some compromises.
Re:Techniques don't make up for a bad schedule! (Score:5, Insightful)
Re:Smart? (Score:5, Insightful)
The appropriate response to any of these is "You should have proposed this project X months ago (where X is a conservative estimate."
Re:Why do people buy into this nonsense? (Score:4, Insightful)
Done regularly actually. The big difference is that the impossible schedule dramatically increases costs (heating in winter for year-round construction, running three crews in shifts for 24/7 construction), etc.
For some reason "Impossible Schedule" in software development means cutting corners instead of increasing manpower.
Re:Getting back on track (Score:3, Insightful)
Next time will be worse (Score:3, Insightful)
Re:Why do people buy into this nonsense? (Score:3, Insightful)
Because software is something of a virtual product, people think that is very easy to make changes along the way. You wouldn't see an architect or a civil engineer accept fundamental changes to the design: "Oh how about moving the elevator shafts to the side and making space for a swimming pool on the 10th floor?"
Re:You can explote your coders better by... (Score:3, Insightful)
fast, cheap, well done (Score:5, Insightful)
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.
Re:Code reviews (Score:3, Insightful)
Aye here. I've experienced this a number of times and started thinking about it. Generalizing a bit, most developers who like to do code reviews, like to do all sorts of things throughout a week (set up a build system, do some design, code a module, do some testing). However, these are exactly the same developers who often have trouble with the nitty-gritty details.
Code reviews should be done by developers who hate code reviews, and should be concentrated on the meaning of the code and what could be missing.
Coworker doing a review: "Hm, this function looks a bit big, maybe you should split it."
Me: "OK, good idea. But do you think these 500 lines cover the problem, or have I missed something?"
Coworker: "Umm, it looks OK".
Me: "Well, maybe you should give it some thought?"
Coworker: "I have, and it looks OK. Hey, you have some duplication here."
Et cetera.
12 Rules (Score:5, Insightful)
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.
double time ain't enough. (Score:5, Insightful)
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!
That's funny, but... (Score:4, Insightful)
I think that the most important thing to do when a project is on an insane schedule is realize that you aren't super-human and pace yourself. If you don't, and crunch hard nights or extra-long 50-hour sessions, you'll spend the next few days with a fried brain and a complete inability to make use of your time.
If you're normally a 9-5 guy, pull 10 hour days. If you're normally longer, possibly consider working longer, but notice when you've started lagging because of fatigue.
Other things:
And my build is done...
too idealistic: it's the same old sw management (Score:3, Insightful)
However, the article appears to be far too idealistic.
1) The only good schedule is a realistic schedule. If the schedule is intentionally compressed, it's a bad schedule. The only way to compress your schedule is to cut work (e.g. features).
1.5) Working under the "hurry hurry hurry" "boss wants it yesterday" environment means your engineers will cut corners everywhere. When faced with a choice to copy/paste a function in 15 minutes vs. taking some time to refactor and reuse the code in 1 hour, engineers will choose the earlier. In my experience, design debt then accumulates really fast.
2) Code reviews as suggested in the article are a drag (2.5 hours at a time?!). In my experience, they rarely get anything useful done: it's usually too late to make medium or major changes and under the gun (see 1.5) engineers will scoff at "wasting time" with minor changes. From what I've seen, the code reviews serve mostly as a cover-your-ass mechanism for management.
Code reviews need to be short (30-45mins) and happen as soon as possible, while the original engineer has all of the reasoning and decisions in his head. Hot-on-the-heels code-reviews of bug fixes and feature check-ins (especially useful for bug fixes).
Perhaps the code reviews need to happen as the code is written (sometimes I ask my coworkers to show me their draft solutions). That's almost pair programming though. Unfortunately, that's not practiced at my job, and so I have no expereince with pair programming.
3) Estimates. What the article described seemed to be a basic process for doing the SWAGs and the engineering time estimates that we all "know and love." I fail to see the novelty in the proposed approach: it seems to be run of the mill waterfall stuff.
It's so easy to say "break down estimates into small tasks, so you can estimate well." However, I found it very difficult to do so effectively. Pardon the Rumsfeld flavor, but often we just don't know what we don't know: stumbling blocks occur, requirements drift or get "clarified", surprises abound. Pressuring developers to provide task breakdowns and estimates past their knowledge point can create a false sense of security (i.e. misleading task estimates). I've seen many such a small task breakdown become trash as the project progressed.
Often, to get a better idea of the remaining work and tasks, prototype work is required or some progress on key features.
I have no good answer for this problem, but my feeling is that it lies somewhere in the realm of being able to react quickly to change and reevaluate the project's progress. This is where things like smaller tasks and more frequent completion points of features seem to help. At that point, changing direction is easier because you have fewer concurrent unfinished tasks.
This is where the smaller tasks and frequent iterations of the XP fame seem to be a benefit. Unfortunately, many managers can't take the thought of not having a detailed per-small-task project plan in their MS Project window. So, in my unfortunate experience, such managers attempt XP-style iterations, but then quickly regress into more traditional long-term milestones. I've seen it happen time and again.
Re:Techniques don't make up for a bad schedule! (Score:4, Insightful)
In otherwords, the future value of 'doing it right' is lower than the immediate value of 'damn the torpedoes' and getting it done. (unfortunately)
Re:Smart? (Score:1, Insightful)
Re:Code reviews (Score:4, Insightful)
No charge for the clue.
Re:Smart? (Score:3, Insightful)
And then you: a) get fired.
And then you go compete with that company and bury them because they don't know how to schedule and, most likely, can't prioritize features because they never listen to their engineers.
Re:Smart? (Score:5, Insightful)
Do not lie to your customers when you make a quote for them just to get one contract. Be honest about everything. The most important customers are repeat customers, and you will be #1 on their list if you get them a quality product on time and on budget.
Losing one contract is no big loss, particularly when you know for a fact that your competition cannot possibly make the goals they're quoting. They will look like fools when they ask for time and budget extentions or fail to produce anything usable, and nobody likes to do business with a fool. As they say, people might not know the difference.
Certainly there will always be competition that lies to get the sale and customers that make poor decisions based on unrealistic quotes. Dishonest business and mismanagement are commonplace. That doesn't mean you should compromise your quality or ethics. That's called "professionalism". Customers worth doing business with appreciate that, and you will attract repeat business and new customers through word of mouth.
Quick-Kill Project Management (Score:3, Insightful)
1. Quick kill the managers who set the impossible schedules
2. Quick kill the developers who can't stay within a reasonable schedule
[Sarcasm off]
It's impossible to change the development time outside of the -10%/+10% margins. If your schedule is wrong you either have incompetent managers, incompetent developers or both. What ever you do, work overtime, drop in more developers or else, all you gain is a few percents.
Development time is IMO a rather static variable, the only thing which can improve this time is education. Yet education has to be done in advance before the project is even started. During the project there's no time for education while the knowledge should be available right from the start. The easiest solution is to always plan for a 25 - 30% education phase at the beginning of your project.
O. Wyss
The same lessons... (Score:2, Insightful)
Oh, and none of them come up with a cure to the problem, but insist that doing it their way is the cure.
Just say no (and more) (Score:5, Insightful)
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 [amazon.com]). 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 [joelonsoftware.com] on project management. A few highlights:
- Human task switching considered harmful [joelonsoftware.com]
- Joel's test to identify bad software companies [joelonsoftware.com]
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):
Re:That's funny, but... (Score:5, Insightful)
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.
Re:Smart? (Score:5, Insightful)
You will be on nobody's list if you give them realistic schedules.
On the contrary, in my experience companies tend to come back to you to ask you to clean up the mess made by the low bidding cowboys when they realise that you were just being honest with them. At this stage you can often get away with jacking up the rates too, as they have made that realisation that you get what you are willing to pay for.
Re:Why do people buy into this nonsense? (Score:1, Insightful)
Re:Why do people buy into this nonsense? (Score:2, Insightful)
In a business to business transaction there's little to protect a client from a bad development shop. Once you're in more than half-way on a project, there's little a client can do to stop the bleeding. Sure, you could have internally managed the project well from day one, but you chose the lowest bidder (or at least made a compromise). Do you halt development? Most software shops aren't to eager to pick up the pieces of a unfinished project. Also, a project that is late or over budget is often looked at better than a unfinished project. So you keep going, lying to yourself that 'outsourcing' (even domestically) is a good thing. The software shop, trying to meet a budget or perhaps just being unscrupulous, 'rounds the edges' realizing they've got they're client over a barrel. Sure, it tends not to foster long term relationships, but that's business*.
*the big company anomaly: if your company has pedigree, this often isn't even a problem
Re:Techniques don't make up for a bad schedule! (Score:4, Insightful)
Some companies works with a sick "problem bringer"/"problem solver" mantra. Removing feature to allow you developping beter code invariably put you in the "problem bringer" section and that is bad.
On the other hand, putting all the features = "(management) problem solver".
When the application crashes in production and the situation looks very bad for the manager, if you come with any way of cleaning the mess you are again a "problem solver".
Every time you remove a feature or refactor the code preventively, from a management perspective you move 1 step in the dark side of the force, so you must handle that with political gloves, not common sense ( i.e. use fear factor, find tactical advantage for your manager not to include a feature, sneak "cleaning" code into features your manager think are worth extra-time to be able to cut budget later on a refactoring,
A new word for managers' vocabulary (Score:5, Insightful)
I've taken development teams down into the Valley of Death and out the other side. It can be done. But there are consequences, and you're kidding yourself if you think you can avoid them.
The first consequences is that you can only do this once. If you're smart, you hire smart people. They know when you are ordering them to jump into a pile of shit. And if you're smart, you hire craftsmen, and craftsmen have pride. They resent being told to do that. What that means is that if the second time you try it, you end up losing all the people who can find a job easily -- in other words your most valuable employees.
Another word that should be in managers' vocabularies is investment. Developers create assets that produce future revenue and expenses. You want programmers working as hard as they possibly can, but not simply to get the job done. To get the job done right, which means producing something that generatesw more revenue and less expense. When you focus on just getting the job done, you end up with something that barely breaks even. That's the minimal criteria for "not failing", not the maximum possible success.
That's why I hate questions that start with "How hard would it be..." because they focus on the present, not the future. It should be "I think we can make X dollars a year; how much would it cost to support this feature, and would the amortized development costs be justified by the net revenue given the other things we could put our efforts into?" It's not as pithy as "How hard would it be...", but it covers the things managers should think about: the future impacts on revenues and expenses, the opportunity costs of the road not taken.
Re:Techniques don't make up for a bad schedule! (Score:5, Insightful)
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.
Can anyone really estimate accurately? (Score:5, Insightful)
It's interesting to look down this thread and see how many different rules of thumb are employed, apparently by quite experienced developers/managers.
It seems to me that we can make two reasonable assumptions based on this:
One might hypothesise, based on these assumptions, that any project plan that quotes hard figures up-front will be inaccurate most of the time, and without allowing a huge defensive overhead that inaccuracy will often be in the wrong direction.
Now, working from unreliable estimates is in no-one's interests. If a company overestimates by too much on a fixed-price contract, it risks being undercut by a more realistic competitor. If it underestimates, it will look bad when things over-run, its profits will fall, and its reputation will suffer as well.
So what conclusions can we draw from this?
Firstly, if we're looking for realistic management, the way to go is almost always some sort of time and materials contract, with floating deadlines based on when features are actually ready. This allows good developers to do their job properly, which in the long run will be more efficient, and it means that other groups such as sales, marketing and customer support can be kept informed and given realistic expectations.
Secondly, fixed-price contracts are only a good bet for a software development firm if it can include enough slack to be safe, without including so much that it can be undercut by more realistic competitors. The corollary, of course, is that if you're a client, you're almost inevitably going to be screwed by agreeing to a fixed-price contract, even without considering the lack of flexibility it entails.
It is a rare project indeed that truly requires hard deadlines. Smart clients and smart development shops will reach a more flexible arrangement, and come to respect each other for having realistic expectations and providing realistic updates as time goes on.
Re:Tried and true (Score:4, Insightful)
A couple of points:
- If you don't have a clear vision of what the software is suposed to do and how to get there, having people work 10h/week or 80h/week produces exactly the same result - you get nowhere - either the project is late and gets canned or what you deliver is not accepted because it doesn't match the expectations of the customer.
- Long hours => tired developers => a lot more bugs => much more time is needed to implement the same features => long hours. Unless long hours are restricted to a couple of days, the end result is a vicious circle where removing the extra bugs introduced by tired designers/developers ends up consuming more time than whatever extra time you got from those extra work work hours.
Making people work extra hours gives the appearence of getting more work done while reducing the actually amount of work that does get done. This is one of those management techniques that sites high up in the list of "Things that managers that have no sense of strategy do", right above measuring productivity by "lines of code written" instead of by "requirements features implemented".
Re:Techniques don't make up for a bad schedule! (Score:3, Insightful)
Starting a project without gathering requirements, scoping the project, hammering the list of business rules and doing a high-level design is a great way set the project up for getting out of control after a couple of months, even without the extra pressure.
Re:Techniques don't make up for a bad schedule! (Score:3, Insightful)
Unfortunately, from my experience, there seems to be both a lack of business analysts with the experience and ability to create a well-documented, internally consistent set of requirements and of senior designers/developers that actually figured out that the secret of speed in software design/development is to take some time of in the beginning for preparation.
And please, don't get me started on clueless managers
Sounds like engineering (Score:2, Insightful)
Intriguing--this sounds like what real engineers call engineering. Summarizing:
Re:Techniques don't make up for a bad schedule! (Score:3, Insightful)
An easier approach is to measure progress.
Divide your project into microfeatures, deliverable units of work that are either done or not done and take less than a week to build. Estimate each microfeature on a simple complexity scale (I like 1/2, 1, 2, 4; anything above 4 gets split into smaller features).
Then just start in developing and see how many units of work get done each week. Even a manager can see that if you got 5 units done each week this month, he should expect you to get 5 done each week in the future.
The advantage of this, besides the simplicity, is that you can then let the suits trade scope against schedule and you don't have to be involved. If they want the project done sooner, they should pull features out. If they want to add stuff, that means they're shifting the end date. Either way, the devs just keep popping features off the stack and making them work.
That's how I do it now, and I love it.