August 3, 2009 at 12:39 pm
I think the whole thing is based on a set of common misconceptions on what a craftsman is vs what an engineer is, and on an overly broad set of generalities about software.
In other words, "it depends".
Engineering is about design, crafting is about making.
Plenty of engineers never weld a single joint, cut a piece of wood, poor a gallon of concrete, etc. Many craftsmen never draw a single blueprint or other design. Some people do both.
I know an electrical engineer who designed wiring diagrams for military aircraft. He never handled a single actual wire in a production aircraft once, but nobody would argue that he wasn't an engineer.
I also know a seamstress who uses patterns to make shirts and such. Can't call her an engineer, really, but definitely a craftswoman. (Or craftsperson if you're more PC than I am.)
Many in software professions are both. Design and write code.
Some of the projects will be the Golden Gate Bridge, and require a tremendous level of planning and precision, and some are going to be laying a plank over a stream. (Engineering process: "Should I use a 2X4 and assume people have a sense of a balance and are light, or a 4X12? Hmmmm....")
It's not about whether it's engineering or not. It's about the basic law that any time precision exceeds accuracy, you're wasting effort. Too many software projects have this tremendous precision, "these deliverables in 42 programming-man-hours, these in 15 after that, blah blah blah", and their accuracy would really only support something like, "It'll probably take me a week or two. Better call it three so that we can run over a bit and not upset the managers, and we'll look good if we finish before deadline anyway."
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 3, 2009 at 1:53 pm
Although I'm willing to whole-heartedly agree with many of the arguments in the article, I'm afraid I have to come to a very different conclusion. My previous job was working at one of the Department of Energy's Nuclear Facilities. No one ever thinks of these places, even when they're in your own backyard, but everyone knows instinctively that the US nuclear arsenal is created and maintained somewhere. I worked at the one in South Carolina.
Some of the most important software we wrote was the software that actually controls the automated processes in the creation of refined uranium, plutonium, and tritium (a form of hydrogen used to make the big bombs). And it may surprise you to know that all of these processes cost a considerable amount of money. The two things that all of the nuclear weapons automation software all have in common is that they all have a rather large, negative profit margin; and they all are far more critical than even your child's upbringing -- when something goes terribly wrong, it can wipe out all of Augusta, GA, Savannah, GA and all the towns and cities along the river between, and render them uninhabitable for 1000 years (or more).
What the author should have concluded is that we do an exctremely poor job of scaling our controls to the relative importance of the software project. This was the impetuous for creation of the Software Engineering Body of Knowledge. Too many people in software engineering want controls on everything because. Not because of something, just because. They see the same amount of controls on a mileage reimbursement calculator utility as they do for the software that adjusts the reactor control rods to prevent a reactor from going critical as equally important. They're not.
The SWEBOK was created along the concept of the Chinese proverb that to succeed at something, you find people who know how; but to excel at something, you find people who know why. I want very much to agree with the author, because I know only too well the heavy handed approach that managers have in gathering knowledge. And the less they understand the process they manage, the more control they must maintain to feel comfortable, like a drowning man grasping at floatsome. But instead, I find the author's scope of experience to be too limited to conclude such a wide-reaching conclusion. Business applications are not all applications.
August 3, 2009 at 2:03 pm
A bit off topic here, but witchdoctors and medical doctors aren't really from the same branch. Witchdoctors were pioneers in modern medicine and had many, many success stories, based on an incomplete and often dangerous scientific process. Try it, if it kills them, don't try it again. If it makes them better, remember the symptoms and try it again.
Medical doctors, by contrast, practiced a medeavil form of medicine that science too often continues to this day -- it should work this way because it makes sense to me, so continue this treatment in spite of the number of deaths that insue.
As a result, early medical doctors had a abysmal success rate and few adherents. They would likely have died out had it not been for their cure for female paroxisms. Of course, without a male organ, everyone instinctively understood that women did not find any joy or pleasure from intercourse. So no one ever bothered to test this universally obvious statement of fact. Modern medicine can track its success with the success of the modern vibrator, which was originally invented by doctors to alleviate their sore fingers in their treatment of female paraoxisms, because even though they were at a loss to understand the cause of the disease, the treatment was well established -- digital message of a lady's netherparts.
I guess I can see some relation here to Software Engineering -- if you're creating serious software you shouldn't be jaggin-off. 😀
August 3, 2009 at 3:39 pm
rboggess (8/3/2009)
Although I'm willing to whole-heartedly agree with many of the arguments in the article, I'm afraid I have to come to a very different conclusion.[snip]
But instead, I find the author's scope of experience to be too limited to conclude such a wide-reaching conclusion.
Srsly? You find Tom Demarco's "lack of experience" disturbing? Or Jeff Atwood's experience too limited to agree with his conclusions?
:hehe:
[Where's my ROFLMAO emoticon when I need it?]
I guess I'd prefer to work with all those "inexperienced" types like Tom and Jeff...
I could understand (maybe) if you were talking about Steve Jones and I just misunderstood... but I'd love to work on a project with Steve nonetheless!
😛
August 3, 2009 at 3:53 pm
rboggess (8/3/2009)
A bit off topic here, but ...[snip]
I guess I can see some relation here to Software Engineering -- if you're creating serious software you shouldn't be jaggin-off. 😀
:w00t: I'm going to medical school as soon as I find my time machine. :hehe: :crazy: I can just hear all the unposted comments about "taking it in trade". :smooooth: Then we just had a meeting where we were discussing if certain project management aspects are just so much "mental masturbation".
This is shaping up to be a great week and it's only Monday. 😛
ATBCharles Kincaid
August 3, 2009 at 3:54 pm
I think Mr. Reed and I might drive each other crazy, but it would probably never be boring. Actually with Mr. Ranger and his SQL Ranger credentials, I think I'd be working for him!
It's easy in a large budget, highly important area to say that engineering works better and should dominate the software process. I think it should, just like the shuttle software if written extremely well.
However in most of the software world, we have less time, money, resources, or even direction. We're swatting at mosquitoes trying to figure out what to do. Being a craftsman, even an ignorant craftsman, works better. As long as you try to get better over time.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
August 3, 2009 at 4:00 pm
David Reed (8/3/2009)
Srsly? You find Tom Demarco's "lack of experience" disturbing? Or Jeff Atwood's experience too limited to agree with his conclusions?
I didn't say "lack of experience" -- I said scope. :rolleyes: He's making a global conclusion when he hasn't worked in all areas golbally. So, in a word, "yes". You can't work everywhere in the US and conclude you know everything about working in the whole world. Sorry.
If you disagree, you're welcome to move to Aiken, SC after they remove all software controls from their nuclear processing facilities at the bomb plant. Might help you save a bit on lighting bills. :satisfied:
August 3, 2009 at 4:06 pm
rboggess (8/3/2009)
David Reed (8/3/2009)
Srsly? You find Tom Demarco's "lack of experience" disturbing? Or Jeff Atwood's experience too limited to agree with his conclusions?
I didn't say "lack of experience" -- I said scope. :rolleyes: He's making a global conclusion when he hasn't worked in all areas golbally. So, in a word, "yes". You can't work everywhere in the US and conclude you know everything about working in the whole world. Sorry.
If you disagree, you're welcome to move to Aiken, SC after they remove all software controls from their nuclear processing facilities at the bomb plant. Might help you save a bit on lighting bills. :satisfied:
I would equate writing software for controlling nuclear processing facilities to writing code for the Space Shuttle. It has to right the first time. The controls used in writing the software for the Space Shuttle is probably the same the use in writing the control software for those facilities. Requirements well defined, software well tested and QA'ed, change control strictly followed, and solid documentation for all of it.
Unfortunately, in the business world it never seems to be that straight forward.
August 3, 2009 at 4:15 pm
Lynn Pettis (8/3/2009)
Unfortunately, in the business world it never seems to be that straight forward.
Which is why I'd very much like to agree with his conclusion. That all software should be implemented like a craft. I do agree with the sentiment. Even in my old job.
The controls used in writing the software for the Space Shuttle is probably the same the use in writing the control software for those facilities. Requirements well defined, software well tested and QA'ed, change control strictly followed, and solid documentation for all of it.
Unfortunately, this very much wasn't the case. Too many controls on utilities, too many management controls on all software, and too often, a poor understanding of what eacy piece's purpose resulted in software requirements that were as weak as "software will do stuff". It was one of the many varied reasons I left. But that's why I think the emphasis should be on the right controls, not on no controls. Removing the excess allows greater focus on what's important, or critical.
August 3, 2009 at 6:25 pm
Just left a large team meeting which discussed lots of prioprietary Office 15 planning things, but one part of the perspective that the O15 planning team tries to keep fixed in their minds as they work is that they are:
Designing Software for 500,000,000 People
Something to think about when considering how much upfront effort is justified.
:hehe:
August 4, 2009 at 10:19 am
From the article:
I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability. Consistency and predictability are still desirable, but they haven’t ever been the most important things.
For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal.
The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.
I don't know about the rest of you, but after spending years of tooling around in CASE tools producing data flow diagrams and literally decades of either producing or reviewing reams of design documentation that never said anything that wasn't intuitively obvious, reading quotes like these from one of the founders of the method is infuriating. This reminds me of the admission by Thompson, Ritchie and Kernighan that C and Unix were an elaborate prank, except that this isn't a joke. My opinion of ordained methodologists who spent all their time producing books and presentations instead of code has been sinking steadily since the demise of CASE and the self-destruction of DeMarco's partner in crime, Ed Yourdon, and this article is just another data point mapped to that plummeting curve. Perhaps he should've titled his article "Oops, Never Mind".
October 25, 2009 at 10:04 pm
Interesting starting point (thanks, Steve) and some interesting comments.
I agree with most of what Tom DeMarco says, but two things I don't agree with: that his discovery that the obsession with control is silly means that software engineering is dead (and perhaps should never have lived) and with his suggestion that this might push us towards Agile methods - since "Agile" is a very dangerous combination of two things: (1) simple pragmatic rules about software development that the computing professions in general knew and understood at least as long ago as the mid 60s (my vintage) and that some good people knew a long time before that (three examples: Edsger Dijkstra, John McCarthy, Jules Schwartz); and (2) ludicrous sound-bytes to support the hype and provide the empty suits with whatever justification they need for their lunatic control-freak destruction of all rational development processes.
I think that DeMarco's new realisation is really caused by one very simple thing: we have, in our profession, a very large :angry: number of "managers" who haven't a clue what their staff do and want lots of meaningless metrics to enable them to fool themselves into thinking that they understand what's going on.
For myself, I claim to be three things: a computer scientist, an engineer, and a craftsman. Computing (IT if you must, but I think the use of the term IT is part of the problem, not part of the solution) is a very young game and I don't think we have reached the stage where anyone can be just one of those things, except perhaps in some small niches (but being just two of them can work very well - Dijkstra for example was a scientist and a craftsman, but not really an engineer; Jeff Moden is, I think, a craftsman and an engineer - he wants to produce elegant things but he also wants to measure and understand what their limits are). The trouble is that many people in computing are none of those three things: they don't have the mental discipline to be scientists, they have no idea what an engineer is, and they are too stupid/lazy to be craftsmen. I might go along with Jeff Moden and introduce the term "crap" into the discussion here, say that what these people produce is crapware and that they should be called crapsmen, but our profession already has several names for them: they are called project officers, project managers, and programme managers and, regrettably, they are often called software engineers. It would be nice to have a term for the negative contributors, but changing the job title of 75% (or am I too optimistic?) of our profession would be hard ;-).
Software engineering mostly doesn't work for two very simple reaons: first and foremost because its practise has been banned by management in most companies; and secondly because many members of our profession (not just the managers) don't have the capability to do it (they are missing critical qualities mentioned in Dijkstra's list of unpleasant truths - the relevant bullet points from Dijkstras note are :- .
# Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
# The easiest machine applications are the technical/scientific computations.
# The problems of business administration in general and data base management in particular are much too difficult for people that think in IBMerese, compounded with sloppy English.
# About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.
# Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
# By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support.
# In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.
Perhaps today we should substitute C or C++ or C# for Fortran. While the management insists on programming in these archaic languages instead of something useful like Haskell of F# or an ML dialect, most of the employees have never bothered to learn anything useful anyway. How many people, DBAs included, even know SQL (which is maybe the most used language that isn't really hopeless)? I've seen plenty of evidence that DBAs mostly don't learn it beyond an absolutely trivial level.:(
Tom
October 26, 2009 at 7:15 am
Interesting points, Tom.
I think you have hit some good thoughts here, though I'd disagree that most people can't learn to program better. I do think many are lazy, but I also see so many people attending events like SQL Saturday, and coming here, trying to learn more. Trying to do better.
I would agree many DBAs don't learn SQL that well, often not needing to. Or not thinking they need to. They survive with mediocre skills. I do also think that some of the high end SQL I see written by Jeff and Itzik is beyond many people. That's a little sad, and I hope that I'm inspiring or motivating people to try and do better.
It is sad that many developers think they have no need for SQL. They want to go to an ORM rather than build a skill in another area.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
October 26, 2009 at 7:29 am
Good points, Tom.
The problem isn't the people trying to learn "software engineering" or "software crafting". Not directly anyway. The problem is the same one I see in just about every field these days: Nobody ever taught these people how to learn.
According to surveys, 90% of American high schoolers think it's okay to cheat on tests and/or homework. Apparently, nobody ever told them that there is no possible way to cheat when writing computer code, or anything else productive. It's even hard to "copy someone else's hamburgers" if you can only hold down a McJob.
But that's just the lead-in to a book-long rant on my part, so I'll shut up now.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 14 posts - 31 through 43 (of 43 total)
You must be logged in to reply to this topic. Login to reply