Useful Hints for Software Project Planning? 60
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."
simmilar thing at me (Score:4, Interesting)
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.
Re:simmilar thing at me (Score:1)
I am constantly revising things like dbases when I realize new needs, or think of a good way to handle something.
I don't think this is a bad practice. When I sit down to write some code, I am very prepared. I'll just sit, and output. The thinking has largely been done.
Re:simmilar thing at me (Score:2)
However, I agree that the preparation time is best done up front. Just because code isn't being produced doesn't mean that progress isn't being made. I have trouble getting my management to realize that also. The get really nit-picky about somethings, but certainly don't object to me thinking of an idea on my own time and using it.
16x7 (Score:1)
Its.. (Score:1)
Is it a problem ? (Score:5, Insightful)
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... (Score:4, Insightful)
Re:Is it a problem ? (Score:4, Interesting)
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!
the 80/20 rule (Score:5, Funny)
Re:the 80/20 rule (Score:1)
Shoot the Boss ! (Score:1, Funny)
It works for M$
hyperthreading for people? ;) (Score:3, Insightful)
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...
Creativity (Score:4, Interesting)
Ideas (Score:4, Informative)
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).
Re:Ideas (Score:4, Interesting)
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.
Re:Ideas (Score:1)
Re:Ideas (Score:2)
With all due respect, why do XP evangelists always assume that those of us who disagree with their golden rules either have never tried them or have failed to understand or appreciate them?
There are plenty of good, experienced programmers who have experimented with various aspects of XP, including the big ones of pair programming and a test-first process, and have found them to be inappropriate or ineffective for them. If they work for you, that's great and I'll be the last person to tell you you should do anything else, but that's you, not me.
Personally, I can see the merit in these approaches, but I don't hold them on a pedestal as some sort of panacea. I reckon my programming matches the 80%/20% pattern pretty well. In my particular circumstances, when I get hung up on something, it's usually because I'm not aware of a relevant detail in how our software works, being a relatively new member of the team. Speaking to someone more experienced to find the missing link, or bouncing an idea off another team member to see where they instinctively see it going, is often a way to get clear of the 80% and back into the 20% again for me, right now. Given how naturally our group works together anyway, I could see pair programming potentially working out.
On the other hand, we have a very effective lightweight process going on, which is based on an initial proposal for a feature, followed by a very iterative design and implementation phase, with automated tests. I wouldn't swap that for a test-first process given any choice in the matter, because I've tried both, and found the latter lacks the power to work well in my development areas. If it works for you, that's great, please use it, but don't assume that it would work for everyone else just as well...
Re:Ideas (Score:1)
I'm not going to tell you that XP in general (and pair programming in particular) will work for everyone. I can say from experience, that it has worked for me... after an overwhelmingly negative initial reaction.
Did 'King of the World' give pair programming an serious attempt. I have no idea. I wouldn't call sitting bored with another programmer for a half a day and then saying that you don't like it a serious try...
BTW: I wouldn't introduce pair programming as the first 'XP' practice. I'd introduce Test Driven Design first. It works better in isolation and it has a faster payoff.
Re:Ideas (Score:2)
I think that instead of formally using XP, a better strategy to take is paired offices or physical workgroups. At my office, we have 8 month - 14 month projects, and when we begin a project, we move all of the design level programmers (about 6 usually) to a centrally located part of the office. We have a large white board and a large shared table. I often will have somebody sit next to me while I am coding, but we don't have these formal XP sessions. We tried following the rules strictly, and it just felt wasteful. Creating a comfortable work environment and teams that work well (synergistically if you like using that word) is so much more important, in my opinion.
%80 lost time or not ? (Score:3, Interesting)
Re:%80 lost time or not ? (Score:1)
The 90% rule (Score:5, Interesting)
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).
Re:The 90% rule (Score:1)
All the projects I have worked on professionally have been released except two, one of which involved a one-line change to an existing product that never ended up being needed, and the other was a "first draft" of a product I ended up rewriting from scratch. That means well over 50% of my professionally-written code has been actually used, especially if you include scripts and things that were intended just to be used by me.
Re:The 90% rule (Score:1)
Well, (thanks god) most of the code I write is personal (hobby project, hacking around, learning, testing, having fun, etc), so that the "90% of all your coding work will never be used for anything" pretty much apply, and that's no problem.
And I don't think it's wasted time.
Now, in a professional (capitalist) enviroment the coding is make by demand, so most of it *will* be used.
(Just as I don't think that when it comes to a point that you just throw away (mostly) all the code and restart from scratch is not a waste either.)
Re:The 90% rule (Score:1)
Re:The 90% rule (Score:1)
Good lord, what companies have you been working for? All the projects I have worked on professionally have been released except two...
We obviously work at different companies. I work for an RBOC, and I've lost count of the number of development projects that get canned less than a month before going live. So far, I've been lucky; nothing of mine has ever been pulled, although the one project was threatened. Then our manager decreed that everyone would work 12x7 until the customers were happy.
Number one reason for cancelled projects: The users don't know what they want. ("This isn't anything like what we requested!" "Really? The requirements document says otherwise. Plus, you seemed perfectly happy with last week's demo.").
Re:The 90% rule (Score:1)
Re:The 90% rule (Score:1)
I have the dubious fortune of being salaried; I get paid just for showing up, but overtime is non-existent.
Re:The 90% rule (Score:2)
90% of the code you change for a business rule change, will change back in six months because
a: the users hate it.
or b: the manager was wrong to begin with.
I never EVER delete code. I just comment it out. More than once I have been asked to change something back and I just uncommented the old code.
Simple advice... read books (Score:5, Insightful)
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
Re:Simple advice... read books (Score:1)
And, yes, I completed the computer science course, and I consider myself a pretty good coder (and even a scientist
(yeah, i would be perfect if i was modest)
Re:Simple advice... read books (Score:1)
I sincerely hope this does not apply to your reading-for-pleasure selections. My rule of thumb for books is all about how much of my time they can actually waste.
I'll leave the definition of waste up to the reader.
Arbitrary clerical deadlines RULE (Score:5, Insightful)
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.
Developers have Attention-Deficit Disorder? (Score:1)
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?
Re:Developers have Attention-Deficit Disorder? (Score:4, Insightful)
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.
Re:Developers have Attention-Deficit Disorder? (Score:1)
Personally I'd fit -- I've described myself as having about 0.5 in simultaneous capacity... (I am INTP in Meyer Briggs, the only test I've taken.) Still, only anecdotal "proof".
Write it up and get someone to investigate it! It's interesting.
(-: You don't want to depress parents of ADD children even more by telling them that their children might grow up to become computer nerds!? :-)
BTW, liked your .sig, but too cynical even for me!
Re:Developers have Attention-Deficit Disorder? (Score:2)
Personally I'd fit -- I've described myself as having about 0.5 in simultaneous capacity... (I am INTP in Meyer Briggs, the only test I've taken.)
Here's a test [oneaddplace.com] for you. No, I have no idea why this page doesn't use Javascript and calculate your results for you. I've thought about fixing that and sending them an updated page.
Still, only anecdotal "proof".
Yep, that's all I have.
You don't want to depress parents of ADD children even more by telling them that their children might grow up to become computer nerds!?
Well, my children have ADD (one of them for sure, two others probably, the fourth does not, or she hides it well) and I hope they *do* grow up to be computer nerds ;-)
BTW, liked your .sig, but too cynical even for me!
Not cynical, sarcastic. Works either way, though.
Re:Developers have Attention-Deficit Disorder? (Score:1)
I just wonder which ADD-stricken person lacking attention to detail decided to make you calculate your total score only to not refer to it at all in the evaluation!
BTW, my score was 285, with 67 items at 3 or above (scoring suggests that 20 or more indicates ADD). Gee, do you think I just might have it??
Re:Developers have Attention-Deficit Disorder? (Score:2)
BTW, my score was 285, with 67 items at 3 or above (scoring suggests that 20 or more indicates ADD). Gee, do you think I just might have it??
It sounds to me like it might be worth your time to go get a formal diagnosis. The main thing that does for you is to get you a prescription for Ritalin or one of the other ADD drugs. I'm considering doing that. I've never liked taking any sort of medication (even aspirin), but there are parts of my life in which my ADD causes me significant problems, and it seems to me that taking something might significantly improve my quality of life. I snitched a couple of my son's pills one day, and even though he has a minimal dose for a person one third my size, the effect was huge. The main difference I noticed was in my ability to focus on "trivial" tasks that occupy less than 100% of my attention, like driving, or holding a conversation.
In particular, I'm almost incapable of carrying on a conversation with anyone who isn't a quick-thinking adult -- any slowdowns in the pace cause my attention to wander. With such "less engaging" people, I must do all of the talking, or else I will begin thinking/doing other things while trying to listen and I'll lose the thread of their conversation. This means that I'm unable to really talk to my children and I'm willing to consider medication to fix that.
Re:Developers have Attention-Deficit Disorder? (Score:1)
Rule #1 (Score:4, Insightful)
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 (Score:4, Insightful)
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? [c2.com]
Peopleware and MMM (Score:2)
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.
Re:Peopleware and MMM (Score:1)
Probably because you're not wasting time and energy trying to explain to ignorant managers why the schedules are meaningless fantasies.
An analogy that occured to me during the scheduling of our current project: You are presented with a jungle. You have no idea of the terrain inside - rivers? quicksand? swamps? You don't know if there are any paths through it at all, much less where any that exist might be. Your job is to build a superhighway through it.
Your first step - before any other work - is to build a detailed schedule. Not just an estimate of how long it will take, but a list of "milestones" such that you know exactly where the project will stand on any given day.
If your project is simple - just building a bridge across a river, where the terrain is well-known - you might be able to do this. But I've yet to work on a software project simple enough that the schedule
I'm going to have to track down a copy of Peopleware and beat managers over the head with it in the future...
XP (Score:2)
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.
The "Do what you have to do" rule (Score:3, Insightful)
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:The "Do what you have to do" rule (Score:2)
I always like to first do a Proof Of Concept first and make sure all of the systems and technologies talk to each other play nicely with each other in the sandbox. Once you get that far, then I agree with you wholehartedly--get started on that prototype, because you can prolly work out anything that was holding you up.
Now that I think about it, the only non-compatibility-related showstopper issues I have ever encountered were bad project managment and/or political fighting. Check out the recent /. article on the VNC failure for an example of what I mean.
So while sweating out the 80% ... (Score:1)
- 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.
when you are really on... (Score:1)
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.
Scrum (Score:1, Interesting)
Re:Scrum (Score:1)
Housekeeping v. creativity.... (Score:2)
- 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
Re:Housekeeping v. creativity.... (Score:2)
Actually, Alistair Cockburn wrote Agile Software Development (ISBN: 0201699699). Robert Martin wrote Agile Software Development, Principles, Patterns, and Practices (ISBN: 0135974445).
Mimimize wasted time - I learned this in college (Score:1)