The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Handwritting (in cursive) Code Question
EncA Fool with CompassionPronouns: He, Him, HisRegistered Userregular
I am writing a short story which at one point involves an auditor going through a software development company and being astounded by acts of embezzlement and other odd things. One of these things involves a man being paid a very large grant to produce a complicated translation program which he produces without use of a computer. He has handwritten, in cursive where possible, dozens of three inch binders of copy paper worth of code.
What I am having trouble with in this scene is reacting to all of the potential problems with doing this, mostly because I am not a programmer myself.
If any of you know programming, could you leave a few notes on just how terrible an idea this is and why? It would really help flesh out my auditor's response which is essentially a jaw-dropping facepalm at the moment.
Enc on
0
Posts
amateurhourOne day I'll be professionalhourThe woods somewhere in TennesseeRegistered Userregular
I mean realistically, aside from the obvious reason that it's weird, I guess the only problems that would come from handwritten code are the lack of backups and organization.
If you lose a sheet your program ceases to work... If a book burns, that was your only copy.
are YOU on the beer list?
0
admanbunionize your workplaceSeattle, WARegistered Userregular
A program that has never been tested on any actual inputs is not a program, it's psuedocode.
Also software development also goes through iteration, which is very hard to do on paper copies.
I think the biggest concern is how you have your character handle the iterative parts of programming, also how does he test as he goes to correct syntax or compiling errors? Obviously if its just a waste of time type project and they dont want it to actually get done then it doesnt matter.
At some point he has to be entering it into a computer, programs run on computers. Not sure how you are getting around that. All I can see is that its an intentional waste of time and the guy doing it isnt actually making a program, but scribbling random code on paper to make it look like he is working on something. Is that what you are going for?
Before monitors computers were pretty much programmed with punch cards. It would make more sense to me if he had to develop a program for some really old punch card system.
Well, here's another problem - something needs to be able to read the instructions and carry them out. Assuming that the program isn't executed by another person, how would it be executed without a computer of some sort?
I mean, even if a computer was involved, it would be a fairly complex task as it would need software that could successfully read the handwritten program (cursive handwriting throws a wrench in that), translate it to plaintext (not hard, so long as the scanning was accurate), pass that to a compiler, and then automatically run the executable that's built.
The latter is possible, if incredibly inefficient to the point of not worth the hassle. Also keep in mind that most non-trivial non-website programs are thousands - millions of lines of code long.
I think the assumption is that the program is still a work in progress and at some point he'll copy it into a computer.
In the context of the story, the programmer in question was murdered soon after sending notice to the branch providing the grant that he was about to finish his program. The question that is being bounced around by the protagonists is why he was killed. A sub-part of that concerns his handwritten program which is either:
1) An elaborate scam to steal the grant money.
2) A very eccentric but otherwise successful way to keep it from being stolen by competition.
The auditor, one of the protagonists, is sent in to figure out which it is and I'm looking to have a realistic response about all of the potential problems of writing code in this fashion, checking it for errors, and immediate responses to coming across something like this.
An eccentric way to keep something from being stolen by competition would probably be more believable like so:
He stores his source control repository on a TrueCrypt drive. The passkey to the encrypted drive might be something he wrote on paper. Or perhaps the paper contains a mathematical problem that would produce his passkey if you solved it. (http://www.truecrypt.org/)
The important point is that the physical hard disk is indecipherable. The disk could contain his code, or his evil nefarious plan to defraud the grant program.
Paper programming is typically not a good idea simply because a program of sufficient complexity like that would be tens of thousands of lines long at least, which equates to something like at least 400 pages. And there would be no way to verify the program worked without completely retyping that in a computer, compiling it (and fixing any syntax errors) and testing it. As well, there are usually milestones in the software development process where the results of the work are reviewed to make sure things are still on track; without an actual soft copy of the program in a semi broken state for these reviews (as in, if he tried to present a paper copy of the code), that would definitely be a red flag.
The programmer could be brilliant and eccentric enough to write an image processing program that takes a scanned image (in this case, the handwritten papers) and translate key parts of the squiggles on the page into text (which could then be a key source code for a larger program in question, or an excerpt that contains evidence worth killing for). It would be a bizarre way to hide data through steganography, but it's plausible.
Actually making a program of any sophistication by writing it on paper would be implausible, but many programmers plan out their programs on paper or other "scratch pad" digital equivalents.
We used to program all computers by using marks on paper -- punchcards! But it's an ineffective process because you need to get whatever is on paper into the computer, so the computer needs to either a) read the paper, using OCR or punchreading or something, or b) be transcribed manually.
There's lots of logistical reasons why paper would be bad, and some are mentioned above. Sheer size, tracking every page, testing and review, ensuring proper coding order, etc. Elements in cursive aren't so bad except they're often hard to read by other people.
Granted, all of those reasons could also be used to explain how it was more secure to do it that way, as they would be harder to steal, test, and input.
This is not that far from reality in the deep, dark, past.
When I was a kid in eastern Europe, we had Amiga 'computers' with tape drives as the only form of storage. Since we were kids, and couldn't afford software (on tapes! Only rich kids had floppies ) we would buy magazines that had pages upon pages of typed code which we would manually input, compile, and run to have new games.
So your example is not impossible, just highly improbable in this day and age.
If I can suggest an alternative, have the guy author the code, and then record the machine code/binary output (thousands of lines of 1s and 0s) in a notebook, just to be difficult.
A modern example of this would be something like the dvd decrypion method which is illegal to share, but can be freely distributed as a number or binary string since numbers aren't illegal.
Dijkstra was a very famous Computer Scientist (at least to those in our field) who preferred to do everything by hand. Maybe reading a little about him will be inspirational?
Jephery on
}
"Orkses never lose a battle. If we win we win, if we die we die fightin so it don't count. If we runs for it we don't die neither, cos we can come back for annuver go, see!".
0
admanbunionize your workplaceSeattle, WARegistered Userregular
edited December 2011
Though even then there's a huge difference between computer science and software development. None of his work demanded the use of a computer.
It might be more realistic if he wrote out an algorithm or solved some specific problem on paper, rather than wrote code out on paper.
0
EncA Fool with CompassionPronouns: He, Him, HisRegistered Userregular
Thanks, everyone! I think I have a good grasp on how other programmers will look at this case. Particular points go to Hahnsoo1 for the seganography link, that's an angle I hadn't considered and might follow.
Posts
If you lose a sheet your program ceases to work... If a book burns, that was your only copy.
I think the biggest concern is how you have your character handle the iterative parts of programming, also how does he test as he goes to correct syntax or compiling errors? Obviously if its just a waste of time type project and they dont want it to actually get done then it doesnt matter.
At some point he has to be entering it into a computer, programs run on computers. Not sure how you are getting around that. All I can see is that its an intentional waste of time and the guy doing it isnt actually making a program, but scribbling random code on paper to make it look like he is working on something. Is that what you are going for?
Before monitors computers were pretty much programmed with punch cards. It would make more sense to me if he had to develop a program for some really old punch card system.
See: http://en.wikipedia.org/wiki/Computer_programming_in_the_punch_card_era
I mean, even if a computer was involved, it would be a fairly complex task as it would need software that could successfully read the handwritten program (cursive handwriting throws a wrench in that), translate it to plaintext (not hard, so long as the scanning was accurate), pass that to a compiler, and then automatically run the executable that's built.
The latter is possible, if incredibly inefficient to the point of not worth the hassle. Also keep in mind that most non-trivial non-website programs are thousands - millions of lines of code long.
In the context of the story, the programmer in question was murdered soon after sending notice to the branch providing the grant that he was about to finish his program. The question that is being bounced around by the protagonists is why he was killed. A sub-part of that concerns his handwritten program which is either:
1) An elaborate scam to steal the grant money.
2) A very eccentric but otherwise successful way to keep it from being stolen by competition.
The auditor, one of the protagonists, is sent in to figure out which it is and I'm looking to have a realistic response about all of the potential problems of writing code in this fashion, checking it for errors, and immediate responses to coming across something like this.
So far, you all have been very helpful, thanks!
He stores his source control repository on a TrueCrypt drive. The passkey to the encrypted drive might be something he wrote on paper. Or perhaps the paper contains a mathematical problem that would produce his passkey if you solved it. (http://www.truecrypt.org/)
The important point is that the physical hard disk is indecipherable. The disk could contain his code, or his evil nefarious plan to defraud the grant program.
Paper programming is typically not a good idea simply because a program of sufficient complexity like that would be tens of thousands of lines long at least, which equates to something like at least 400 pages. And there would be no way to verify the program worked without completely retyping that in a computer, compiling it (and fixing any syntax errors) and testing it. As well, there are usually milestones in the software development process where the results of the work are reviewed to make sure things are still on track; without an actual soft copy of the program in a semi broken state for these reviews (as in, if he tried to present a paper copy of the code), that would definitely be a red flag.
Actually making a program of any sophistication by writing it on paper would be implausible, but many programmers plan out their programs on paper or other "scratch pad" digital equivalents.
There's lots of logistical reasons why paper would be bad, and some are mentioned above. Sheer size, tracking every page, testing and review, ensuring proper coding order, etc. Elements in cursive aren't so bad except they're often hard to read by other people.
Granted, all of those reasons could also be used to explain how it was more secure to do it that way, as they would be harder to steal, test, and input.
When I was a kid in eastern Europe, we had Amiga 'computers' with tape drives as the only form of storage. Since we were kids, and couldn't afford software (on tapes! Only rich kids had floppies ) we would buy magazines that had pages upon pages of typed code which we would manually input, compile, and run to have new games.
So your example is not impossible, just highly improbable in this day and age.
If I can suggest an alternative, have the guy author the code, and then record the machine code/binary output (thousands of lines of 1s and 0s) in a notebook, just to be difficult.
A modern example of this would be something like the dvd decrypion method which is illegal to share, but can be freely distributed as a number or binary string since numbers aren't illegal.
Dijkstra was a very famous Computer Scientist (at least to those in our field) who preferred to do everything by hand. Maybe reading a little about him will be inspirational?
"Orkses never lose a battle. If we win we win, if we die we die fightin so it don't count. If we runs for it we don't die neither, cos we can come back for annuver go, see!".
Thanks again!