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)
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...
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
For every project I've done in my career I had a timesheet where I wrote what was beeing done that day. Well after reading this post I checked those timesheets and about 80% off the time I wrote "research and study"(being surfing around the net, walking around the office and reading ./). So you could say that those 80% of the time where it seems you're doing nothing are in fact the base of the 80% progress you'll do in that 20% short time period.
"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.
My favorite truth from these books comes from a chapter in Peopleware where team productivity was studied under several scenarios: where a manager plans the schedule, where the programmer plans the schedule, where a third party plans the schedule, or where there is no planned schedule. Not surprisingly, the manager created the poorest schedule with the lowest productivity. The programmer, however, wasn't far ahead. The third party did slightly better. But by far the best performance was from teams where absolutely no schedule was done.
In software, you're best off without schedules at all! I follow this in my own software planning; if at all possible, which means if people above don't push it, I have no schedule or plan. I do the design and the work, and when it's done it's done.
Agile methods address this problem by keeping development
cycles very short. They also tend to foster short-term
thinking, but if you can avoid that trap, and keep your
team members as loosely coupled as possible, schedule-wise,
without losing effective communication and coordination,
having frequent (like 2 week) release cycles will flatten
out those humps and raise the mean productivity significantly.
So says my personal experience. Pundits may differ.
-I like my women like I like my tea: green-
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?
[place clever signature here]
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.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.