Nos. 5, 6, and (less so) 7 all make me happy to see in print.
Fortunately, while my Overlord is keen on all sorts of New Shiny Things, he usually doesn’t try to make us use them because they’re New Shiny Things, until they’ve actually been evaluated and found to produce actual benefit.
(Of course, when there Iis/i actual benefit, the loss from #6 is more than recouped by the eventual gain.
Those in the Windows world may recall the transition to .NET - or those that haven’t yet made it… what’re you waiting for?)
I do international humanitarian work. Not a coding bone in my body (I topped out at BASIC thirty years ago). Most of that list, with a few tweaks for different practice and jargon, fits the international aid business too. I’m always on the lookout for new framing and new ways of thinking around the problems identified by Glass, so I’ll pick up his book too.
Regarding #7, I’ve found that there are two types of people in the (international humanitarian aid) world: tool users and non-tool users. Non-tool users talk about tools constantly - mostly to explain why they can’t possibly use this particular one on this project because the tool doesn’t do X. Tool users don’t talk about tools except to teach them; they’re too busy using them to get stuff done.
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?
@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.
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.
i dont found anything interesting here
calypsonaveen
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?
@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.
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’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.