Revisiting The Facts and Fallacies of Software Engineering

Some additional thoughts:

  • take advantage of tools and methods like version control, continous integration, wikis, etc.
  • developers make bad testers (at least on the long run)

By the way, keep up your self linking. People that dont like the links dont have to click on them. To the others this is a great service.

Great post. And completely agree with Jay’s first response on here. This is “is a great bullet point list that non-software engineers should read”. I work as a tech pm in an ad agency, so I’m somewhere between the developers and the rest of the company. Reading through this was like a check list for where we go wrong on so many projects. While it’s great to see acknowledgement on the outside that other people hit the same frustrations I do, my first reaction was how do I get the people I work with, the creative people, the strategy people and the sales people, to appreciate and understand these issues.

We’ve hit them so many times yet still I see timelines and budgets with no time for fixing bugs or maintaining code beyond a launch date and when things invariably go wrong the solution is to throw more people at the problem meaning it can branch into several more problems and cost yet more money.

Would be great if anyone is aware of any resources out there that discuss overcoming these problems. Or should I just buy the book?

I see you added another side ad. Is Jeff a full-time blogger now?

I’m a definite Bob Glass fan-boy, I always dive for his article in the Communication of the ACM. If we could only get all the Project Managers and CXO’s of the world to read this book along with Peopleware…

  1. There is a disconnect between software management and their programmers.

I noticed that maybe half of the 55 facts apply to management more than to the programmer. That is one reason why PaulG’s comment “Its frustrating to see us all bitching about the same things we were bitching about 25 years ago…” is true and will remain true.

I’ve tried managing a medium software project and it was hard. But what made it hell was the governance that the Corporate IT organization had established. They used the toll-gate method (kind of like the waterfall, but more starts and stops) where you had to estimate cost at Scope, Requirements Design before you could begin Construction. And none of the estimates could vary more than 10%.

I appreciate Coding Horror because I want to do what I can to be a better programmer (and its usually really entertaining). Could someone get a “CIO Horror” blog or write a book to get the guys at the top in-line with reality?

For what its worth, my manager and his manager are awesome technologists and managers. They represent the 2% of management that get it right. (I made the 2% up, but it feels about right.)

Software Engineering is a Joke.

Check this out this statement:
http://dewitters.koonsolo.com/sejoke.html

Sooo true; true engineers try to find that “Engineering” property in software because their are used to it in their other professions, and can’t accept how different creating software is, once it exceed certain size. (not talking about micro-controler code here)

The thing that sticks out in that list of items is that they are all negative statements. I do hope those sections are constructive instead of just problem statement after problem statement.

Your book isn’t very interesting if it only says “don’t do this, don’t do that” – it must tell me what DOES work, and I argue that finding out what does work is where the value is.

Lord, your hypocrisy is amazing, Jeff.

You get on Paul Graham’s case because he came off as … gosh… how did you put it… “Participatory Narcissism”.

Then you go and start an article with this: “I realized that I’ve written about almost everything in this book by now.”

This is no different than what P.G. does, except for one thing… P.G. is encouraging people to help themselves and you are writing prescriptions for us (apparently) ignorant masses.

Your blog’s a joke. I’m going to have to unsubscribe.

I’d add this to Glass’ list:

The cost savings of outsourcing are usually overwhelmed up by the friction it adds to any software development process.

@Jay: amen, brother. I’m in the middle of fixing a heavily multithreaded C++ app written by people who didn’t quite understand multithreading or C++.

I’ve completed (much better) stuff in two hours that takes other people 2 weeks to finish, does that change the rule to “up to 40 times better”?

“there are no “stupid” people or “idiots” in this industry.”

Hahahahahahaha.

Regarding point 2. The best programmers are up to 28 times better than the worst programmers.

The amount of times i’ve fixed and still have to fix stupidity errors caused by useless programmers is insane.

BTW, These people are the ones that say they dont touch a computer outside of work hours.

I belive programming is more than just a 9-5. Its a passion that you need to keep up with. Our landscape changes daily and being on top of it requires a certain interest in the subject.

Such as reading blogs like this. Sure its not a definite sign of a good programmer, but its a good way to weed out a lot of useless ones :slight_smile:

I appreciate Coding Horror because I want to do what I can to be a better programmer (and its usually really entertaining). Could someone get a “CIO Horror” blog or write a book to get the guys at the top in-line with reality?

This is an interesting comment, because that’s essentially what Steve McConnell does now at Construx. Many of their seminars are targeted toward powerful CIO level people, and I always wondered why. Maybe now we know.

+1 for “Who cares if we call it engineering or craft?” It’s both.

As a new subscriber the only thing I don’t like about the self-linking is that it takes an hour to make it thru a post. Love the blog Jeff.

@Eber, with all your extra time maybe you should work on your blog. It looks a mess in IE.

I recently gave this book as a gift to a project manager friend as she moved to a new company. I thought the material was broad enough to give a good idea of the issues involved in software development without requiring the reader to be a hardcore techie. This was one of the best books on software I’d read in a long time, for all the reasons listed in the above comments and more. I’m going through Michael Feathers’ “Working with Legacy Code” book. So far, it’s turning out to be just as good as this Glass book, but with a more practical day to day impact.

Great post. I’d also recommend these books:
The Pragmatic Programmer
Code Complete
Smart and Gets Things Done

My thoughts on some the one-sentence summaries:

The most important factor in software work is the quality of the programmers.

I totally agree. In the end, people do the work, not a programming language, process, or technology.

The best programmers are up to 28 times better than the worst programmers

I agree that great programmers are many times better than others. How’d they come up with 28? Must have referred to some actual study.

Software estimation is usually done by the wrong people.

Some companies allow engineers to estimate the time to do their work and I guess other companies don’t. If an engineer is not allowed to estimate, then I’d recommend finding a better job that does.

'I’ve been accused of gratuitous self-linking in the past, so I won’t clutter up the rules with dozens of links to my old posts on these topics.'
Jeff the only people making these kind of complaints are people who don’t like you or your blog, don’t listen. It’s a great way to introduce new vistors to the depth and quality of your writing. If it’s relevant then it makes sense.

“Yes, you HAVE pasted other people’s thoughts on all of the subjects covered in this wonderful book. And then linked to your old posts about the exact same things over and over again.”

I enjoy that Jeff shares what he reads in books, comments and wherever and adds his thoughts to it. It’s like reading concentrated wisdom.

I’d read this blog even if it was all quotes. It’s still been filtered by someone with a clue.

@collin

Where d’you get your troll costume? Think to yourself, would you say this to someone’s face? If not it’s a troll.

Paul Graham is the one who first pointed out that “software engineering” is a craft (at least to me) in “Hackers and Painters”, which is all available on line. I don’t get any conflict with what Jeff and PG say. Just different perspectives, different perspectives that help us all understand things better.

I don’t remember Jeff having a go at PG, but hey, you put yourself in the public domain you will get criticised. So what? They are both trying very hard to help the rest of us make sense of things, and doing a good job.

Let’s see what you have to say Collin? Eh? Then maybe we can make our minds up about your contribution.