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.
To me, the knowledge of this rule alone can cause some stress. You know "Yeah, I've got weeks to do this, but I can be pretty damn sure I won't be working very hard most of the time, and then have to stress like hell toward the end of the given time." And of course starting early just prolongs the unproductive period in the middle ...
Then on the other hand, I do think that there's still a point in the other 80% of time spent. Like you say, I feel like (or is it just hope?) there's some work going on that's required to get around to the next big productivity leap. Those 80% still seem necessary to, I don't know, sit through or whatever. But the knowledge does annoy me sometimes, oh yes!
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.
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
Have you ever tried it seriously? If not, you are falling into the trap of speaking in ignorance.
A few years ago, I would have said much the same thing. After giving pair programming a honest try, I write virtually all of my production code with a pair.
As a result of pair programming and Test Driven Design (TDD), we have been able to write a new embedded, real-time application for one of our systems in just a few months. IIRC: The number of bugs found in this application is 5, and 2 of those were compiler/tool related.
This is just the most recent application we've developed.
Don't knock it 'til you try it.
http://www.controlchaos.com, Home Page Good overview.