Useful Hints for Software Project Planning?

staaktdenarbeid asks: "Over my software-writing career, I noticed that development efficiency closely follows the 80/20-rule. That is, 80% of the progress is made during 20% of the time. The rest of the time, er ...well you are waiting for the next big idea. No matter how well planned a project is, it turns out that true progress is only made at very few points over the entire project lifetime. I would like to ask other Slashdot developers for their experiences, and if they know (and apply) project planning techniques that create a smoother development path."

Comments

Is it a problem ?

[RyoSaeba]

Is that rule a problem for you ? I mean, does it cause you unneeded stress ? Are you concerned about spending 80% of your time doing those 20% ? If not, maybe you can just stick to your current habit ^_^
That said, I don't have maaaany years in software development, but i think even when you are not coding like a crazy your mind is idling working stuff out, getting ready for that biiiiiig flash-bulb that's gonna make the next big advancement. So it isn't exactly lost time, right ?

Apart that, I'll just point out the regular stuff others here will prolly detail a lot more:
* know as much as possible the final result you want, and deduce how to make it from that
* if working with others (your post doesn't mention in either way), try to brainstorm together, and dispatch work to each depending on skills / interest / CPU/brain occupation, and so on
* if not actively coding, maybe browse idly the code from time to time. I have sometimes be surprised, doing just that, to realize how dumb something in the code was, or a bug no one has noticed before. Again, brain working in background manner ^_-

Ho, and let's not forget...

[RyoSaeba]

if idling, use your time to comment the code a lot, it may help in the future, and forces you to think about your program design / flow

hyperthreading for people? ;)

[Anonymous Coward]

stop banging your head against the wall! if you always keep a few (3 or more) threads running at any one time, you can keep those big ideas coming, without feeling the urge to bludge.

working on _something else_ is the most useful kind of bludging there is!

it's not 100% efficient, but i've definitely double the "big idea" rate by always working on 3 or 4 reasonably different projects...

Simple advice... read books

[Jouni]

In this day of constant deadlines and lighting-fast Internet, few people stop to seriously study what they are doing. You have stopped, at least for long enough to ask about this on SlashDot.

There are plenty of good books on software project management out there, from Peopleware to Extreme Programming eXplained and from The Psychology of Computer Programming to The Mythical Man Month.

I use a simple rule of thumb for every book I read; if the ~12 hours spent on the book is not going to pay itself back in time savings in the next 12 months of my life, it's not worth reading. However, I can safely say that any one of these books should have enough to save you at least one working day in your year.

The worst excuse for not reading is that you don't have time. All of us have equal amount of time allocated, it's up to you to choose how you spend it.

Wanting to learn software project management is a good start, now hit the books, then apply your learning to real life. Ideas can be summarized in books and Internet posts, experience you have to get for yourself.

Jouni

Arbitrary clerical deadlines RULE

[swillden]

Most developers I know, including me, are most productive when under pressure (a large number of us have strong symptoms of adult ADD). When the deadline is far away and there appears to be plenty of time to reach it, we tend to dawdle, surf, read slashdot and generally get easily distracted from the job at hand (like, er, now -- oh, wait, my deadline is today! Okay, one post...)

Years ago I was frequently pissed off by the obviously completely arbitrary deadlines that were imposed upon me. I could tell that this "absolute drop-dead date" that was being forced on me wasn't important at all, and that the *real* deadline was some days or weeks later. It pissed me off that I was being pushed to get finished long before it would really matter. A buddy and I took to calling these dates "arbitrary clerical deadlines" (ACDs), implying they were defined by some secretary who knew nothing about what we were doing or what was needed.

Then I was enlightened.

After ignoring several arbitrary clerical deadlines and finding myself up against the real, market-driven deadlines, and after seeing my company suffer significantly when I *missed* the real deadlines, I began to understand that arbitrary clerical deadlines are a Good Thing, and that the managers that were pushing them on me were Wiser Than I, even if they couldn't code their way out of a paper bag.

ACDs apply the pressure required to keep us focused and provide a buffer of time between the established finish date and the real deadline (for when unexpected problems arise). Not all programmers require this, but, IME, most do.

So now I try to take ACDs one step further, setting even shorter-term goals than the ones that are assigned to me and trying to pressure myself to meet them. It doesn't always work, and I envy the few developers I know who are able to work slow and steady and always have their modules done on time, but it helps tremendously.

Rule #1

[Dr. Bent]

"Plan to throw one away"

The first version of whatever you write will be worthless, and probably require a lot of re-writing before it becomes production quality. This is unavoidable, no matter how much you plan and design in the early stages. So just accept the fact that the first version is really just a fact finding mission and plan accordingly.

Re:Rule #1

[splattertrousers]

The first version of whatever you write will be worthless, and probably require a lot of re-writing before it becomes production quality.

So will the second version, and the third, and the fourth... In my experience, any code that isn't re-written often gets crufty and becomes increasingly worthless.

The more the code gets rewritten (a.k.a. refactored), the better it gets. Hmmm... so, what if you were to refactor it often? Very often? Extremely often?

The "Do what you have to do" rule

[reuel]

I learned a good rule from my manager at HP many years ago: First, do what you know you have to do.

Let me explain: When a new project starts, those involved will come up with all kinds of technical problems to be addressed. Some of these may even seem like show-stoppers. Upper management will want these problems to be solved before allowing the project to move forward.

Project managers and engineers have 2 choices: put the project on hold and work on solutions to the problems, or put the problems on hold and get a prototype of the project working. We all know what happens when you put the project on hold: nothing. If you go ahead and do what you know you have to do to get the prototype working, miracles occur! Many of the so-called problems turn out not to be problems at all. Or some clever engineer just solves the problem while working on the prototype. Or new problems, much worse than the original ones, are found and can be addressed now that they're known.

Which kind of project do you want to be working on?

Re:Developers have Attention-Deficit Disorder?

[swillden]

You mean the people you know that are developers tend to have ADD?

No, I mean I suspect it's a widespread trait among developers, particularly the best ones. I've been working as a programmer for a dozen years and the last six of those as a consultant, so I've worked in literally dozens of development shops and with many, many developers. Once I knew the symptoms of adult ADD, I began to recognize them all around me.

You don't mean this as a general rule? ADD people shouldn't be the kind gravitating to sitting still on chairs for long hours?

I think programming is an excellent job for adults with mild to moderate ADD, in fact I think ADD gives them a significant advantage.

Why? The flip side of ADD's scattered focus, particularly in adults, is the ability to "hyperfocus"; to focus your mind completely on a single, intensely immersive task for hours and hours on end, in a way that "normal" people can't do. This is a huge advantage for a programmer because producing large quantities of bug-free code requires that you be able to build and maintain a mental representation of the program or module you're building. For code of any size or complexity this is a difficult task, and any distraction can bring the whole mental structure tumbling down.

So, I think that such people naturally gravitate to programming because they find they're damned good at it.

Note that I'm a professional programmer, not an MD or a psychologist; I have not been trained to diagnose ADD, and I could be completely up in the night. Regardless, I have educated myself on the subject and I'm convinced there's something to this.