unwritten laws of data processing, circa 1973

[Don Shepherd]

From a 1973 textbook on electronic data processing, the "unwritten laws of data processing":

1. Anything that can go wrong will go wrong.
2. Things always go from bad to worse.
3. If several things can go wrong, the one that will go wrong is the one that will cause disaster.
4. Mother nature:
(a) Hates computers
(b) Sides with the bug
(c) Always adds one more bug
5. If by some miracle everything is going well:
(a) The specifications are changed
(b) The test data is nothing like the real data
(c) The project is cancelled
(d) You didn't "really" understand the requirements

This is pretty good stuff for 1973. I think most of us can relate to these things.

[Valentin Albillo]

(05-01-2019 01:26 AM)Don Shepherd Wrote:  This is pretty good stuff for 1973. I think most of us can relate to these things.

"There aren't any good solutions left, only bad and catastrophic ones, and it's essential that we find the bad one."

Heard live at a work meeting. Honest ! ...

V.
.

[cruff]

(05-01-2019 01:26 AM)Don Shepherd Wrote:  (d) You didn't "really" understand the requirements

That's because there were no real requirements to begin with, just vague statements.

[Dave Britten]

I'm working on a big CRM integration right now, and we're pretty heavy on number 5.

[burkhard]

Unwritten laws in a textbook?
I see a deviation from the requirements already!

[Don Shepherd]

(05-01-2019 01:08 PM)burkhard Wrote:  Unwritten laws in a textbook?
I see a deviation from the requirements already!

The thing I find amazing is that these enumerated "laws"--which turn out to be very accurate--were recognized years before I would have imagined.

Another factor that leads to project failure is when managers think all they have to do is consolidate status reports from their underlings and not know a thing about what their people are really doing. Good managers know exactly what their people are doing, and why, and the problems they face.

[Dave Britten]

(05-01-2019 01:50 PM)Don Shepherd Wrote:  Another factor that leads to project failure is when managers think all they have to do is consolidate status reports from their underlings and not know a thing about what their people are really doing. Good managers know exactly what their people are doing, and why, and the problems they face.

I once had a project manager go around the room during a status meeting (well into the project schedule) asking each participant what tasks they currently had assigned to them. It felt like I had wandered into a Terry Gilliam (or perhaps Franz Kafka) film.

[KeithB]

Even though the examples are in Fortran and PL/1, every programmer should read Kernigham and Plauger "Elements of Programming Style". A couple of my favorite quotes:

"Floating point numbers are like sandpiles: every time you move one, you lose a little sand and
pick up a little dirt"

"Everyone knows that debugging is twice as hard as writing a program in the first place.
So if you’re as clever as you can be when you write it, how will you ever debug it?"

[pier4r]

(05-01-2019 01:26 AM)Don Shepherd Wrote:  This is pretty good stuff for 1973. I think most of us can relate to these things.

Because I guess management was and is made out of people that do not really improve much over the years.

Also I recall that similar things were said for projects regarding weapon development in the world wars. The state creates a bid of an advanced weapon (for the time), say an aircraft, and then requirements change, test changes, they want more payload, the wind tunnel breaks 2 weeks before the final test, etc... So it is the same thing rediscovered over and over. This shows how little such useful hindsights are consolidated, as one could try to avoid repeating the same mistakes.

The one from KeithB is gold.

[Don Shepherd]

(05-03-2019 11:24 AM)pier4r Wrote:  Because I guess management was and is made out of people that do not really improve much over the years.

I think that "management" is not unlike most other professions: there are good ones and bad ones. I've seen both in my career. I always tried not to be one of the bad ones!

Large projects require some very bright people and tight controls if they are to succeed.

[striegel]

For years I've maintained my own rule for estimating:

Given the time you know it will reasonably take to complete a task, double it, then move up to the next unit of time.

For example, if you know it should take 1 hour to complete a task, quote 2 days.

This method is more accurate than any other I have found. ;-)

Alan

[pier4r]

For estimates, especially in jobs where new projects are, well, new, but the difficulty is comparable, I try to collect previous solution times to get a better estimate.

So far I see that the teams in which I worked estimated the time needed for the project around 30-35% of the real time, this consistently over several projects. Unfortunately they keep doing it, but in my mind now I say: "ok they estimate 3 days, it is going to be more likely 11 or 12" and more or less it works.

also https://en.wikipedia.org/wiki/Planning_fallacy

The problem in my view is the culture. Everyone is used to hear "yes I can do this in 1 or 2 days" even if at the end it needs 6. They do not see the 6 and they remember the 1 or 2 days. Therefore if you say straight ahead "I need 6 days" they look horrified and they question your ability to work.

On the other side, if someone is used to get the work in 6 days when people say "I need only 2", then if someone says "I need 6 days" they may subconsciously think one will end in 18 days, that is unsustainable. Therefore they again look horrified and they question your ability to work.

Then one gets to https://en.wikipedia.org/wiki/Berlin_Bra...rg_Airport , that likely will be obsolete at the time of the opening.

[everettr]

Here is an image of one of my favorite posters from the mid-80s:
Murphys's Computer Law

https://imgur.com/r/ProgrammerHumor/QrRg0

Published by Celestial Arts, of Berkeley.

[John Keith]

Also related is Hofstadter's law.