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.
Its human nature my friend, it human nature...
The lunatic is in my head
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)
Then you can adopt the old shift the milestones approach.
;)
It works for M$
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
damnit, that'd be 112=16*7, preview, preview . . .
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
I thought the rule as applied to programming was
:-)
The first 90% of the project takes the first 90% of the time.
The last 10% of the project takes the other 90% of the time.
Of course if you believe in the e or pi rules for
scheduling, this is over-optimistic
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]
- collect data that will improve the software code.
...
- rework the code.
- work on multiple things/ problems at the same time and apply a multi-threading development style.
- go out and interact with others to decide the next logical 'do what you have to do' step.
- relax and wait until stress level is high enough.
This list looks quite useful to me. For my own project (hardware simulation), it seems that the logical thing to do would be to go out and ask either a beta user or a fellow developer for early feedback.This includes reading books, surfing the web,
For example writing documentation, throw away/rewrite, use shorter development cycles and early releases.
This is when I'm productive. I'm excited about what I'm doing. I'm really into it. I don't know how to explain it otherwise. The funny thing is that I can go from one moment being totally unexcited and the next moment really wanting to work.
I work by myself at home on software for my own company, so I have no deadlines, except those imposed by my desire to eat.
There are sometimes (usually late at night) when I'm tremendously productive. Then other times, where I have to force myself to work.
The thing is, I don't know the magic that makes me "really on". And I do know that it is probably better for me *not* to be working when I'm not in that condition. I also think there is a limited amout of time you can be in that state; one must have downtime.
And of course, its probably true that I'm "really on" only about 20% of the time, but I have not kept track. That would be interesting to do... And also track how much time I spend working when I'm not interested.
http://www.controlchaos.com, Home Page Good overview.
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? Or?
Karma: Excellent (My Karma? I wish...:-( )
There's a bunch of stuff I do when trying to remain productive but without the immediate inspiration.
/., IRC, IM, dilbert, userfriendly etc. exist ?
- Refactor. Look at my work to date, and see if there are things I could improve without adding new features or changing the external behaviour. Refactoring steps should take a fairly short time - it usually takes me around 30 minutes to make a "normal" improvement. I often get a flash of inspiration during that time, so once I've finished the refactoring I have something new to move on to.
- I believe very strongly in using test driven design (there's a book by Kent Beck on the topic which I recommend). When I'm stuck, I like to create additional unit tests for functionality I know I'm going to be implementing in the next day or so. Doing so exposes new ideas and insights, usually enough to get me back to coding the business functionality. You could argue that test driven development is a very strong antidote for the malaise you describe because it forces you, the programmer, to create many micro-tasks (unit tests) and complete them several times every day.
- Browse the books that seem to inspire me to write better solutions : Design Patterns (Gamma, Helm, Vlissides, Johnson), Agile Software Development (Robert Martin). Usually I recognize something appropriate to my current project, and get inspired to improve it...
- Code reviews : get someone to review my code, review someone else's code. Fresh eyes, new ideas, the joy of communication....It's really easy to get bogged down in the detail of my current project. I like being able to look over the parapet and remind myself of the bigger picture, but in the most concrete way - by looking at the code.
- Hey, why else does
It's all very well in practice, but it will never work in theory.
As a programmer, I know what you mean. But I don't think it's unique to programming.
Take photography, for example. How many photographs does a professional photographer publish a week/month/year? Far less than the number of exposures he makes -- probably far less than 20% of that, even. Ansel Adams, I believe, once said that the most valuable tool in his darkroom was the trash can. Writing a lot of code is great, especially if it means you get better at knowing what to ship and what to trash.
This is one reason why I like open-source. If I feel I'm not being productive with my program, I can go find some other program that's interesting to me and hack on that for a while. Perhaps somebody will return the favor. I think it was Alan Kay or Bill Joy who said something like, "the best innovation happens elsewhere!"
The sooner you get behind, the more time you have to catch up. A motto to live by!
Faster, better, cheaper; pick any two.
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.
Yeah, progress only happens when the boss is not sticking his/her ignorant capricous fingers into the pie.