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.
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).
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.
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.
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 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?