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.

16
  • 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 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 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 at 14:44
  • 5
    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 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 at 18:41
29

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 at 2:47
  • 2
    @DKNguyen If the cost of having a typo exceeds the cost of checking, isn't that an argument for checking rather than against?
    – Llama
    Apr 13 at 4:42
  • 3
    @Llama My typo. See my reasoning above lol
    – DKNguyen
    Apr 13 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 at 8:10
  • @DKNguyen What was the correct decision economically?
    – JeremyP
    Apr 13 at 14:30
10

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 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 at 7:33
3

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 at 13:08
  • 2
    It squares the probability, not square-roots. Apr 12 at 16:14
  • Quite so, thank you
    – Frog
    Apr 12 at 19:57
  • 1
    if anyone gets confused reading this post, ask yourself when x^2>x holds true.
    – Rainb
    Apr 16 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.