Escaping From Gilligan's Island

I find it helpful to revisit Steve McConnell's list of classic development process mistakes, and the accompanying case study, at least once every year. Stop me if you've heard this one before:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/06/escaping-from-gilligans-island.html

I respectfully question your definition of ā€œsuccess.ā€

The definition of success is a legitimate concern, as multiple commenters have pointed out. Iā€™ve struggled with this before:

I read ā€œresearch-oriented developmentā€ as "weā€™re not really sure how it works or how we can make it work, but Iā€™m sure weā€™ll figure it out as we go along."
Put that way, it sure sounds like a classic case of running face-first into the fantasy/reality impedance problem.

Gilliganā€™s Island? Maybe, but itā€™s more Twilight Zone - itā€™s entirely possible youā€™ve contributed to a flaming wreck so awful that you wish you could sneak into the source repository and erase your initials and any trace of your existence from, but it somehow manages to make money in spite of itself and the users are happy. Itā€™s also possible that youā€™ve coded up a gem that makes nobody but you happy. Which is the success? Which is the failure?

Without an accurate taxonomy for such fundamentals itā€™s little surprise that software engineering has advanced little since ā€œThe Mythical Man-Monthā€ in spite of brilliant minds tackling it.

Iā€™m dealing with 28 out of 36 mistakes listed - what are my chances of successfully finishing this project :slight_smile: ?

In a lot of ways, I think ā€œRapid Developmentā€ has stood the test of time rather better than Code Complete. The stuff about mistakes and risks is simply brilliant.

The biggest problem Iā€™ve always seen is doing too much at once. I find that projects work best when you try to do a few limited things and do them well. You can always add features later, but do what is absolutely essential and release now, early, and often.

The big difference between a beginning developer and an experienced one is that an experienced one will think about how their code may change in the future. They already thinking what types of changes and modifications that will be added, and write the code to make doing those modifications easy. Beginning developers tend to write their code as if it will never change.

One of the biggest ironies Iā€™ve discovered in programming is that my best code is when Iā€™ve lost all my work and I am forced to rewrite it. The rewrite is always cleaner, smoother, and faster than my original work. There are times when one should look at your code, and simply decide itā€™s time to put the effort in not simply patching it, but rewriting it. If you are finding that each new change is causing more bugs than you are fixing, itā€™s time to think about rewriting.

If you look at it, it seems to me all of the categories ultimately are sub-categories of the People Mistakes category. For example, ā€œresearch-oriented developmentā€ is a direct side effect of what might be called CV (Curriculum Vitae) Syndrome - the desire of developers to work on the ā€œlatest and greatestā€ stuff so they can keep their resumes up to date with the latest or most in demand buzzwords. This seems to be particularly a problem in the Microsoft space.

You can be pretty certain that many web developers are working in a little ā€œAJAXā€ into their webapps, even when the approach is not indicated (like a small department level, light load intranet app with basic data entry), just so they can get experience with the technology and put it on their resume.

David hit it right on the head when he suggested that you

do what is absolutely essential and release now, early, and often.

That is a guiding principle for a lot of (successful) software projects - in both the open source and commercial space. Granted, in order to adhere to that advice youā€™ll need avoid making about half the mistakes on McConnellā€™s list.

and yet, iā€™ve seen and been a part of more then a few projects which suffer from several of those ā€œclassic mistakesā€ and yet they still succeed brilliantly. go figureā€¦

Iā€™ve worked in a few large consulting companies in my time.

The problem is management has no incentive to care if a project succeeds or fails. Since they donā€™t have the ability to deliver, they concentrate on ā€˜managing upā€™ and rely on having moved on before the inevitable failure. At these large consulting companies progress is measured by brown-nosing, not results, and the more incompetent and snake-like your nature, the higher youā€™ll rise.

What baffles me is why companies carry on paying them. Unless itā€™s people at those companies (and especially in government departments) who hope to get on the gravy train themselves.

One of the worst problems I deal with (and which tends to hit a few of the items on the list) is the idea (from managers) that we can develop a project completely internally, without input from the potential customer(s), surprise them with it, and then, somehow, get them to buy it at a price that covers the development costs, overhead, and some amount of profit. Usually, at best, the product becomes an internal tool thatā€™s useful for improving our ability to satisfy the needs of the customer; at worst, though, we end up with budget issues and no cooperation (either internally or from the customer) which leads to an incomplete project that eventually gets cut (after increased time and spending to somehow fix the problem).

