An interesting set of topics for discussion, but at a quick glance, it seems to make a big point about programmers and a further related point about management.
What about design?
Surely that deserves more importance in the quality and functionality of delivered software
I found all facts quite interesting, but I got stuck with quality:
“47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.”
What is quality then? How do you measure quality?
What are the attributes of number 46.? Aren’t those attributes to be specified anywhere and then we have to meet these requirements in the process?
This sounds quite esoteric to me.
@Mitch,
Your concept of real engineering is flawed. The best engineers I know tinker. What you perceive as real engineering is the outcome – it’s the finished product.
This fallacy of engineering taught in academia is flawed. This is one of the reasons Toyota is still beating the pants out of us, even on our own soil using the same American factories and using the same American workers. Toyota gets engineering.
–Stephan
@Stephan - I have worked with electronics engineers and we built real products - http://www.develcon.com/ These are not tinkerings otherwise we would not still be in business 25 years later.
I perceive engineering as the design of software. I believe what Jack Reeves believes - http://www.developerdotstar.com/mag/articles/reeves_design_main.html
And if you must know the truth about software engineering http://softwareindustrialization.com/TheTruthAboutSoftwareEngineering.aspx
Which post was it that said software engineering was like building a bridge… on jupiter with materials that didn’t exist five years ago?
If you want software engineering to be as disciplined as electrical or mechanical engineering, we’d all still be programming COBOL on mainframes. Computer science software development have evolved too quickly for standard engineering practices to emerge. Some of the best practices of only 10-20 years ago have become bad practice today (Jeff - that’s a perfect topic for another article). I don’t think this phenomenon occurs in other fields of engineering, at least not on this short a timescale.
hmm… sounds like a good read. off to amazon…
There are a lot of sites out there showing book video. BookVideoTV, BookTelevision and of course CSPAN, but I like how BN.com and Reader’s Entertainment TV have specific genre channels and original shows. There’s just more to see and I can be specific in what genre I’m interested in. Anyone else watch online tv?
Excellent post. I have learnt a thing or two so thank you!
I actually read this book.
@Gunther and others: fact 30 is about COBOL being a ‘bad’ language for business data processing, being pretty old and ‘laughed at’. But actually (and factual) it’s not dead yet, and still no demise in use is seen.
@Tony: Yes, fact 45 is a Jevon paradox. If enhancing maintenance can be performed more efficient, there will be a higher demand for even more enhancements.
@Jake: no need to buy the book for that, there are no ‘answers’ to the problems behind the facts.
@Eber: fact 2 is referring to a specific research result. That is the factual information, it doesn’t change because you measured something else.
@Jrgen: don’t worry, that’s Glass getting picky about his personal definition of quality.
Software tools have not fundamentally changed over the years unlike hardware tools.
There are IDEs, but, software tools need to be more CAD-like.
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%.
This is in my top five of software engineering books.
I make a point of skim-reading it once a month just to keep it fresh in the mind the common pitfalls you can make on a project.
The fact it’s such a concise book helps enormously, and it’s littered with research references that back-up each one of his facts or fallacies.
I second Jeff on recommending this book 100%.
Simon.
“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.”
Who cares? That’s what hyperlinks are for. If someone doesn’t want to follow them, they can avoid clicking on them. One great feature of your blog is that you’ve written about a lot of things, and it’s easy to find them from your links. And if I read a post again a year or two later, I’ll probably get something new out of it.
read some of this on the AW website a couple of years ago, good stuff. But how best to get your manager to read it?
The silver bullet has born. Having good processes is the answer to everything. If you have bad people, you can always get better ones with a good hiring process.
And so on. Surely people are important, because without them you can’t do anything - except with automated processes. But processes are the core of everything. For example even a good programmer has a living process: 1) Inhale 2) Exhale 3) Repeat until death. If you don’t breath properly but only in small amounts, your brains don’t get enough oxygen. You cannot be good without exercise processes.
“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.”
Well, that’s how people make money, by re-packaging/re-thinking/re-stating the products/thoughts/statements of others. Everyone is free to do the same, don’t get upset because someone else is successful at it and you are not!
Points 21 and 22 seem to be missing from the list of “55 facts”…