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."
Printer friendly version (Score:5, Informative)
Re:Why do people buy into this nonsense? (Score:5, Informative)
Because that's all you can do (in general). Adding man-power to a late software project only makes it later, as was shown by Brooks [amazon.com] some 30 years ago.
Rapid Development: Taming Wild Software Schedules (Score:4, Informative)
Rapid Development: Taming Wild Software Schedules
by Steve C. McConnell
I'm in no way related to it, I just own it and I think every project director should have one. It contains a lot of ideas and hands-on tips you can immediately try on the field. The last section, named Best Practise, is a practical reference guide. There is also a chapter if you already are in a crazy project and want to rescue it.
Re:Techniques don't make up for a bad schedule! (Score:3, Informative)
wow you do code reviews? My last employer dropped those over 3 years ago to "speed up the process"
No such thing as a quick fix (Score:3, Informative)
Want some good (aka REAL) tips, check out Steve McConnel's book on Rapid Development [amazon.com] (Ignore the fact that it is produced by M$ press). This book is great, and if anyone is serious about software development they should read this book. And for the developers out there, please read his other book, Code Complete [amazon.com].
Re:Why do people buy into this nonsense? (Score:3, Informative)
There's a lot of truth in Brooks, but you have to take it in context. Adding manpower to a late project may indeed make it later, but adding more manpower up-front and managing it well can increase the capacity of your team to deliver a project, and therefore get the work done sooner. You get diminishing returns to an extent, of course.
Re:Smart? (Score:5, Informative)
In the first case, my company tried to break into the professional market (we were big in the education market) so we announced a major overhaul and several new new features. It was a fantastic vision but unfortunately the president made the mistake of announcing the full feature set and that we would start accepting purchase orders that summer. By the time spring rolled around it was clear that were were going to miss the deadline by several months (very bad when most of your sales are in September), but since the feature set was set in stone, we couldn't cut features. The writing was on the wall but we accepted it and started working 13 hour days nonstop for 6 months. Customer complaints over late orders flooded our phone lines and prevented our previous customers from calling tech support, so our old customers felt neglected and our new ones started cancelling orders. We gave up in christmas and released the complete but buggy product and got more complaints.
The president was replaced, and under his leadership we were able to finish the product we wanted to finish within a reasonable schedule. Depite all the doom and gloom earlier, we survived. Unfortunately, we lost the senior software engineer and another developer in the process.
Then, president hired a vice president which wanted to revamp the whole product and move it to an even higher market. I gave a detailed estimate that said it would take 2 years. The VP said we'd go bankrupt if we didn't release in 9 months. I repartitioned the estimate and said that we could do it in two stages, each 13 months long or three releases each 9.5 months long. No go. It had to all be done in one release, and that release could take no longer than 9 months or we might as well close up shop. I came close to losing my job over the issue, but since I was the most senior programmer there with the most experience about the product, the new senior software engineer told the VP if I went he'd have to give up too. 2 years later, after a complete turn over of the team twice (including the new senior programmer), the product was finally release It had more bugs than we'd like, but it was recieved well by the market so it was "good enough". At release time, I was the last person standing from the original team, but I had enough and left soon after. The product was well received but since the team was new, a new version of the product wasn't released into three years later.
All the VP's threats didn't change an impossible schedule. You can't squeeze 2 years of work in 9 months, not matter how you try to force it. If you try, the most you can do is destroy your team and lose sales in the process. Most of those doom and gloom professies don't pan out. If they *are* true, someone is running the company wrong and development schedules are the least of your problems.
In the later case, had the VP chosen either a more reasonable schedule (like any of the 3 I laid out above), we would have had most if not all of our original team at the end and been able to do subsequent releases at the same measured pace. We would have had regular sales and the company would have prospers much more.
Being a software architect or project manager is hard, but ultimately, the best ones just lay out out all the credible options on the line and stick to their guns, even if it means risking your job. My experience in that job showed me that you can do it even in a hostile environment. If you lay things out properly and tell the truth, you may be resented, but you will be respected, even by those who chose to ignore your advice.
Engineers survival kit. 3 solid tips. (Score:3, Informative)
If you want to continue to give your whole life to your comapny in the mistaken concept that you'll get recognition for it later then chances are you're still a naieve new grad. Experienced engineers know they have to train their managers.
After 25+ years of software development heere's what I learnt works best:
* Demand the necessary time to do good work, no matter what time problems that may cause others. Reason: You will actually need about the same time, no matter what quality concessions you make. Furthermore, your manager should have had involved you in his time-estimates for project planning. This is management 101. If he didn't then this is the only way you'll convince him to involve you next time.
* Don't ever agree to deliver low-quality product, regardless of other peoples deadlines. Reason: Non-techincal managers mistakenly believe that time can be saved by sacrificing quality. Actually the opposite is true. Low quality software takes more time overall. Furthermore, if you deliver crappy software, people will forever identify you as being a crappy engineer, regardless of any justifications you may have had at the time. If you're a crappy engineer you're like too many others and worth nothing.
* Don't work overtime unless you both want to and are being paid extra for it. Reason: Your employer is making significantly more money from your work than they are paying you. If they weren't, they wouldn't keep you there. Its basic business economics. They are not a charity and you deserve to be paid and treated just like any other professional. Furthermore, it does nobody any favors if you set urealistic norms and expectations. Yet another reason is that you are far more effective if you're not continually burned-out.
The BIG secret your company doesn't want you to know:
Nearly all deadlines are just artificial mechanisms created by management and designed solely to get free overtime/more productivity from the workforce. They usually have no relation to what delivery date was acutally agreed with the customer.