Iā€™m also continually amazed at how little input people are willing to give on the user interface of a program in the design phase of a project, and yet theyā€™ll still have twenty ā€œlittle thingsā€ they want adjusted in the interface when you finally get a feature complete build in front of them (and then be amazed that what they think of as a minor interface adjustment turns out to be a completely new feature that requires changes to the underlying code). Then thereā€™s the idea that we can somehow fix someone elseā€™s closed-box software, or give a reasonable estimate of the value of the source code for that software vs. developing a replacement in-house (which we may have to do anyway after purchasing the source for the previous software).

1 Like

Itā€™s weird. I have worked on projects and I am currently working on a project where many of these mistakes are made. In my current position Iā€™ve tried to talk to people about it. The other developers nod their heads in agreement but do nothing. Management just doesnā€™t listen at all. We have no clear product concept. Not a single page of documentation, and weā€™re going ā€œliveā€ in a week from now. Yeah we have something but 24 hours after a big meal we can all produce something that smells better than what Iā€™m staring at.

Being aware of these mistakes and the problems they cause is one thing. But itā€™s all really pointless when one is powerless to do anything about it. In the end I give up like the other developers around me. I bury my head in front of the compiler, and hope that I can find a new job before last nightā€™s processed dinner hits the fan.

Iā€™ve worked in a few large consulting companies in my time.

The problem is management has no incentive to care if a project succeeds or fails. Since they donā€™t have the ability to deliver, they concentrate on ā€˜managing upā€™ and rely on having moved on before the inevitable failure. At these large consulting companies progress is measured by brown-nosing, not results, and the more incompetent and snake-like your nature, the higher youā€™ll rise.

What baffles me is why companies carry on paying them. Unless itā€™s people at those companies (and especially in government departments) who hope to get on the gravy train themselves.

This is a very timely posting. A few days ago I posted an update to my classics mistake list on my blog, 10x Software Engineering. Over the 10 years since Rapid Development was first published, weā€™ve identified a few more mistakes, and weā€™ve also refined the descriptions of a few others.

http://forums.construx.com/blogs/stevemcc/archive/2007/06/15/Classic-Mistakes-Updated.aspx

My company and I are conducting a survey to assess just how classic these mistakes are, i.e., to assess the frequency and severity of occurence. Weā€™re looking for volunteers to fill out the survey.

https://vovici.com/wsb.dll/s/10431g2996e

Thanks.

1 Like

The big difference between a beginning developer and an experienced one is that an experienced one will think about how their code may change in the future. They already thinking what types of changes and modifications that will be added, and write the code to make doing those modifications easy. Beginning developers tend to write their code as if it will never change.

I agree with your picture of the beginner, but Iā€™d add another step: The beginner writes code that works now, but is hard to change tomorrow. The experienced developer writes code that works now, can adapt to a few changes tomorrow, but fails a week later, due to too much code that was writte to provide more flexibility.

The expert writes code that works today and refactors it tomorrow and every time he needs to add something, always aiming for the simple and clean solution.

Its easy to find projects that are overloaded with so much unnecessary flexibility that it is impossible to maintain them.

Great stuff. Took the survey yesterday. Everyone should, too.

Recently, my management team made no less than 50% of the classic mistakes and a few of the new ones. And guess who got a promotion? Hint: not the developers.

Hopefully, weā€™ll someday reduce the classic mistakes list to an ancient relic of software engineering history.

I just completed a large scale enterprise software development project for a client. It took over a year. We were on time and under budget with a final bug count that was in the low teens. And Iā€™m talking minor stuff here. The client is absolutely ecstatic and singing our praises all over the place.

The secret? Just two decent programmers. Iā€™m convinced that two good guys can produce a working system when an entire team cannot. The average computer programmer is a real dud and can bring an entire team to its knees. The only way to protect yourself is to use a small team of carefully chosen individuals. As soon as the team gets larger than two people, the probability of bringing in someone who negatively impacts the project goes up dramatically.

Iā€™ve seen it time and again. If you want to be successful in the software business, think ā€œsmallā€.

I think this is good. Basically the bottom line is, pay attention to every detail, large and small. Developers like to just get the big things out of the way and ignore the small details. Eventually the small details pile up into more big details, so itā€™s easier just to get the small details done at the same time you are doing the so called big details.

I was horrified to read this post. Why? One word: Conviction.

I should know better.

Where does the line form to turn in your Qualified Software Professional membership card? I donā€™t think I deserve to carry one anymore.

http://eddiesguy.blogspot.com/2007/06/creating-my-own-personal-hell.html

I have no idea what is meant by most of these ā€˜mistakesā€™, or why they are so dangerous. Iā€™m on a successful project, live for 2+ years, and we have many (at least as I understand them) of these mistakes. Care to define these?