Slashdot Mirror
Smart Software Development on Impossible Schedules
Andrew Stellman writes "Jennifer Greene and I have an article in the new issue of Dr. Dobb's Journal called "Quick-Kill Project Management: How to do smart software development even when facing impossible schedules." We got a lot of great feedback from our last article on open source development, but there were a bunch of people who wanted to know whether it was really feasible to do planning and reviews on a tight schedule. That's a fair question, and this article is meant to be an answer to it. We pulled out bare-bones project management practices that will help you protect your project from the most common and serious problems, and gave instructions and advice for implementing them that should work in a real-life, high-pressure programming situation."
Just make your developers pick up the slack by working lots of overtime.
In the real world, no amount of tips and tricks is going to make up for a bad schedule. We end up doing code reviews while are software is in verification and validation. Is that smart? No. But when you need to get features done, that takes priority. As for documentation, that always falls to the wayside as well. The truth of the matter is this. The only way to make schedule is to totally inflate your time estimates on the project. We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late ;)
http://religiousfreaks.com/Less clicking.
The Army reading list
It seems to me that if you have an impossible schedule, then you've already failed.
Ewige Blumenkraft.
I was kind of suprised to see the recommendation for formal code reviews. In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments. I feel that pair programming is more effective way of getting multiple eyes on the code, spreading knowledge around, training the new guys, and all that good stuff.
And of course there's always static analysis to catch any problems that do manage to sneak in there...
The Army reading list
Well if you are desperate or evil enough to not give a damn about keeping a well motivated and trained staff (which will reflect on the product) then by all means outsource it to other parts of the world, you will be a fool not to.
/cut to the point.
//If you start with an impossible schedule wouldn't that be a bad sign to start with?
Stop reading slashdot!
The society for a thought-free internet welcomes you.
"Smart ... on an Impossible Schedule" is just management/corporate speak for "How to minimize the crapiness of a project when we know we can't spend the proper time required." You can dress it up all you like with sleak catch-phrases, and call it a rose if you want, but it still stinks.
So yes, the article does make some good points, but they only go as far as the factors covered are under your control. Even in the best circumstances, a poor programmer or a less than perfect team lead can hamstring the whole team. In the end, I think that the only benefit that articles like these have is to make you really think about process. Process might not save you in the end, but at least going through the effort should make you a better developer.
-:sigma.SB
WARN
THERE IS ANOTHER SYSTEM
Step 1: Admit being late as early as you can. If people start ranting, keep cool. Tell them that ranting won't fix it. The sooner you admit to being late, the sooner you can stop screwing around and start getting the project back on track.
Step 2: Help management prioritise what they want and what can be delivered when and what options are available. If they want a product to sell, they'll need to make some compromises.
Engineering is the art of compromise.
It's like playing Final Fantasy & casting Haste on your own team members after they've all been Doomed in an attempt to beat the clock.
Sometimes it works, sometimes it doesn't.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
is an oxymoron. That said, when I'm strapped for time I just inject embryonic stem cells down the eye of my penis.
"We developed a rule of taking the engineers estimates and double them. Of course we're still running a little late ;)"
Problem is Scotty already doubled them. Now just wait till the admiral gets them.
And if you do manage to produce something marginally useful in that impossible schedule, they'll give you even less time to do it next time around. After all, you managed to meet the deadline, right?
My current team has issues communicating, so I should bring another language into the equation ?
What are you, some kind of foreign labor spokesperson ?
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
It should read "Stupid Software Development on Impossible Schedules".
If its an impossible schedule then by definition it can't be done.
My favorite project karaoke is Rawhide. I never actually sang it on the job, but I had the joyous pleasure (after I left, throwing my mug in the drink and wishing river trolls on the morgul-minded) of watching that management style self-destruct within three months. From "my way or the highway" to chapter eleven in 90 days, wow. No, folks, rawhiding your most creative people is stupid.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
Nope, just a manager who wants to cut the time it takes to build our product and save some bucks while doing it(I will probably get a big fat bonus). And nobody can tell me otherwise because I read it on my favourite business magazine that claims it's the way to go.
/Make sure that I bail out for maintenance and future changes
//I don't know why Crystal Reports comes to mind ;-)
///Everybody can understand english, you just need to speak a little louder :-D
Pick two. If you are so lucky.
A truly impossible schedule is by definition impossible to meet.
An extremely-difficult-but-possible schedule is by definition makeable if the correct resources are applied... correctly.
If management is giving you an impossible schedule, they are either idiots or setting you up to fail or both.
If they are giving you a difficult schedule and refusing you the resources you need, or do not have the authority to give you those resources, see above.
If they are giving you a difficult schedule and you haven't requested the necessary resources, then they are testing you and you've failed the test.
--
What do I mean by resources? I mean anything that can make the project go faster without sacrificing quality. This may mean additional manpower, the authority to say "no" to new feature requests, the authority to make feature cuts, or the reassignment or hiring of people with key skills to your project. It may also mean late-night pizza parties and family-support to the "code widows" until the project is complete. It can also mean additional or extended time off for the entire team after the project is shipped.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
You made my head asplote.
It's not offtopic, dumbass. It's orthogonal.
How to be a consumer without ever taking out the trash...
How to spend money without making any...
How to eat without any food...
How to find another job after your company's poor planning puts you on the street.
2) Make sure you only work on things that you need to ship version 1.0 of that.
3) Make sure you keep the prototype running always.
4) Show Demos every few days to make sure noone is confused about what is going on.
5) Tell them they can ship it whenever they want, they write the check.
6) In the meantime, work towards the goallline like a football player, do not circle it like a lion waiting for it to die.
7) Don't make any project your time to show how clever, cute, or interesting you can be...
8) Keep Teams/Egos/Methods/Files/Modules/Projects/build times small. Small is good.
9) If someone is not clicking with the rest of the team:
- talk to them privately
- reassign them
- if this person is you, read #11, and consider if you want to build this project, or do something else. Follow your heart.
10) Do the riskiest part of the project first.
11) Remember that the enemy of the better is the best.
12) Don't worry about it. If you are working hard, and follow 1-11, you are doing your part.
That's enough to chew on. As homework, go build a paper mache model of the project, complete with testers whizzing around, filing bugs that are actually feature requests.
Programming isn't like building a bridge or skyscraper, where you can say "this will take x man-months" and build either a quick, expensive schedule or a long, less-expensive one.
Someone else already mentione Brooks's Mythical Man-Month. By and large Brooks is correct. There are some opportunities to "buy time" but these only work when the people you are adding have roughly the same level of knowledge as the people who are already on the team, and even then it's dicey. For example, if you manage to get someone added to your team who worked on the last release, and have him be responsible for updating the code he's already familiar with, you can make the project go faster. Bring in someone unfamiliar with the code and your schedule will suffer while he trains up. Also, if you were planning on giving a part of the project to an as-yet-untrained group, you can bulk up that part of the team before training starts and shorten the schedule. For example, if you have a dedicated team of in-house testers who have never tested your new product before, it won't be terribly costly to double the size of that team. Of course, if you don't adjust the size of the development team to account for bugs coming in at up to twice the previously-predicted rate you might shoot yourself in the foot.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Companies should follow EA's tactics. Say to the coders "you'll have an easy schedule during the majority of a project but at crunch time, you're expected to work huge hours with minimal overtime pay" You start the coders on a project nearing crunch time, have them slave away till it's finished then move them onto another project that's nearing crunch time. If no projects are nearing crunch time move ahead the schedule on one knowing full well you can't meet the new date but still force the overworked coders to give 110% to attempt to meet this impossible target. You keep all the experienced programmers doing the stress free base work and once the outline is done, you move them to start another project. The vital experienced coders stay happy and stick with the company and the dime-a-dozen average coders have all the work they could possibly give squeezed out of them for minimal pay. Gotta love an industry with few/weak unions...
Seriously, doubling the time is NOT enough.
;-)
Top 12 - Rule of thumb says:
1) Triple the estimated time + 10%.
2) Add 2 weeks to that amount for a complete code review.
3) Any changes by the customer means "adding 2 weeks to the schedule", even if it's one line of code... why? because, it must pass documentation, Q.A., validation and be reviewed by the entire department, without accounting for "double bug", bug induced by another bug and stuff like that or bugs that are in the core library and means retesting "everything", "every module", etc.
4) Any changes must be approved, reviewed and means adding delay (normally a big NO-NO) and therefore, 99% of the case thoses changes are left for future phases or abandonned by the client when they realise the implication. If not, it's your objective to discourage them or force them to reconsider by any means. =P
5) Don't give any feedback to the customer unless you must! If you do, downgrade any progress to minimum to reduce expectation and refrain the customer from adding new stuff to the TODO list.
6) Which means, each phase must be clear, consise, humble, realistic, feasible, with lots of buffer time for fixes, reviews and testing. Exagerating how complicated it is to a customer is always a good idea, because in the end, everything that seems easy is actually very difficult.
7) Do minimum documentation, UML to get started... They'll get rewritten at least 30 times, before everyone in the group agrees after what 40 meetings?
8) Once the phase somehow works and the thing is somehow settle, start documenting it, so you don't forget. It's actually a very good way to detect logical mistakes, misbehaviors, bad coupling, bad cohesion, missing corner cases, bad design choices, usability problems, etc.
9) Best teamwork is small team of 3-5 senior people working toghether hand-in-hand, sometime helped by 1-2 junior, which can do much better than 120 junior who are completely clueless and never deliver on time...
10) For big projects split things up in component and/or phases that a small team of 3-5 people can do, keeping in mind of the big picture so its scales up, but ignoring any meaningless future details that don't matter "right now".
11) Rush the people to do it in "the simple 1/2 time delay", keeping in pocket the "double time" remaining for any arising issue and reworking the core libraries, overhaulin the code, reviews, fixing bugs, etc. This means that if you are really late, you are actually late on your "buffer time". If things goes well, then the project will be done before it's expected, which will impress any client.
12) Finally, but not the least, there's no such thing as a bug, it's just a "small improvement", a "new feature", "code overhaulin", "mispelled requirement" or a "security enhancement". It keeps customer smiling, it's less depressing for everyone and overall keeps the mood up on everyone face with a laugh or two!
Furthermore, no ones want to hear that the code is "full of bug", but saying that a group of people are always "enhancing, overhauling and improving the code base" also means bigger bonus! =)
Hope it saves you from any future project delay or cost overrun!
I think that the most important thing to do when a project is on an insane schedule is realize that you aren't super-human and pace yourself. If you don't, and crunch hard nights or extra-long 50-hour sessions, you'll spend the next few days with a fried brain and a complete inability to make use of your time.
If you're normally a 9-5 guy, pull 10 hour days. If you're normally longer, possibly consider working longer, but notice when you've started lagging because of fatigue.
Other things:
And my build is done...
When you're in a situation like that you need to prioritize the most critical features and release them immediately.
That wouldn't happen to be a sales manager for a foriegn staffing firm would it ?
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
How's that version of "Quick-Kill Project Management"?
Slashdot's bot checker a mind reader?
How many of us have been under the fire of those impossible schedule? These last years have been coupled with "due yesterday projects" requests. It must be some human resources way to have results against lazyness and such.
I haven't the experience that some of the engineers hanging around here have, so please take what I say with a grain of salt.
However, the article appears to be far too idealistic.
1) The only good schedule is a realistic schedule. If the schedule is intentionally compressed, it's a bad schedule. The only way to compress your schedule is to cut work (e.g. features).
1.5) Working under the "hurry hurry hurry" "boss wants it yesterday" environment means your engineers will cut corners everywhere. When faced with a choice to copy/paste a function in 15 minutes vs. taking some time to refactor and reuse the code in 1 hour, engineers will choose the earlier. In my experience, design debt then accumulates really fast.
2) Code reviews as suggested in the article are a drag (2.5 hours at a time?!). In my experience, they rarely get anything useful done: it's usually too late to make medium or major changes and under the gun (see 1.5) engineers will scoff at "wasting time" with minor changes. From what I've seen, the code reviews serve mostly as a cover-your-ass mechanism for management.
Code reviews need to be short (30-45mins) and happen as soon as possible, while the original engineer has all of the reasoning and decisions in his head. Hot-on-the-heels code-reviews of bug fixes and feature check-ins (especially useful for bug fixes).
Perhaps the code reviews need to happen as the code is written (sometimes I ask my coworkers to show me their draft solutions). That's almost pair programming though. Unfortunately, that's not practiced at my job, and so I have no expereince with pair programming.
3) Estimates. What the article described seemed to be a basic process for doing the SWAGs and the engineering time estimates that we all "know and love." I fail to see the novelty in the proposed approach: it seems to be run of the mill waterfall stuff.
It's so easy to say "break down estimates into small tasks, so you can estimate well." However, I found it very difficult to do so effectively. Pardon the Rumsfeld flavor, but often we just don't know what we don't know: stumbling blocks occur, requirements drift or get "clarified", surprises abound. Pressuring developers to provide task breakdowns and estimates past their knowledge point can create a false sense of security (i.e. misleading task estimates). I've seen many such a small task breakdown become trash as the project progressed.
Often, to get a better idea of the remaining work and tasks, prototype work is required or some progress on key features.
I have no good answer for this problem, but my feeling is that it lies somewhere in the realm of being able to react quickly to change and reevaluate the project's progress. This is where things like smaller tasks and more frequent completion points of features seem to help. At that point, changing direction is easier because you have fewer concurrent unfinished tasks.
This is where the smaller tasks and frequent iterations of the XP fame seem to be a benefit. Unfortunately, many managers can't take the thought of not having a detailed per-small-task project plan in their MS Project window. So, in my unfortunate experience, such managers attempt XP-style iterations, but then quickly regress into more traditional long-term milestones. I've seen it happen time and again.
I was asked to create a fully dynamic, CMS backed website in 3.5 days, using ASP.Net just the other day. This was because the Marketing department had forgotten to involve me in the launch of their new spin. I managed it by working long hours, robbing code from other projects and working at a furious pace. There was no time to plan, I just had to spill out ideas on the fly. Sound familiar?
... and the amount of times I have been told, "it's just a few buttons, surely you can manage that!"
I went on vacation, returned after 3 weeks and nobody had used the CMS to populate the site with data and graphics. In fact, the Marketing department complained that I had not given them more time to decide what they wanted. I was blamed for holding the project up.
A lot of people out there think that coding is very simple, a bit like waving a magic wand. Oh
Now where's my wand gone?
Sarcasm, Joebert. Joebert, Sarcasm.
emt 377 emt 4
So that the oursourced-to crew can say
" we love deadlines, the whooshing
sound as they go by, priceless ".
Or something like that.
emt 377 emt 4
Oh me & sarcasam have met, it just seems that every time we do, they've undergone plastic surgery & I don't recognise them at first.
Wanna fight ? Bend over, stick your head up your ass, and fight for air.
:-)
There is a hidden flag you can test for.
emt 377 emt 4
I can't stress this one enough!
As architect of a small software company, the most frustrating aspect of designing software is the knowledge and understanding that there's no way to know how to do it right until you deliver something that's wrong. People almost never seem to know what they need, but they do know that whatever they have isn't it, and they'll tell you why.
So, we have a very different tack, similar to Agile Programming. When we implement a new feature or functionality tidbit, we release very early - pretty much as soon as it more or less works without major errors, - with as much fanfare as we can manage on the cheap, and then wait for the feedback.
We're very up front about it, and openly welcome the feedback and ideas. This takes any conflict out of the relationship and turns it into a sort of partnership. Customers love being listened to, and feedback we get, in droves. When a customer sees THEIR idea implemented a week or two after they suggest it, even when it's something stupid-simple (such as having a particular button selected by default to avoid a common mouse-click) then they're your advocate for life!
It's that continuous, iterative cycle that's resulted in our young, 3-year-old codebase having eye-popping features, and remarkable stability. The software updates itself at the client's discretion, so nobody seems to mind much. They update as often as they like.
With this model, there is no due date. It takes me about 15 minutes to issue a release of our software. The idea of a "release" means almost nothing - we've done more than one in a day! (we've released 46 official releases in the past year alone, with too many "unofficial" releases to count)
Faced with this "impossible" situation, (I've lived "impossible" schedules for years now) I'd step UP the release cycle and start pre-annuoncing alphas/betas of the product the instant that something that appears demonstrable compiles and can be stuck on a dev server someplace. Invite comments and download. Call people to ask about feature X or Y. Let them know it's really early, and make sure that they have a place to bitch about the problems they find.
When you do, you'll be surprised how much of what you thought was required was, in fact, completely un-necessary - or at least could be put off until next March for a future release. But, you'll find some simple, straightforward ABSOLUTELY GOTTA HAVE that takes a man-month to code that the users would sacrifice their firstborn to have.
Agile software methods will find this "gotta have" pretty quickly. The waterfall model of software development would take a decade.
You decide.
This model won't work for all products and/or markets. And it's very important not to take away functionality that the customer previously had, or they get the feeling that you're taking something away, and that's bad. But for us, it's been very, very successful, and the relationship we have with our clientelle is very friendly, close and intimate.
PS: Maybe it helps that we're an ASP.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Rapid Development: Taming Wild Software Schedules
by Steve C. McConnell
I'm in no way related to it, I just own it and I think every project director should have one. It contains a lot of ideas and hands-on tips you can immediately try on the field. The last section, named Best Practise, is a practical reference guide. There is also a chapter if you already are in a crazy project and want to rescue it.
[Sarcasm on]
1. Quick kill the managers who set the impossible schedules
2. Quick kill the developers who can't stay within a reasonable schedule
[Sarcasm off]
It's impossible to change the development time outside of the -10%/+10% margins. If your schedule is wrong you either have incompetent managers, incompetent developers or both. What ever you do, work overtime, drop in more developers or else, all you gain is a few percents.
Development time is IMO a rather static variable, the only thing which can improve this time is education. Yet education has to be done in advance before the project is even started. During the project there's no time for education while the knowledge should be available right from the start. The easiest solution is to always plan for a 25 - 30% education phase at the beginning of your project.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
Join a pre-existing open source development group?
What's so irritating is that the previous generation pretends that they've known the lessons all their life and takes them for granted, begs the question as to the right way, and any other similar sins of... what sort of sins are these anyways?
Oh, and none of them come up with a cure to the problem, but insist that doing it their way is the cure.
From architect on up, one of your key job responsibilities is to push back on features, schedules and so on, and to set expectations right from the get-go. Early on, I used to laugh out loud when being told proposed dates by marketing. That didn't go over too well, of course, so I've adopted a more diplomatic way of saying 'no' since. :-)
The gist of it is that many executives believe in Spanish management (very well explained in Peopleware). This boils down to setting ridiculous schedules, asking for continuous overtime, etc. The idea being that every minute an engineer spends more will get the product out the door faster. Of course, this is not the case as Peopleware will tell you in great detail. It is also matched by my own experience.
However, if you push back with data in hand (such as a detailed sizing) and a constructive proposal what to do differently, you may very well end up with a more reasonable schedule, a good product and happiness all around.
A few more gems in Peopleware:
- Schedules are counterproductive. Teams that don't have schedules ouperform those that do by up to 50%.
- Overtime is only productive for one week.
- Cubicles are sinkholes of effectiveness. Why do Microsoft and IBM only have offices for engineers?
Peopleware is rather sobering. Every other page you think "wait - we're doing exactly what is being described here." The good news is that you can do something about it once you can recognize the signs.For those of you with a humorous bent, I highly recommend checking out Joel Spolsky's articles on project management. A few highlights:
- Human task switching considered harmful
- Joel's test to identify bad software companies
As far as the TFA goes, once you've accepted an impossible schedule you're already hosed. If you can't push back, leave. The job market is good right now.If you can get to a reasonable schedule (by way of reducing features, adding time or people), the TFA is a bit limited in its scope. I have a few recommendations that have worked for me in the past (your mileage will vary, and you should read Peopleware anyway):
Learning to use copy/paste doesn't mean "use copy and paste for everything you do." Don't confuse the two.
Copy and paste come in handy when you're refactoring a function call, building a table of similarly named elements, or propogating a new flag/variable. It can be a serious time-saver. Ctrl+Shift+(left or right) to select, Ctrl+V, or double-click, Ctrl+V.
I'm not saying that copying huge chunks of code is a good idea. That ends up costing you more time. I'm saying that typing things out fully when you could use copy/paste can be a time saver. It's also worth mentioning that learning little shortcuts in your environment may not save you time overall, but it can make you faster when you need it. Spend slow times getting to know your workspace.
Yes... I'm still at work.
One last note would be that, when it comes down to it and you just have to kill yourself to get something out the door, you shouldn't expect any huge pats on the back for it. If you grind hard, you generally won't be the last guy holding up the show. Do this for a few revisions, and people will come to think of you as a closer. I don't know if this really helps in any way. I think it generally just means that you get more work to do...
Back to the grind...
Use a project management tool that does most of the work for you like xProcess from http://www.ivis.com/
Yeah, Steve McConnell's book should be required reading for every project manager in IT. Of course, once they've read the book, they'll probably think they know as much as him, but that's another story.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
Dont make the deadline.
Cripes you guys, pulling miriacles out of your asses every day means that management expects it.
Then sales starts selling your team as "getting it done in 1/4 the time. and then youare royally hosed with the worst job ever.
Do not look at laser with remaining good eye.
1. Stop agreeing to customer deadlines before asking the engineers how long it's going to take/if it's possible.
I've had many, many instances where someone asked me how long something would take, and I told them that there's really no good way to do what they're talking about so at least a month or two. It was only after this that I was told that they had already agreed to 2-3 weeks, so I'd better "figure out a way". But what if there is no way? It's not like 9 women can have a baby in 1 month, you know.
stuff |
Sustainability.
I've taken development teams down into the Valley of Death and out the other side. It can be done. But there are consequences, and you're kidding yourself if you think you can avoid them.
The first consequences is that you can only do this once. If you're smart, you hire smart people. They know when you are ordering them to jump into a pile of shit. And if you're smart, you hire craftsmen, and craftsmen have pride. They resent being told to do that. What that means is that if the second time you try it, you end up losing all the people who can find a job easily -- in other words your most valuable employees.
Another word that should be in managers' vocabularies is investment. Developers create assets that produce future revenue and expenses. You want programmers working as hard as they possibly can, but not simply to get the job done. To get the job done right, which means producing something that generatesw more revenue and less expense. When you focus on just getting the job done, you end up with something that barely breaks even. That's the minimal criteria for "not failing", not the maximum possible success.
That's why I hate questions that start with "How hard would it be..." because they focus on the present, not the future. It should be "I think we can make X dollars a year; how much would it cost to support this feature, and would the amortized development costs be justified by the net revenue given the other things we could put our efforts into?" It's not as pithy as "How hard would it be...", but it covers the things managers should think about: the future impacts on revenues and expenses, the opportunity costs of the road not taken.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I have seen great projects, OK projects, and the-worst-projects-ever-created. This article points out some good tips, but there is no such thing as a free lunch. The best thing you can hope for when faced with an impossible schedule is to communicate with management, and not just with bitching about how they setup an impossible schedule, but offer solutions that are logical, like reducing scope, throwing more money at it, slipping schedule, reducing quality, or yes even canceling the project!
Want some good (aka REAL) tips, check out Steve McConnel's book on Rapid Development (Ignore the fact that it is produced by M$ press). This book is great, and if anyone is serious about software development they should read this book. And for the developers out there, please read his other book, Code Complete.
Here, Here! This book is great. The developers should read his other book, Code Complete!
There is a fundamental problem with planning innovation (doing something you or others did not do before):
Because you are doing something new, you cannot predict in front how much time you need as you don't know the problems you will encounter and the additional requirements/features that pop up during development (this always happens in software or system development).
PS. I am talking about real innovation. Most real innovations are build upon existing ones. So this holds only is you maximize sharing or re-use of existing systems, and not repeating your same trick over and over again. I will even go so far as saying: if you did a good planning your development is problably not very efficient.
The only part I disagree with is a schedule. Its not that schedules are bad. Its that people aren't rewarded for being honest. We've tried to convince folks that they need to put everything they do on the schedule so that management can see the actual complexity and so that they get credit for what they do. Then, at the end-of-year review, they can go through some of the schedules/plans and say "I did this and that".
I'd mod this up but I don't know what that means!
This tells me that you don't have much experience, or any experience of well-run code reviews. It is not trivial to moderate a code review, but nor is it very difficult if the moderator has received a little training.
In my experience (~30 years of it) properly-run code reviews are the best way known of improving code.
Pair programming I find mostly a waste of time. It's just a way of using 2 people to do one person's work.
It's interesting to look down this thread and see how many different rules of thumb are employed, apparently by quite experienced developers/managers.
It seems to me that we can make two reasonable assumptions based on this:
One might hypothesise, based on these assumptions, that any project plan that quotes hard figures up-front will be inaccurate most of the time, and without allowing a huge defensive overhead that inaccuracy will often be in the wrong direction.
Now, working from unreliable estimates is in no-one's interests. If a company overestimates by too much on a fixed-price contract, it risks being undercut by a more realistic competitor. If it underestimates, it will look bad when things over-run, its profits will fall, and its reputation will suffer as well.
So what conclusions can we draw from this?
Firstly, if we're looking for realistic management, the way to go is almost always some sort of time and materials contract, with floating deadlines based on when features are actually ready. This allows good developers to do their job properly, which in the long run will be more efficient, and it means that other groups such as sales, marketing and customer support can be kept informed and given realistic expectations.
Secondly, fixed-price contracts are only a good bet for a software development firm if it can include enough slack to be safe, without including so much that it can be undercut by more realistic competitors. The corollary, of course, is that if you're a client, you're almost inevitably going to be screwed by agreeing to a fixed-price contract, even without considering the lack of flexibility it entails.
It is a rare project indeed that truly requires hard deadlines. Smart clients and smart development shops will reach a more flexible arrangement, and come to respect each other for having realistic expectations and providing realistic updates as time goes on.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
A good way to avoid pissing matches over brace indentation and other nits is to lay down a qualification checklist that must be clean before a review. It can be simple of extensive depending on your field. What slows the review process is a moving quality target that varies with reviewers. A checklist helps prevent that. Pair programming is a drastic waste of programmer time. What you typically get is an alpha who overwhelms and neutralizes the work of his partner.
an ill wind that blows no good
Intriguing--this sounds like what real engineers call engineering. Summarizing:
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
... does a coder with multiple personality disorder really need a collegue for pair programming?
"Work expands to fill the time alotted for it."
This is one reason why software is NEVER completed before the estimated date. If you're doubling the estimates, you'd best not let the engineers know that you've done so.
Learn to use copy and paste ... learn to type quickly This is the absolute worst advice I've ever read about programming. Need to add a parameter to a piece of code that has been copy/pasted 10 times? You'll multiply your work by 10.
Ever copy/pasted a piece of code into *another* piece of copy/pasted code and need to make a change afterwards? Prepare to increase your workload by a factor 100. Do it again and it's a factor 1000. And you just might have duplicated a bug. Before you know it, you'll be drowning yourself in repetitive, boring work and bugs that keep popping up after you thought for the Nth time that you fixed them *for real* this time. Even if you're the fastest typist in the world, no amount of words per minute will be a match for spending five minutes of your time to abstract your repeated code into a function.
This is also shows why lines of code per day is a bad measure of productivity: the better a programmer is, the less lines of code (s)he needs to implement the same features.
Finally, another indication that repetition is bad: I was going to give this a subject with a lot more O's in there but the lameness filter stopped it. Reason: Too much repetition. How appropriate.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Aim for quality then pick a realistic budget and schedule to match. Better yet, double the schedule and double the budget, then you can look really good when you come in way under budget and way early.
Note he didn't say he did it "cheap" or "fast" only "on time and under budget."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
> "How to do smart software development even when facing impossible schedules."
Here's the answer: "Remember that study from last year that found the top programmers were 4x as productive as the average programmers, and that there were things the top programmers could do that average programmers couldn't, no matter how long they were given? Hire some of them guys."
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
...so last project you worked 40 hour weekends to bail management out yet again. The real problem: Now you've raised their expactations of whats possible, and they'll expect that and more next time. Its the Scotty principle.
If you want to continue to give your whole life to your comapny in the mistaken concept that you'll get recognition for it later then chances are you're still a naieve new grad. Experienced engineers know they have to train their managers.
After 25+ years of software development heere's what I learnt works best:
* Demand the necessary time to do good work, no matter what time problems that may cause others. Reason: You will actually need about the same time, no matter what quality concessions you make. Furthermore, your manager should have had involved you in his time-estimates for project planning. This is management 101. If he didn't then this is the only way you'll convince him to involve you next time.
* Don't ever agree to deliver low-quality product, regardless of other peoples deadlines. Reason: Non-techincal managers mistakenly believe that time can be saved by sacrificing quality. Actually the opposite is true. Low quality software takes more time overall. Furthermore, if you deliver crappy software, people will forever identify you as being a crappy engineer, regardless of any justifications you may have had at the time. If you're a crappy engineer you're like too many others and worth nothing.
* Don't work overtime unless you both want to and are being paid extra for it. Reason: Your employer is making significantly more money from your work than they are paying you. If they weren't, they wouldn't keep you there. Its basic business economics. They are not a charity and you deserve to be paid and treated just like any other professional. Furthermore, it does nobody any favors if you set urealistic norms and expectations. Yet another reason is that you are far more effective if you're not continually burned-out.
The BIG secret your company doesn't want you to know:
Nearly all deadlines are just artificial mechanisms created by management and designed solely to get free overtime/more productivity from the workforce. They usually have no relation to what delivery date was acutally agreed with the customer.
So nice recipe, looks good, has somebody put it in practice already?, where are the case studies?
If you are in a bind like this one, better take a look at SCRUM or any other of the Agile Processes that are PROVEN to work.
HTML is obsolete. It's time for a new, simpler and richer markup language.
I agree with the value of code reviews, but there's no way you're going to get developers together for 2.5 hour meetings on a regular basis! This is EXACTLY why we no longer have a policy for review meetings. We're using a tool now, Code Collaborator - http://www.codecollab.com/ and it's pretty spiffy. I think probably the most time I've spent on any one review was 30 minutes. We also trialed a couple other code review applications, but they all could be improved, to make doing code reviews easy. Does anyone know of a feature by feature analysis of the code review applications that are available, and what SCM systems they support (we use Perforce)?
Seriously, one could fairly easily convert this guy's suggestion to SCUM:
- Vision and scope document = Product backlog
- Work breakdown structure = Sprints and task estimation
- Code review = Sprint review
And with SCRUM you have a much larger pool of resources for help, suggestions, and case studies.Who said Freedom was Fair?
The article states that, "If two people disagree on how long a task takes, it's likely that...each person made different assumptions about details of the work..." If only it were that easy! Given that developers vary from 1-4x in productivity (or 1-10x, if you read Tom DeMarco's _Controlling Software Projects_), any hope of estimating accurately, especially on small projects with only a few developers, is, well...hopeless.
I think schedules are an interesting subject that can take pages to cover. A few thoughts anyway:
But you did read that last paragraph, right? I don't think I exemplify anything other than an unreasonable emotional attachment to my product that allows me to be taken advantage of.
I essentially said that, if you kick things out the door through lots of late nights, people will come to know you as someone who finishes well. Then they'll give you more work to do. I didn't say this was good. There generally aren't performance bonuses (unless they've been agreed to before), large amounts of comp time, or cool perks awaiting those who completely bust themselves to get something done.
If you love the product and the work, that can be a reason to do it, but don't do it because you think it will get you much more than a "sucker" stamp on your forehead. It won't.
then either your engineers stink or you've put them in an impossible situation. A good engineer will rarely miss an estimate made with sufficient information unless you're pressuring them to commit to an unrealistic timeframe, asking them to develop something for which they had no input or control at the design phase, or you keep surprising them with other work that has a higher priority than their project work. As for sufficient information--if the engineer doesn't know enough to make an accurate estimate it is his responsibility to say so, and if you ignore that then it's not his problem when he misses a date. A relevant article here is Joel's piece on "The Development Abstraction Layer": http://www.joelonsoftware.com/articles/Development Abstraction.html
I have lost many contract opportunities because of honest estimates, but I have received so much other business because of that honesty that you wouldn't believe it. And now because I confronted this issue upfront, rather than giving a low-ball estimate, I don't have to have a confrontation at delivery time, because all the cards were on the table for the start. And now these clients trust my opinion, because I was willing to give them the honest and difficult truth that I cannot make them happy for the price they wanted to pay.
Honesty. These clients need someone they can trust to build their software, because they have absolutely no idea. Just because the business world forces you to swim with the sharks, doesn't mean you have to become one. Just try not to be a tuna, so you don't get eaten. So make that honesty and gonads.
This rule of thumb shows its age:
For COBOL programmers, multiply estimate by THREE.
For FORTRAN programmers, multiply estimate by PI.
A proper review means giving the reviewers review time, not just dropping a pile of code in front of each attendee 30 minutes before the meeting. The reviewers need time to comprehend what's being presented, to look for logical inconsistencies, to ponder what the user may do that wasn't allowed for, to track down unintended interactions, to find the right questions to ask. A reasonable figure is two hours of prep time for reviewers, spent at least a day in advance (the subconsious mind of sleeping reviewer is a powerful tool). Then the review meeting can move faster, while also being more effective.
If reviewers must start cold, finding a missing delimiter is a best case scenario. More likely, the meeting will be spent handling superfluous questions that arise because the reviewers don't understand the items being reviewed.
The article talks about fixing bugs during the review. YIKES! Impromptu decision-making is a recipe for compounding errors, especially when under the gaze of upper management. Every problem a reviewer brings to the table should come with a thoughtful plan of attack. Wild-ass guesses inevitably cause new problems, further corrections, and additional schedule delays.
I would have read this article if you had left some room open for the lead-programmer to be a woman.
I understand that most people here will think I'm overreacting. We all know that it's easier to wrtie "he" than "he or she" and that if you're going to pick one gender, the most commonly picked is the male. (Quite frankly, in this line of work, you're probably right to pick "he.") If you pick the female, you're making a statement rather than just avoiding the lengthy and cumbersome "he or she." But seriously, there is so much discrimination against women in the programming world that we need to be helping women to imagine that they might be the lead-programmer rather than assuming the lead-programmer is a man.
If you were programming, you would be more specific about the possible values for a given variable.