views:

391

answers:

14

If you ever managed a software development effort or parts of it in any capacity when what bits did you find difficult or frustrating? What did happen at the end?

UPDATE: It would be nice to hear some actual stories as opposed to "geeks are difficult people". Thanks!

+5  A: 

Software Developers.

You're all a nightmare

John Nolan
No, we're real.
djna
Doesn't that make it even worse ?
Matthieu M.
If you're not a software developer, what are you doing on a software development site that gets into technical details? No offense -- there could be many legitimate reasons. However, perhaps your developers are a nightmare because you're trying to micromanage or do their jobs.
Lee B
In terms of the why software developers can be a pain (not necessarily are but can be), I'd generally put it down to their lack of understanding about some of the commercial realities. Generally speaking managers don't want to do dumb stuff any more than programmers do, we're doing it because that's what clients insist (despite our best efforts, I promise you we try) and that's how we all get paid, make our rent at the end of the month and have money for iPods.
Jon Hopkins
+4  A: 

Difficult: The hard-to-reproduce bug. Very difficult to construct a schedule for delivery with one of those to accommodate.

Frustrating: Communication. Write a spec in detail, tends not be read in detail.

djna
+4  A: 

Optimistic schedules drawn up by management, even when you've told them already that it's impossible.

Jon Limjap
Sounds like a Dilbert cartoon.
ScottE
My project has so many Dilbert moments, it's scary. Sometimes I check around the corner to see if Scott Adams is there taking notes.
MetalMikester
+11  A: 

The most frustrating part is trying to get a full specification up front so that you can estimate properly. The worst part of the process is having a half baked spec, coming up with an estimate and then being rigidly held to it while functionality is shoehorned in left, right and centre.

Pete OHanlon
+1  A: 

Funny Dates : That Project Leaders and managements commits

Now developer need to complete his job on time with Quality .

Some time these leads to hell

sat
+7  A: 

Clients. Things would be much easier without clients.

ScottE
And without them we don't have jobs.
squeeks
Just having a little fun squeeks. Although I must say that when our company does internal projects things still go sideways, probably with greater frequency that for exteranl clients!
ScottE
+1  A: 

The fact that I read all these silly questions rather than doing some work...

Paddy
+3  A: 

The most challenging part is usually the client.

The client often doesn't want to understand that something that takes only 3 minutes to come up with on a whiteboard might take a lot longer to actually create in software.

They also often fail to understand that changing their mind completely halfway through a project means that de-facto we are starting over, and the deadlines need to move.

Also, "time and material" budgetting in a project still means "fixed budget" on the lowest value that you mentioned in the quotation to the customer 99% of the time, no matter how many times you explain the concept to them.

This is why I no longer manage projects, but work as a developer team coach instead. Software Developers, you are great people compared to clients :)

MadKeithV
+6  A: 

Ignoring my attempt at humour/flame-bait (delete as however you interpreted it).

Here are the things I find difficult/frustrating when managing a project:

Underspecified projects.
If you don't know what you want how can we give it you?

Unrealistic and ever shrinking deadlines
Just because you say it can be done in two weeks doesn't make it so.

The next highest priority syndrome
If you want a project doing and that's top priority don't come mid-way through project and give me another top priority and then don't come mid-way through the project and give me another...

Quality, Speed, low cost
Pick two out of the three.

People
People can and will get in the way of even the best planned projects.

John Nolan
"The next highest priority syndrome" and if you just made one project the highest priority over a another project, don't come back two hours later and ask if the original first priority is done.
HLGEM
A: 

You might not believe it but its happening..

when project managers does not have geeks at his disposal...

and when your (co-)developers are worse than your clients...

its not an ideal world after all.

thecoolside
+1  A: 

Computers do what was said instead of what was meant. People do what they think was meant instead of what had been said.

People have agendas. And there are as many agendas as there are people on your team.

Quality is the biggest variable in any software project.

Totophil
+1  A: 

Where I work, we are using Scrum and some other Agile practices so that we are self-managing in some ways. What makes this frustrating:

  • Trusting the rest of the team. Will they pull their weight? Who knows how to handle various parts of the codebase? Do they know how to do their job?

  • Trusting the management around us. How are the Project Manager, Scrum Master, Team Lead and others seeing what we are doing? Are we doing good, great, or suck? Are they pulling the good stuff from the back log? Are we getting whatever hardware or software we need up and running?

As you can probably tell, I am a bit of a worrier and have had fairly bad anxiety a few times. I do really believe I work with a great group of professional people that do dig in when needed and aren't afraid to roll up the sleeves and get dirty. Similarly, we have had problems and tried numerous ways to get around them but some part usually remains. The end is still months away for this project but the team has been together for almost 2 years now mostly so we do know each other to some extent.

On my current major project, we are customizing a CMS which has taken a long time to get to the first release that came 15 months after the project started and still has at least another few months to go. The consultants that we are using don't have answers for some of the problems we are having because we are trying to do this in a way that is quite different from the usual way. Let me describe a bit of each to explain:

Usual way is Waterfall-like. All the requirements are gathered upfront, and then the customizations are done and what is delivered is what was promised, nothing more or less than that. This has the problem of if there is something to change, that may or may not be possible to get done. Note that the languages needed for the site, what pages would look like and all this other stuff has to be known at the start.

New way is Agile. We have some of the site working, but we are still adding more functionality and where needed going back and changing things to handle changing requirements that can come hourly in some cases as this isn't a small project. There are over 50 people on this project team and involves at least a half dozen departments with a half dozen from IS and probably a dozen or more from Marketing.

So far it is working but the process is still evolving and that seems like a good thing at times, just in case anyone got bored. :)

JB King
+1  A: 

Product Management teams easily frustrate a project by passing information in only one direction, customer to engineering.

The most effective PMs provide technological leadership by mixing non-customer market knowledge with existing customer feedback. They understand when to say "yes" and "no."

Hesitant PMs parrot customer requests without exploring which will generate revenue. Otherwise successful projects wither without this understanding. Engineers blame each other without realizing the basic concept itself won't sell.

Matthew Glidden
A: 

My perspective may be a little different because I transitioned (read 'volunteered') from a software developer to a project manager.

Being responsible for other peoples' work

Feature 'A' wasn't delivered because Joe Developer [quit, got sick, forgot C#, etc] = My fault

Not being able to jump in and write the code myself.

I did try this, but the constant fires and interruptions resulted in spaghetti code.

Everyone thinking I have all the answers.

Well I don't, but any answer is better than no answer. Sometimes these answers come back to bite me.

The word 'Estimate' is synonymous with 'It WILL take EXACTLY X amount of time...'

Coming up with estimates on a one line requirement will almost always be wrong.

Reflecting at the end of the day and not being able to think of a tangible THING I personally delivered.

Let's see I was in 3 meetings, did some 'pair programming', created tasks for developers... Nope I've got nothing.

Curt