two lines of code

The hypothetical amount of code needed to solve any given problem, as given by a professor I once did research under. A running joke with everyone else that worked with him.

A typical conversation where this phrase would occur:
Grad Student: So you want a program that will generate surface data given 3 pictures of a room and some camera position data, by next tuesday?
Professor: Well, all you have to do is choose edge points and set up some matrices. From there it's just two lines of code.

Here's how different people add two lines of code:

• Computer Science Student:
  1. add the code
• Open Source Developer:
  1. checkout the file with CVS (Only use CVS!)
  2. add the code
  3. compile the code
  4. checkin the file
  5. e-mail the list telling others about the fix
• Typical Software Engineer:
  1. file a bug report on the company intranet
  2. checkout the file with CVS or whatever
  3. add the code
  4. run lint, Purify, or whatever
  5. compile the code
  6. perform some sanity checks on a lab machine
  7. checkin the file
  8. e-mail the team mail alias about the fix
  9. close the bug report
• Me:
  1. file a bug report on the company intranet
  2. e-mail the program managers to put this item on their radar
  3. e-mail the manager in charge of the source tree to put this item on their radar
  4. create a full copy of the OS source tree
  5. checkout the file in my copy of the source tree
  6. add the code
  7. compile the code
  8. run lint, Purify, or whatever
  9. perform some sanity checks on a lab machine
  10. checkin the file
  11. perform a full build of the entire OS for the four separate architectures that it supports
  12. download 3 formal test suites from the company intranet
  13. run all test suites on all supported architectures in both 32 bit and 64 bit mode (when applicable) in both single processor and multi-processor mode
  14. conduct a formal code review of my changes
  15. attach a summary of the changes to the bug report
  16. fill in a form on the company intranet describing my fix, how I tested it, why it's necessary, and how and when I'll deliver it to the OS source tree
  17. conduct a formal review of said form for correctness, completeness, and importance of this change to the company's business
  18. conduct a formal review of my test results
  19. schedule a time with the manager of the source tree to put my change into the OS
  20. put my change into the OS
  21. update the bug report to reflect that the code is delivered and awaiting verification
  22. e-mail the Quality Assurance department to put the verification of my fix on their radair
  23. Once a production quality CD including my fix has been verified, I must then confirm that my fix is properly included on the CD (another form on the company intranet)
  24. After verification, close the bug report

I saw that a small buffer was allocated but then not freed, so I had to go through all of those procedures to add this code:

	if (buf)
		free(buf);

True story. I do this all the time. Sigh. Sometimes I miss college.