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."
I was kind of suprised to see the recommendation for formal code reviews. In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments. I feel that pair programming is more effective way of getting multiple eyes on the code, spreading knowledge around, training the new guys, and all that good stuff.
And of course there's always static analysis to catch any problems that do manage to sneak in there...
The Army reading list
-- this little line has helped me throttle down a lot of rants over the years.
Do not mock my vision of impractical footwear
We would take the estimates, double them and add 30%, that is how I bid out all work. Now... The challenge is when you, the lead developer do not control you schedule and you are having meetings twice daily to discuss the progress. In that situation, well, it doesn't matter what the WBS says, or whether or not there is a code review, it matters that the features get done. Granted that is the anomolay for me, when it does happen, the goal is to get done and get out as quickly as I can.
Is that the norm or the anomolay for others.
Mod parent Insightfull.
I think the prime difference is that buildings have a much greater lifespan than software, so it's alot easier to justify the increased cost of a building.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
Of course you're running late.
Let me guess - you're a young pup. It's always been the same, since the dawn of history. Every generation laments that succceeding generation has to make the same mistakes, and learn the same lessons, over and over again.
IBM solved this estimation problem back when dinosaurs roamed the earth, virtually all computers were made by IBM, and they came with a "free" (as in beer) systems engineer.
IBM's solution was that every level of management that had to review an engieer's estimate would triple the estimate of the person who reported to (almost invariably) him. So, if the estimate required two levels of managerial approval, the quote to the client was 9 times what the engineers figured it should be. If three levels of approval were needed, the official estimate was 27 times what the engineers came up with. Now you know how IBM was able to afford that "free" systems engineer with every computer.
Actually, there are ways to drasticly increase the likelihood of success on "mission impossible" projects. I successfully led an EDI implementation project where there was no spec, no data, no customer, no access to the computers, the programming had to be done in an obscure language, and there was an arbitrarily set deadline of three weeks. Sometimes you take on such projects because you want to stretch yourself. But that's a story for another day.
The appropriate response to any of these is "You should have proposed this project X months ago (where X is a conservative estimate."
And then you:
a) get fired.
b) get yelled at by your boss for making his company seem slow and incompetent.
c) lose the contract to that company that lies and says they can do it faster than your accurate estimate.
d) all of the above.
I was asked to create a fully dynamic, CMS backed website in 3.5 days, using ASP.Net just the other day. This was because the Marketing department had forgotten to involve me in the launch of their new spin. I managed it by working long hours, robbing code from other projects and working at a furious pace. There was no time to plan, I just had to spill out ideas on the fly. Sound familiar?
... and the amount of times I have been told, "it's just a few buttons, surely you can manage that!"
I went on vacation, returned after 3 weeks and nobody had used the CMS to populate the site with data and graphics. In fact, the Marketing department complained that I had not given them more time to decide what they wanted. I was blamed for holding the project up.
A lot of people out there think that coding is very simple, a bit like waving a magic wand. Oh
Now where's my wand gone?
I can't stress this one enough!
As architect of a small software company, the most frustrating aspect of designing software is the knowledge and understanding that there's no way to know how to do it right until you deliver something that's wrong. People almost never seem to know what they need, but they do know that whatever they have isn't it, and they'll tell you why.
So, we have a very different tack, similar to Agile Programming. When we implement a new feature or functionality tidbit, we release very early - pretty much as soon as it more or less works without major errors, - with as much fanfare as we can manage on the cheap, and then wait for the feedback.
We're very up front about it, and openly welcome the feedback and ideas. This takes any conflict out of the relationship and turns it into a sort of partnership. Customers love being listened to, and feedback we get, in droves. When a customer sees THEIR idea implemented a week or two after they suggest it, even when it's something stupid-simple (such as having a particular button selected by default to avoid a common mouse-click) then they're your advocate for life!
It's that continuous, iterative cycle that's resulted in our young, 3-year-old codebase having eye-popping features, and remarkable stability. The software updates itself at the client's discretion, so nobody seems to mind much. They update as often as they like.
With this model, there is no due date. It takes me about 15 minutes to issue a release of our software. The idea of a "release" means almost nothing - we've done more than one in a day! (we've released 46 official releases in the past year alone, with too many "unofficial" releases to count)
Faced with this "impossible" situation, (I've lived "impossible" schedules for years now) I'd step UP the release cycle and start pre-annuoncing alphas/betas of the product the instant that something that appears demonstrable compiles and can be stuck on a dev server someplace. Invite comments and download. Call people to ask about feature X or Y. Let them know it's really early, and make sure that they have a place to bitch about the problems they find.
When you do, you'll be surprised how much of what you thought was required was, in fact, completely un-necessary - or at least could be put off until next March for a future release. But, you'll find some simple, straightforward ABSOLUTELY GOTTA HAVE that takes a man-month to code that the users would sacrifice their firstborn to have.
Agile software methods will find this "gotta have" pretty quickly. The waterfall model of software development would take a decade.
You decide.
This model won't work for all products and/or markets. And it's very important not to take away functionality that the customer previously had, or they get the feeling that you're taking something away, and that's bad. But for us, it's been very, very successful, and the relationship we have with our clientelle is very friendly, close and intimate.
PS: Maybe it helps that we're an ASP.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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
Zark's singing fish, yes.
Even more annoying, though, is trying to fix a C&P programmer's mess and then being told to - and I quote - "just copy and paste, we don't have time to over-engineer it," not by management, but by the lead developer.
I am a rebel, a guerilla programmer, fighting to change the company from the inside...
Next task: getting them to accept that version control is a good idea.
1. Stop agreeing to customer deadlines before asking the engineers how long it's going to take/if it's possible.
I've had many, many instances where someone asked me how long something would take, and I told them that there's really no good way to do what they're talking about so at least a month or two. It was only after this that I was told that they had already agreed to 2-3 weeks, so I'd better "figure out a way". But what if there is no way? It's not like 9 women can have a baby in 1 month, you know.
stuff |
Those are very good rules.
Very good indeed. Did you collect these yourself? If so, do you want a job?
I'll add a few more of my own rules:
- Make sure you're in total control of your toolset and improve it systematically
- Do not take the clients' deadlines literally - first accept the project, then renegotiate the deadline.
- Don't implement anything that is not going to be used immediately.
- Design your software around interfaces so you can make massive changes cheaply.
- Document the interfaces perfectly, but don't document code (see next point).
- Be fanatical about the readability of code.
- Push all QC, packaging, and issue management through a single person.
- Build regression testing into the build process.
- When debugging a problem, never ask, "how come it works on my box?"
- If some code is too complex to understand on a Monday morning before coffee, redesign it.
- Never add new code while there are still bugs in the existing code.
My blog
There is a fundamental problem with planning innovation (doing something you or others did not do before):
Because you are doing something new, you cannot predict in front how much time you need as you don't know the problems you will encounter and the additional requirements/features that pop up during development (this always happens in software or system development).
PS. I am talking about real innovation. Most real innovations are build upon existing ones. So this holds only is you maximize sharing or re-use of existing systems, and not repeating your same trick over and over again. I will even go so far as saying: if you did a good planning your development is problably not very efficient.
A good way to avoid pissing matches over brace indentation and other nits is to lay down a qualification checklist that must be clean before a review. It can be simple of extensive depending on your field. What slows the review process is a moving quality target that varies with reviewers. A checklist helps prevent that. Pair programming is a drastic waste of programmer time. What you typically get is an alpha who overwhelms and neutralizes the work of his partner.
an ill wind that blows no good
Only that it does not really work. Overworked programmers are tired programmers who make more mistakes. Long ago, research has shown that the best productivity is reached with a 40 hour week.
For details, see http://www.igda.org/articles/erobinson_crunch.php
C - the footgun of programming languages
I don't think this is possible given U.S. corporate practices or the market for software. My day job talked about trying to shoot for long-term success, but of course they're still fighting short-term fires (layoff when a customer has a bad quarter, stage releases to get something barely working out the door, keep cutting test time, etc.) Don't know whether they were really going to do it and failed, or whether they were just telling the engineers what they wanted to hear.
Since neither your company or your customers can think long-term, your company will just lose all of its business if it tries to do things right. Of course, there may be customers out there that both demand quality software and are willing to pay more and/or wait for it. I'd love to see some examples.
I agree with the value of code reviews, but there's no way you're going to get developers together for 2.5 hour meetings on a regular basis! This is EXACTLY why we no longer have a policy for review meetings. We're using a tool now, Code Collaborator - http://www.codecollab.com/ and it's pretty spiffy. I think probably the most time I've spent on any one review was 30 minutes. We also trialed a couple other code review applications, but they all could be improved, to make doing code reviews easy. Does anyone know of a feature by feature analysis of the code review applications that are available, and what SCM systems they support (we use Perforce)?
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.
I agree completely that one should spend time making sure the design is right. But I disagree that it should all happen before starting coding. You will never know less than at the beginning of the project. Improving the design should be a continuous process; then you get to take advantage of new information. Including information on how well your previous design theories are working out in practice.
I can spot a deathmarch project from the next county, and they *ALL* begin with phrases like "The market window for this product is..." or "We have to complete this by XXX or we all die" or my favorite, "My research shows every month we don't have capability X we loose Y dollars."
I don't have a problem with that, really. The trick is to only give the suits levers you want them to pull. The deal I make with my clients is that I control the estimates and they control the scope. I estimate each feature; they decide what order to do them in and when they want to release. Then the dates are their problem.
Once you break them in, they like it fine. It's just like going shopping: you put more in your cart, and you pay more at the checkout. Want a smaller bill? You put less in your cart.