14

In an IBM service bureau in the early 1960’s all data was keyed twice. The first time the holes were punched into cards. The 2nd time a verifier checked that the correct holes had been punched. Even in the programmers’ office we had both machines and were expected to verify our debugging changes.

Today passwords are the only things we are asked to enter twice.

17
  • 19
    Probably at the time the cost of the extra manual effort for double-checking started to exceed the cost for wasted CPU time on unsuccessful batch jobs
    – tofro
    Apr 12, 2021 at 8:09
  • 13
    Have we really stopped to verify inputs? A lot of inputs to computer systems today are verified with checksums, control digits, CRCs and reality checks.
    – UncleBod
    Apr 12, 2021 at 9:29
  • 2
    For a while there as companies started digitizing records it was cheaper to ship the paper to someplace (the Philippines were common) and have people type them in, usually two separate people entering the data as a verification.
    – Jon Custer
    Apr 12, 2021 at 14:44
  • 6
    Keying data onto cards was often done from handwritten input. Double keying by two different people was a check on reading poor quality handwriting, as well as on "fat finger" typing errors. When computer users entered input themselves, the "handwriting check" was irrelevant since (presumably) they knew what they wanted to input!
    – alephzero
    Apr 12, 2021 at 18:27
  • 4
    @LeoB Not just taxes, bank #'s seem to be always entered twice. All my bill pays work that way. Apr 12, 2021 at 18:41

5 Answers 5

30

Maybe we don't always enter things twice, but verification is still a major part of software engineering.

A lot of pure data entry is still done by double keying, which is to say, the data is entered twice by two different people and the results compared to try to reduce the error rate.

