Discussion on:

Why consultants should banish magical thinking

The more intelligent software becomes, the more bugs look like personality disorders. But we're still a long way from having software as complex as the human mind, and in any case we should be able to reason about software that humans created, no matter how complex it is.

After all the Hardware & Software have ganged up and are trying to get me. I know this from old and take steps to prevent it happening now.

So when the wind is blowing that way I stand on the right foot with the toes pointed that way and clamp my tongue between my teeth with it hanging out the right side of my mouth. When the wind blows at a different level or directions I act differently.

But seriously I can remember some really strange things happening over the years ranging from a Operator typing too fast for the hardware which caused a State Wide Crash, Some really Poor Coding practices which only seemed to affect one operator when she sat a certain way to yesterday when I pulled a new NB out of it's box and found that the HDD was blank.

I couldn't fault the drive it tests perfectly and it could be A OK and just someone at the factory has screwed up or it could be that the Platters have a faulty coating on them which is causing the Stored Binary to just disappear over time when it's unused.

Either way They is Ganging up on me. Just not sure what to do from there with the last one but I'll deliver it today and see what if anything happens.

Oh and in the first case mentioned here that operator knew exactly what she was doing and if she wanted a break she would break the system but I can Guarantee that She didn't tell the Tech who was sent out to fix the mess.

However Chip I do tend to disagree with this bit of you above post

and in any case we should be able to reason about software that humans created

That works on the superposition that the person/people creating the software are sane. If they are Insane/Deranged there is no way to attempt to understand the mental processes that went into creating the code or what processes they have instigated to make it do what they wanted. You may find that the "Deranged" programmers who incidentally where always that way and where never allowed near the public lest they scare them have developed something so strange that "Normal" Programmers can not understand their Thought Processes.

However that just means that there will be a new position opened "Shrinks" for Ai's where they talk the computer into repairing it's own code.

Col

While it may be impossible to reason through the insane programmers thought process, it is certainly possible, though perhaps difficult, to reason through the code itself. No matter how convoluted it might appear it will still execute as written and in a deterministic fashion.

The idea that code doesn't execute as written is the "magical" belief we need to stamp out.

That's what I meant, although I appreciate the humor in Col's comment.

Not quite right there though that is what should happen

It doesn't always apply. I remember the first Pentium???s years ago with a Floating Point Issue which was interesting to say the least and the Code didn't behave as written on that though it worked perfectly on nonpentium CPU's.

The hardware acted in a fixed way. Once you wrote for the hardware rather than the documentation, it worked.

In that case you took an already working program loaded it to new hardware and it turned very expensive race motors to scrap metal.

It's a case where a previously working app didn't work when it was loaded to new hardware which it was supposed to be compatible with.

There is a very big difference between writing a program for specific hardware which doesn't happen any more anyway to writing an app for a Platform and it works great for a few years and then starts giving Major Problems.

The App in question was used to make the programing for EPROMS used in Engine Management Systems in the racing side of the industry. Compile the code through this app and then burn a PROM type thing. All old hat now but then it was right at the Bleeding Edge and a nasty thing to fix.

Col

And what the programmer was hoping to achieve is also part of understanding the code. If you can not understand why it was written to perform that way it makes it much harder to impossible to understand what was envisaged by it's original developer.

So many Agile programmers consider working code the only necessary component to successful development. Without knowing the decisions made to bring code to its current state and the reasons those decisions were made, the next step a programmer makes based on reading code alone may undo months worth of decision making.

This is where the architect steps in. The architect is responsible for the success of every developer on the team and the continuity of the solution.

It's the fault of some self-styled Agile programmers. Every methodology has its perverters, and there's a big difference between "agile" and "falling apart at the seams".

and no one's failure, including their own, then?

You might want to take a few remedial leadership courses...

But Honestly before I stopped punching code my biggest problem was attempting to understand what was going on on something that had been developed and then "Improved" numerous times over the years by different programmers/developers and why what was happening was even designed to work that way.

In the end I gave up trying to understand once I came to the conclusion that the majority of people coding did not look at the entire system just small subsections and they would "Develop" improvements into their Specialist Sections which by themselves looked good but when looked at as part of an entire system left people wondering why it was done that way.

Not so much a problem with 1 person making modifications over a year or two but when several different people make minor modifications over a decade or so things get into the Magical category that it works at all let alone works was well as it does.

Now days I get to fix bugs in code so I'm constantly looking over others code

when it starts to give problems and most of those times it's almost impossible to

the original problem reliably.

Now days I get to fix bugs in code so I'm constantly looking over others code when it starts to give problems and most of those times it's almost impossible to the original problem reliably.

Of course I may be completely Insane as I've been doing this type of work for several decades now so I may have lost it all ages ago.

Col

Anyone got any ideas what in G to G2 is unacceptable to TR as that is what has been causing the post to disappear.

I mist have completely lost it as I can not see anything wrong there.

Col

the possible culprit? It appears that it wouldv'e been 'un-flock' (actually a certain vowel replacing 'lo'). It makes the comment make sense, and would (I suppose) get it flagged, as well.

So if you read it that way it sort of makes sense.

But if you put breaks in it it doesn't make any sense.

Col

...the original problem reliably."
So, looking for a 'flaggable' word somewhere, it seemed feasable that "...almost impossible to 'un-something' the original problem reliably." both served the 3-part comment's meaning and could've used a euphamism for 'unmucked' (ahem).

But you wouldn't have, with ladies about, I'm sure.