Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
