Hey, I don't usually talk about a book, but I do want to mention this one.

(And yes, full-disclosure, I recently arranged to be able to sell it for a time, because it wasn't getting too much exposure.)

Anyway, the food-for-thought is this: this author says that computer software is "different, very different," because it is: a machine. A self-directing machine. Just as "Eliza" talks to us like a psychologist but isn't really real, computer software does whatever we program it to do but never knows what it is doing. So basically, instead of being just a cab that we're riding in that's being driven down the road by a cabby, this thing is a cab that is driving itself. And so, this is why software projects are so dammed difficult vis-a-vis any other type: because there are no people involved when the project that we've managed finally winds-up in front of a customer.

I know that for a long time I've tried to find a way to explain to people why a computer software project was "hard." Why it took such up-front planning and such testing ... and, why the folks who promised to do it in half the time shouldn't be trusted. But I never found anyone who, like, said it.

Do you agree? Disagree? Thoughts??

Wow...that's deep...

But it makes sense. And I like the "car driving itself" analogy.

Yeah, it really got me thinking in a totally different way, and nodding my head throughout. No one else, so far as I know, is saying this. Nor were they providing pragmatic project management (and software design) advice that wasn't just "snorting PMBOK" or "quoting Agile" ... as though either or both of these were dogma.

Way too many [other ...] books, if and when you finish them, make you think: "you've never actually done this, have you?"

There is something about software ... there is something about software ... that is fundamentally different ... that is fundamentally different. And I think this is "it." This is the sort of thing that we need to be saying to our customers, internal or external, and we need for it to exert a lot more influence on how we scope, design, and execute our projects. We're telling people right now that if we, say, just "re-organize our teams in Agile (tah-dahhhh) ways," magical things will come to pass. Unfortunately, we change buzzwords every two or three years with basically the same result, namely: .. .. And we couldn't say why.

Part of the problem, of course, is that even though people today spend every waking moment interacting with software (and, generally, software of extremely high quality), they don't know how the stuff works. They definitely don't know how to plan and execute a software development project from a business point-of-view. Literally, don't know. We know what we do; they don't. But they do understand what a "self-directing machine" is, and when you cast the effort in that perspective, a lot of things fall into place in their minds (and plans). "Why do you need that much detail?" "Why are you telling me I can't change this, can't have this?" "Oh. That's why. I get it, now."

The light comes on, [maybe] the demands change, [maybe] greater cooperation and business-participation follows.

This little book was apparently languishing in a very obscure corner of epub-only land, almost never to see the light of day. So yes, full disclosure, I am trying to help get it a little more traction and exposure, which I think it richly deserves.

there is nothing better at pounding it in to your head that software is a machine than learning assembly code programming
may be this is why at one time to get a job as a programer you had to be able to program in assembly
even if you were never going to program in assemble or your employer didn't have the CPU you knew
you still had to know how to program in some CPU's assembly code

I read this in about 8 computer books from the 60s

I read those computer-books in the 60's!

But the whole point of the thing is subtly different from that. It has nothing to do with any particular software implementation language and everything to do with "software, itself." We're "manging the process" as though it were a human process. But it isn't. The actual encounters between software and its clients allow no human intervention or "management" at all.

We build the ships, launch them beyond-reach with not a soul on board and not so much as a remote-control, and wonder(?) why more than 70% of them sink or founder.

We concoct all sorts of "methodologies" that talk about how the builders organize their day, and wonder(?) why they aren't nearly as effective as we promise they'll be. Hell, we've been doing that in one form or another since the OS/360 project burned.

the machine aspect has been abstracted away by HLLs
so long ago that it has been forgotten
assembly code is so low level it keeps one aware that one is working on a machine
like working on a car with little screws nuts bolts clips just to get to the part you need to fix

HLLs make programming more like doing math (as in just doing math) than working on a machine

almost all HLLs are focused on doing just math a whole range of computers programs use little math
and focus on logic and decisions at best Hlls are clumsy at doing logic because what is happening at the bit level gets hazy along with keeping track of what the program has done and needs to do

when more than one person is working working on a machine the chain command needs to be a rubber band
people need to let go of there egos one person may know some tricks that others don't rank needs to be forgotten joe may be a better programer but bill is the boss even if joe has a better way doing the task bill is still the boss

the boss may not always right but he is always the boss

Missing the point, Rob ... "the machine" is not "the silicon chip," nor is it a sufficiently-low-level means of addressing it.

"The machine" is ... "the software itself." That is the light-bulb realization that everyone so-far seems to have overlooked.

Whether it's written in terms of assembly-level instructions or Prolog, the final result is a set of if..then..else directives that will be launched to entirely fend for itself. The team that built it will not have any influence at all. Their entire project-management strategy, their entire means of managing their own affairs, all of their "nine o'clock scrum stand-ups," will mean . . . zero. Because "the Thing that they have made" is the one and only thing that survives.

It's such a damned easy idea to overlook.

I under stand when the project is done all the office politics bused egos power games the one upsmanships all that is gone but all those games can effect the final product for the worse


what I'm saying is you stay more aware you are building a machine to do a task when working at a lower level
like build a logic circuit from chips rather than wiring modules together and hoping the modules work as advertised with out unintended side effects to do the same task you can never really be sure you know exactly whats going on with the modules

have you ever programed in assembly the mind set is not at all the same as a HLL

I have on a Z80 and on a 486 in 16 bit mode
in assembly one needs to keep a model of the CPU and your usage of memory in your head along with how the instructions interact with each other with HLLs you glue box a to box c there is not as clear of a model of what the program will do as there is with assembly

the long and short is there can be advantages in working at a lower level
working at a low level helps teach one to think in finer grans

This sure seems like it's setting up a straw man: where or who are the people who pretend that software works otherwise?

It's aimed as a project-management text. Has nothing to do with assembly language or arcana. It has a lot to do with testing and such, and a fair bit to do with practical office politics.

What rang my bell with it was that lots of people out there manage projects in one of two ways: either they basically don't manage it, assigning a small group of people to basically diddle with it forever as problems (always) crop up, or they micro-manage it with timelines and such. Or they try to manage implementation like deployment. And so, the argument made is that, in both cases, they're trying to manage the people, not the (software, never mind the hardware) machine. Somehow you've got to explain to people what that difference is.

Good reads thanks and your text as a whole is not completely "aimed as a project-management text."

Trial and error until mechanical AI, I'm a believer.

(Hmmm ...) "Ladies and gentlemen, XYZZY Airlines is pleased to announce that you are flying on the world's first completely automated airplane! This is your robotic Captain speaking. Would you like to (A)bort, (R)etry, or (I)gnore?"

The trials are no big deal, but the errors do seem to be a wee bit of a problem.

They got us here. Now applying concepts of Moore's Law to software... it's hard to conceve at this point in time, I know. Even when AI sparks true life howmany won't believe and for how long? Stuff does happen ("good\bad") whether taught by a mom or a machine. Sorry to go so off topic.