Software development and ... mechanical(?!) engineering?
 

I like my Kindle. Love to find stuff there that you don't find in bookstores and probably never will because (a) it costs a lot of money to kill trees, and (b) why bother. (Plus I ride in airplanes a lot.)

I especially like to find books that really make me stop and think, and this is one.

The premise is simple: that computer software is actually a mechanism, and not just that, it's a mechanism that drives itself. In other words, that über-nerd game of Robot Wars, in which two opponents program their robots and then push the "Start" button and from that point on can only watch whatever happens next, really is true. These days we fret about riding down the road in a futuristic car that drives itself, but we've been doing that for years ... and this car has no windshield, no steering wheel "just in case," and no rear-view mirrors. And, in about 70% of the cases, the projects we build as an industry fall short of the mark ... 30%+ are stillborn. Problem.

The notion, then, is that maybe mechanical engineering principles ... certainly, in any case, engineering principles ... should be applied to the building of software mechanisms too. We're endlessly discussing how we should organize teams from day to day, what color we should paint the ping-pong table next to the espresso bar and so on ... as though we would be directly affecting the behavior of whatever it is we build. When, in fact, we don't. Can't. :scratch: There's no driver's seat for an industrial robot, in which the team that built it may sit.

We pratter endlessly about this "methodology" or that one, when it may well be that all of them are missing the point. Talking about things that don't matter to the machine. No matter how we did or didn't approach the task of designing and then executing the work of building that machine, the machine will be driving itself to whatever outcome the outcome may be. Either we designed it well or we didn't; we tested it well or we didn't. We say we're done .. okay, here's the Big Red Button. Push it and see. The "Light (Motor)Cycles" sequence from the original movie, Tron, is true including the breakneck speed.

I'm not doin' it justice, but it sure did make me think.

Spoken like a true realist! :hattip:

You won't get any arguments from me on that; I agree sundialsvcs-

Being a Software Engineer doesn't seem like a walk in the park type of job.

"Software engineers must deal with complex values in attempting to optimize the quality of a product. From the study of algorithmic complexity, we can learn an important lesson."

What lesson exactly is that?

Didn't understand fully until I read this article on Principles of Software Engineering.
It's a tad beyond me BTW but I think it's a good article for folks to learn from.

http://www.d.umn.edu/~gshute/softeng/principles.html

Some folks try to turn "engineering" to mean "hard stuff" ... algorithmic complexity, NP-complete problems ... :doh:

I took a couple of tele-courses at Stanford many years back and when they wandered off into that land, I gave up on that.

No, the argument is that all software-development is, fundamentally, an engineering activity ... and that software development gets into a pattern of repeated failure because it doesn't apply basic engineering principles to the process. And, because it fails to realize that the outcome isn't a direct result of what they do in the act of building it – but rather, an indirect one.

The book explains it better, I guess.

In total regard to the subject I have to give you the "Respect and Recgnition" on it as I lack this experience you have.

This repeated failure that you speak of if indeed is going on it can't be good-

That driving force to produce a product to obtain a profit (Business ofc) Could that be another reason for this failure? Now you got me thinking....people pushing people to provide something in this case (software)not really allowing a Developer the time he needs to proficiently practice his skill to build and what is in demand and being rushed to do it- Another reason for failure; perhaps?

I've seen this practiced all to many times over and over again.
At least in general from what I have observed.

"Managing the Mechanism" looks like a good book-
By reading it I think I'll understand you better--

The "repeated failure" has been documented in the Chaos Report (great name, huh?) put out by the Standish Group over the last decade ... and the results are still the same. But we've been documenting the same thing, and the same reasons, since The Mythical Man-Month, first edition.

Yeah, people put huge effort into building things that they can see. The only folks who start working on anything without a solid plan in place, are either software developers :rolleyes:, or the people who made Home Depot such a friggin' big company. (Hint: professional building contractors don't shop there.)

Carrying the software analogy just one step farther ... how often do we see this: "Do you know what a hammer looks like? (Ooh! You have a hammer-holder certification, cool!) Well then, I'd like you to please start building my house. You can start right now. There's the vacant lot where I want to put my house ..."

I've read plenty of software-PM books but this one makes sense. :eek:

LOL! W/o a plan in place; seen it over and over again!
In my book that's doing a 1/2 aXX job-

Sadly, I used to work there and they (contractors) really do shop there. I had the job at the contractors desk. Talk about a JOKE!

I'll start here for grins and giggles:
http://en.wikipedia.org/wiki/The_Mythical_Man-Month