As for programming, if you do it properly, there are code reviews and unit tests and integration tests and system tests. One of the few real innovations in programming since I started professionally in 1987 is "continuous integration" (which isn't really continuous, but never mind), where any change a programmer makes and commits to the codebase is automatically compiled and tested.

So maybe we don't always literally check everything twice, but our modern verification methods are fairly robust and do not represent a backward step since the 1960's.

PS we are also often required to enter an email address twice (which really annoys me since I always copy-paste it), so passwords aren't the only things.


Ironically, my answer contained at least one typo. Maybe I should have checked it.

5
  • 2
    No, it was the correct decision economically not to check it because the costs of having a typo exceed the costs of checking it to see if there is one.
    – DKNguyen
    Apr 13, 2021 at 2:47
  • 3
    @DKNguyen If the cost of having a typo exceeds the cost of checking, isn't that an argument for checking rather than against? Apr 13, 2021 at 4:42
  • 3
    @Llama My typo. See my reasoning above lol
    – DKNguyen
    Apr 13, 2021 at 5:05
  • 1
    Technically, "continuous integration" is not automatic compilation and testing, but frequent building and testing of the entire system (or large sections of it). The originator (or at least popularizer) of the term, Kent Beck, did this manaully on the C3 project; they had a dedicated machine in the middle of the room on which developers would do this at least once a day. (I also use manual CI quite frequently, for reasons there's no space to get in to here.)
    – cjs
    Apr 13, 2021 at 8:10
  • @DKNguyen What was the correct decision economically?
    – JeremyP
    Apr 13, 2021 at 14:30
12

There were two issues, the first being that data entry was not interactive and data was often strangely formatted to get around the constraints of the 80 column punched card so the data wasn't easy to enter. An additional problem that not all punched card machines printed on the cards as holes were punched making verification harder. So type twice to verify became the rule in many places (but not always). The card punch in verify mode would read the card and if your input didn't match, it would alert you and give the possibility to correct, generally by a mixture of duplicating the bad card to the column before the mistake and then manually typing the correction.

Later we went to forms based data entry via screens, even before true interactive computing came into play. The description of a form was sent to a visual display unit, and it looked like the data being entered. It was much easier to see and correct mistakes. The systems also had very limited data checking. They could check if numbers had been typed where alphas were expected or vice versa.

They could still have a verification stage but it was often skipped and if anything, checked from a printout of the entered data later.

2
  • 3
    Some of the more sophisticated card punches of the day supported a Program Card. It provided a skosh of assistance to the operator, but was hardly what we would consider interactive.
    – HABO
    Apr 12, 2021 at 19:37
  • Essentially the program cards could let you SKIP to the next field (a tab function), DUPlicate columns and could lock down the characters available for entry. The DUP function was useful if you had many data records with the same prefix. One such punch was the IBM 029. The problem was that you had to enter the fields in order and then you didn't actually see what you were typing as the punch/print head covered multiple columns.
    – hughk
    Apr 13, 2021 at 7:33
4

Entering data twice squares the probability of a typo going undetected. Things have moved forward and these days we have the computing power to do some more comprehensive sanity checks ‘if (x = 0) { }’. I (just) missed the punched-card era but I’d say that pretty much as soon as a programmer was allowed to type commands directly into a computer they would realise that attempting to compile code is much quicker than checking it by hand.

4
  • 1
    Uhm, square root means the probability of a typo would increase... Apr 12, 2021 at 13:08
  • 2
    It squares the probability, not square-roots. Apr 12, 2021 at 16:14
  • 1
    if anyone gets confused reading this post, ask yourself when x^2>x holds true.
    – Rainb
    Apr 16, 2021 at 8:42
  • That code compiles does not mean that the entry was error-free. As an example, consider FORTRAN IV variable names. May 9 at 23:03
2

When did double-keying cease to be a common practice in verification?

About the time when data entry became interactive, i.e. when terminals became a thing, which is the late 1960s. On a terminal data entry could be not only easy read and corrected, but as well machine checked right at entry. Something not possible before (*1).

Even in the programmers’ office

Well, that's a bit extreme, but understandable when punching was done by a dedicated craft who didn't really understood to what she was typing. Saves against a missed comma or space or weird variable name. Saves as well all the paper for redoing and valuable machine time wasted one a missed compile job (*2).


we had both machines

I guess the answer is already in there but maybe hard to imaging in modern times: Keypunches and card based processing predates all programmable and digital computing.

Those two keypunch types, straight and verifying (*3), were needed as verification is a different process. There was no way to check any data entry, no processing power for check numbers, valid ranges, format or alike. But what could have been made with (electro-) mechanics already at the turn of the century (20th that is) was comparing the 12 holes at a card position with the 12 levers pulled by a key. A pretty good check when assuming that two different people would not make the same mistake at the same location.

It worked rather well and made lots of sense exactly until the point when computers became interactive - either with the main CPU or local data entry stations (*4).

and were expected to verify our debugging changes.

Now that's a strong hint that at that time and place it was more a case of the 3 holy rules (*5):

  • It's the way we always did it
  • We never have done it otherwise
  • Who are you to ask otherwise

After all, the chances that the the same person does the same typo at the same location are extreme high, making he whole process somewhat useless.


*1 - This is in fact what brought us some of the very first desktop computers: Programmable data entry terminals like the Cogar 4 or Datapoint 2200 - the later being the start of the direct linage to today's x86

*2 - Of course some places also may have made it mandatory for programmers just because it's the way it is - never overestimate the flexibility of bureaucrats.

*3 - Later models combined that into one.

*4 - Well, there were intermediate steps for data entry with key punches that had punch tape control for data entry allowing only certain characters at certain positions of a card and so on, but they were extreme expensive and needed careful setup, so only useful for huge amounts of ever the same cards.

*5 - May sound better in Bavarian

-2

I notice that nobody has actually given the approximate date when verifying everything was abandoned.
I do remember receiving a report from the people looking after my money. It claimed that some of my money was in a bond earning 200% pa. I wrote to them asking why ALL my money was not invested at 200%. I even sent them a macro which would compare 2 spreadsheets and highlight discrepancies. It still took them 2 years to amend their reports to show the more accurate return of 2%.

1
  • 2
    This doesn't seem to be an answer; it would be more suitable as a comment. And with reference to the first sentence - there is some dispute as to whether "everything" was verified (by double-keying) in the first place. May 9 at 21:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .