Slashdot Mirror
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."
I am a developer with similar experiences. but I am not 'waiting for the next big idea' but mainly, I am, uhm, surfing around, reading slashdot, until the pressure of the release date becomes high enough.
Then I start working hard, through the nights, and oh wonder, I have all the tables, primary keys, foreign keys, objects, constructors and destructors coming right out of my fingers.
Perhaps I use the time hanging around to 'plan' databases and software in my head.
P.S.: I am a web-developer.
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 ^_-
Tsuyoikoto ha taisetsu da ne, dakedo namida mo hitsuyousa (Strength is an important thing, but tears too are necessary)
the 80/20 rule is the deepest truth I have come across. 20% of the people have 80% of the brain cycles, 20% of the people commit 80% of the crime, 20% (techies) of employees contribute 80% of the company's output, 20% of statistics cover 80% of the cases where a statistic would be good, 20% of the people (not /.ers) have 80% of the sex. 20% of the 80/20 rules cover 80% of the general cases.
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
Tsuyoikoto ha taisetsu da ne, dakedo namida mo hitsuyousa (Strength is an important thing, but tears too are necessary)
This so called 20%, at least for me, is when I enter the state of flow. There are specific requirements to be met so that one can enter this state of mind, in which the person is very creative and time seems to go faster, among other things. Read this for more information on entering the state of flow.
I don't believe in dual programming, but you can get somewhat of the same effect by requiring that programmers get together and explain their code to everyone several times a week. Just high-level architecture stuff. Each programmer should spend 5 minutes.
When developing software the most dangerous part should come early on. You don't want to pull a Daikatana and not understand what's difficult until late in the development - that's what causes late releases. Because you want to understand what's difficult first you should prototype the application. Hardcode as much as you can, even if it's half-assed, and program the minimal you need to get something that a programmer can recognise as components that address the main problems.
Prototyping is part of "release early, release often". Shame is part of "release early, release often".
Rather than planning technica details start from the interface. If you've got a client, and they're not computer programmers, they won't be able to know their requirements (and whether they're feasible) until they see it in front of them. Get them to draw the interface on paper and how they think it should work - this will help them get in the right mindset about the application. Provide them with prototypes. It's all about trying to jog their memory.
Price on phases (prototype releases).
--Giving to trolls for the benefit of us all
"90% of all your coding work will never be used for anything".
It's a rule I found out after a few years in the coding business. Most of your work will go directly to the trashcan.
Companies you're working for go bankrupt before your code has been used, projects get cancelled, clients (or managers) change their minds all the time and you have to recode some parts 10 times.
Not to mention doing quick'n'dirty code to meet a deadline and then you're told "Oh, finally we didn't do the demo, we didn't have the time for it". And you can press the delete key and start recoding that part the right way (or sometimes you have to leave it that way and it will come back to haunt you later).
True warriors use the Klingon Google
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
Jouni Mannonen | Game Designer, Consultant
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
"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.