If, as you claim, your project has “many of these mistakes,” I respectfully question your definition of "success.
On time
On or under budget
Users/Customers are happy
Nobody feels like they had to kill themselves to do it
The developers feel good about the product they have produced
Those are MY criteria for success, even though we made several of these so-called mistakes during the dev cycles. There are times when it’s a near thing of course, and times when it’s an utter failure but there have been plenty of success stories to. Enough to make me love my job.
IMO these lists are mis-named. Instead of “classic mistakes” they should be called “classic warning signs”. If you see these in your project, watch what your doing or your going to crash and burn but it’s by no means a given that you’ve failed.
I’ve increasingly come to believe the only difference between
experienced and inexperienced software developers is that
the experienced ones realize when they’re making mistakes.
I think that’s a fair statement. And what happens when the experienced developers say something about the mistakes? They are troublemakers, not team players, sabotaging the project. Steve McConnell’s list is suddenly “academic” and doesn’t take into account the “sense of urgency” around the project. Less-experienced programmers are promoted to lead to punish the out-of-step senior people. As the death march proceeds the experienced developers leave the project (or the company). The inexperienced gain some experience – all of it bad.
Even experienced programmers with ten or more years in the business may never have worked on a successful software project in their career. Most programmers don’t know what a well-run project looks like, so every proposed solution seems equally valid.
However, these mistakes are dangerous because they each have a price tag, in dollars, people, or project success, associated with them. What’s the price of undermined motivation? Or confusing estimates with targets? How much wasted effort/overtime will go towards fixing bugs because of unclear requirements? How much money are you (or your clients) spending on rework? These things matter especially in cases where you have a fixed budget or contract. Cost overruns can be very dangerous, wouldn’t you say?
Interesting post and comments. I have been in the pro s/w biz for 17 years and still write code daily (C# by day, IronPython by night). I have been on at least 30 projects over this time frame. Some successful, meaning they made it into production and some not so successful (i.e. never made it to production). That would be my criteria for success.
Not one of these projects was on time or on budget and I can almost name (getting old) which project(s) mapped to which mistake(s) – all 36 and them some. Software development to professional developers seems somewhat straight forward, but to anyone outside this domain, it is a complete mystery, voodoo, or magic.
Even amongst software developer’s we can’t agree on the right approach to designing software. For every requirement there may be 101 ways to design it and for each design there maybe 101 ways to implement it. Toss in the variability around tools/languages and people and is it any wonder that things go wrong?
I used to be an Agile, XP, etc., SEI CMM, ISO 9003, etc. type of guy in various orgs and in the end, I would deem success is that you got your project/product into production by any means possible. I have yet to see one approach better than any other. In fact, I have had more success in just outright gluing a solution together made up of parts/components/source searched on Google. Sad isn’t it? And I am a big fan of industrializing software development!
As John Walker, inventor of AutoCAD in 1982, said, “Absolutely the only way I know to succeed with an innovative product is to throw something together quickly, push it out the door, persuade some lunatic early-adopters to start using it, and then rapidly evolve it on a quick turnaround cycle based on market acceptance and driven by a wish list from actual users.”
In a lot of respects, I believe that still holds true today, some 25 years later. What does this say about our profession?
I think the number 1 is always communication. If the communication breaks down, the project is doomed. If you have good communication between each of the people of the team, then you can deal with the other 36 problems.
The only issue with your comparison is the pic you posted! Who would NOT want to be Gilligan stuck on that island with Mary Ann and Ginger (in swimsuits to boot)???
Can someone explain to me why Research oriented development is bad? Does it mean that researching new technologies while developing is bad or does it mean that developing your product as a “research product” is bad?
Research is a great thing - it just means don’t go pinning the success of your project down to assuming you can invent some great new technique within a [small] period.
For an example, take a look at the vista timeline… Initially it was crammed full of great new technologies and gradually kept slipping cos they weren’t working and then they pretty much all got stripped out of the release and everyone laughed
This is the phenomenon McConnell likens to Gilligan’s Island.
The only difference is that unlike Gilligan who’s stuck in a tropical paradise with the likes of Mary Ann and Ginger, the developer is stuck in a flourescent lighted cubicle with other sweaty engineers.
Like with most things though, it’s easier to point out the flaws with the development process - and playing God over idealistic approaches can also get a bit too ideological as well.
As a developer, I feel I have to be a frickin theologian sometimes to join the cult of “good software development”. My quote comes from Frank Zappa - Joe’s garage:
“After all, all I ever wanted to do was to play my guitar like rin-tin-din-tin-dinny-dee-duh-deedle-deedle-dee…”
I define success as a project that has met the customers needs and provided a positive net value economically to the company.
I don’t put much stock in budgets or deadlines. When the original estimate was done for the project, it was fairly accurate to what eventually happened, but the project sponsors, in order to get the project approved, cut the time and money in half. Naturally, this resulted in lots of stress, and extensions, and so on, but in reality, this was really just so much theater. Not for those of us slaving on the software, and trying to be heroes, and feeling there was no communication, and all the rest, but for the managers, this was how they felt they weren’t wasting their money. It allowed them to maintain (or at least the feeling of) control.
Ultimately, I think the project was successful just because there was a real business need for the software.
The really sad part is that even if we get it figured out and finally get off the island, we just hop on another cruise and get stuck on a whole new island. Wait, maybe RoR is the solution.
I gave a speech last night about the classic mistakes (it was the first speech of my life!) and when I came back home I opened my RSS reader and I saw your post on the same topic. What a coincidence! Classic mistakes still happen in our lives and they still have a huge impact on the projects’ schedule and on the overall quality of our products.
I am very glad that Steve decided to re-evaluate them. It was just about time! Meanwhile, I decided to start a series of posts in my blog on the subject and I will be glad if you take a look on it and give some comments.
“I’ve increasingly come to believe the only difference between experienced and inexperienced software developers is that the experienced ones realize when they’re making mistakes.”
I am reminded of the old saw, “Engineering experience is proportional to the dollar value of all equipment destroyed.”
Humans learn by trial and error, over time comes experience by armoring against these conditions (and lots of overtime). However its just the nature of our industry, many times its charting new ideas and new systems that are advancements, its not always pretty.
In fact if you ever wake up in a project that doesn’t have some of these problems, you are dead or dead man walking and you have just lost your mind.
I don’t want heroic programmers and innovators, I want careful, conservative spoon fed slackers.
Paul Allen and the Woz were Batman. And when they left Gilligan’s Island the show was over.
As I make money from fixing broken projects, I suppose I should be glad that people don’t take enough notice of McConnell.
There are other amusing books which are good for specific things (eg Brooks’ MMM / Silver Bullet, or “Deathmarch”), but McConnell is broader and more practical.
The root cause of most project problems I’ve had to fix has been stupidity. Sometimes it comes from hubris; sometimes it’s naivety; other times corruption. Most failed projects have failure written into them from the start.
I’m a game-player, so I don’t do projects which are bound to fail.
I’d much rather wait until failure, then either shut the thing down or save it depending on the nature of the failure.
Last summer I read the “The Mythical Man-Month” by Frederick Brooks Jr. (first published in 1975). I am amazed at how true his book is today was it was when he first wrote it.
Today I still see all those problem, (and those 36 points described above). I think the number one and number two problems of failed projects are
communication (or lack there of)
and
honesty. Both talking to management and honesty from management.
