Thursday, December 1, 2011

Why Software Projects are Terrible and How Not To Fix Them

Shouldn’t a little startup using XP be able to wipe the floor with bad companies in an hour? If all it takes is better engineering practice, shouldn’t the better engineers always win?

our industry’s best practices don’t make sense. I don’t mean, of course, that they aren’t objectively better–of course they are. But they are nonintuitive.

If the guy you’re talking too is thinking “This sounds like a really good idea but I’m concerned I can’t sell this upstairs,” you are dead in the water.

Put yourself in the middle manager’s shoes. If the project goes bad, he has to “look busy”. He has to put more developers on the project, call a meeting and yell at people, and other arbitrary bad ideas. Not because he thinks those will solve the problem. In fact, managers often do this in spite of the fact that they know it’s bad. Because that’s what will convince upper management that they’re doing their best.

My second theory is that business objectives can change faster than anyone can react.

Jobs was fired in 1985, but he was re-hired in 1997. That is twelve long years before they admitted their mistake.

Reality is slow.

They want results today. They want a PowerPoint slide to present at the meeting upstairs in ten minutes that explains how the project is back on track. They don’t want a real solution, they want smoke.

Actually writing better software doesn’t matter. What matters is stats.

If a prospect objects to being involved in the testing, starts editing your contracts line-by-line in pencil, and starts talking about penalties for missed final delivery deadlines and bugs,

run.

CTOs in mainstream companies still believe in function point analysis.

I would like someone smarter than I, to produce a software formula that balances these factors: Speed to Market, Profit, Cost, Happy Customer, Happy Stakeholder, Quality, Performance, Keep your Job and Happy Worker.



оригинал

No comments:

Post a Comment