In the introduction to the paper, I found:

• An interesting Knuth quote.
• An important lesson.

"Unfortunately we are unable to give a rigorous proof that [the listed runtime] is indeed the expected running time of the number field sieve. Consequently, this paper does not contain a rigorous mathematical result. In this context the following quote from Donald Knuth is of interest: `One of my mathematician friends told me he would be willing to recognize computer science as a worthwhile field of study, as soon as it contains 1000 deep theorems. This criterion should obviously be changed to include algorithms as well as theorems, say 500 deep theorems and 500 deep algorithms.’

The present paper describes a deep algorithm for the solution of a fundamental problem, and it depends on techniques that have not been of traditional use in this area. We therefore trust that it is of interest to theoretical computer scientists, and that they will appreciate the challenge posed by its rigorous running time analysis."

"The Number Field Sieve": Lenstra, Lenstra Jr., Manasse, Pollard. 1990. Copyright ACM.

The interesting Knuth chestnut aside, it’s important to note that even the famous mathematicians draw inspiration from different sources. This is the best argument for perpetually continuing one’s education, no matter your field of study: the more you know, the more tools you can use.

Integer factorization is ostensibly a number theory problem, but the tools for the job were found in abstract algebra. Where are the tools for your job?

How are you sure that an Object-oriented database doesn’t solve your problem better if you’ve never learned how to use one? How are you sure that you shouldn’t be writing your web application with Ruby on Rails instead of PHP? Maybe Erlang solves your scaling problems much easier than Java. Maybe those Lisp jerks were right all along.

A lot of different solutions have been introduced by a lot of smart people. There may be a good one you haven’t tried.

Decades after The Mythical Man Month examined the management of software development, projects are still failing at an alarming rate. Some estimates say that as few as 34% of software engineering undertakings are successful. Not only that, but big projects fail, and fail spectacularly, like the FBI’s case management system debacle. The whole project was scrapped after it was discovered that you can’t build software the way the Egyptians built pyramids: draw a triangle blueprint and whip the slaves until it’s all in place. Since then, effective management and work styles somehow shifted, and the FBI didn’t keep up.

Edit: As pointed out by Greg Molyneux , the pyramids were not built by slaves . Was EVERYTHING I learned in history class in middle school a lie?

Programming failures are due to a lack of rigor at all levels. The requirements suck, so the design sucks, so the interaction between modules suck. These problems will continue to persist until development practices assume that the developer and designers are making mistakes, and does everything possible to correct the mistakes early. This will be done, not by a slick methodology from a book, but rather a karma-based social programming application.

To strengthen my case, I want to look first at mathematics.

Why Does Math Work?

Mathematics, despite its difficulty, continues its inexorable advance. Theorems Conjectures that have withstood the test of time are falling, one by one; just ask Fermat and Poincaré . New ground is constantly blazed, and even tired subjects– such as number theory– are finding new applications and new life.

First, let’s get the obvious difference out of the way. Mathematics is largely a theoretical field. Sure, we can often apply it to the real world, but where’s the fun in that? The goal is not to produce products for ordinary people, but rather to further mathematics as a subject.

Also only those who are fully interested in mathematics are mathematicians. This does not hold true for software development, as trade programmers exist. I’ve met them. These programmers simply bang out code day to day as a living, and are not thoroughly passionate about programming.

Now, let’s see what math does right:

Excellent Peer Review System: Mathematics is advanced through proofs. These proofs are carefully perused by other mathematicians. Even better, there is an incentive to find mistakes: when an error is discovered in a published paper, the discoverer can write a paper on the subject. This ups the yearly publication count by 1, making the mathematician seem more valuable. It’s like karma!

At the end of the day, the effect is clear. The only mathematics that survives has seen a thousand eyes, and subtle flaws are discovered in due time. For example, Bertrand Russell discovered a contradiction in set theory near the turn of the century. This caused set theory to be ripped up from the floorboards and be rebuilt on top of new assumptions that did not fall victim to this same flaws. The paradox is now known, unsurprisingly, as Russell’s Paradox .

Open source software also has this same advantage of many eyes, but open source software also does not do everything for everybody. Yet.

So How Can We Fix Software Engineering?

In one sense, we may not be able to. People are not usually programming for a decade before they enter the field, so it turns out that some people were just never meant to be programmers, and it is too late!

Other people will always code without "reading the manual" on their coding methodology. They will use the waterfall method. They will take eXtreme Programming as a blanket excuse to code without thinking. They will adopt the Rational Unified Process, but forget about that testing thing because it takes too much time. It could be impossible for collectives of the uninformed to produce good work.

The best, on the other hand, do not need to be regulated. They know better than anybody else about their own personal shortcomings (whether they realize it or not), and they use them to their own advantage. They know they are likely to make breaking changes to their own code, so they use version control. They know that they are going to write bugs, so they do everything they can to automate their finding. They already have a library of old code that is tested and works, so they can finish projects faster.

So to fix development for the rest of us, we need to approach software engineering like we would approach mathematics: with rigor. We need to treat it as if it is an incredibly difficult subject. We need a plan of attack, and there needs to be an excellent review system. However, I strongly suspect that most developers will not willingly go along with the rigor associated with, well, rigor. They may give it good lip service, but when it comes time to write the 60th test case for their physics simulation, they just might start cutting a corner or two. So what will the next programming methodology have to do better? One of the following:

1. Simulate rigor from the unrigorous.
2. Encourage rigor.

The Next Big Thing in software engineering methodologies may even do both. How could it accomplish this? Incentive! There has to be an incentive for programmers to do rigorous work, which is why I think that the Next Big Thing will come, not with a book, but with a slick collaboration GUI that encourages/rewards rigorous activities with karma. If Reddit has taught me anything, it is that people will do anything for something as worthless as a karma point. Of course, this would need more serious study before anything was actually produced, but we’re talking theoretically at this point.

What The GUI Will Need

The program would best be served by a karma system, similar to Reddit. The program will need to keep track of (and reward) the activities most associated with rigorous programming.

I haven’t really worked out the details (being elbow-deep in another project), and there are many details to work out. Ideally, the GUI will be able to reward good design, good requirements, good code, and good tests.

I just want to give you a quick example of how the program can work: rewarding unit tests. When tests are coded well, they tell you when things break, and they tell you when things are (likely) working. It is generally well-agreed that programmers should write unit tests for their code. Despite all of this, the actual writing often fall by the wayside at the 50th unit test for your extremely boring file parsing function.

The program should reward you points for the number of unit tests you write for anybody’s code. Other programmers are human, and can often simply forget to perform these measures. They could even document the areas that still need work if they are fatigued by the process. They shouldn’t be penalized for something that should easily be added by another programmer. After all, if the function that they wrote is any good, they will be rewarded with karma for the function.

Obviously, this can be gamed. You can simply write 500 unit tests for the "add()" function written by another programmer’s class. But not when the karma system comes into play! If other developers find that your unit test additions are worthless, they can downmod the useless unit tests, and they can flag you as abusive.

Why won’t the developers spend all of their time writing unit tests instead of adding to the development effort? It can be claimed that if they are adding the unit tests and getting upmodded that they are contributing to the development effort, but I will not dodge the question.

Why will they not game the system? At the end of the day, they have a manager, usually in their same office. The managers will be able to see who is abusing the system, who is getting the most downmodded votes, and will be able to read comments and get explanations from their team. They will be able to walk down the hall and say, "Hey, dummy! Write the binary parsing utility you’re assigned and quit spamming unit tests!"

This system has the benefit that, over the long haul, the manager gets to see who has contributed the most to the project, who has the most controversial changes, and who has contributed the least. They will get to see the comments that other developers have left, and they will get to see who is not fitting into the team.

Why Am I Telling You Instead of Making It Myself?

There are a few reasons.

• I’m sick and tired of using bad software.
• It will never actually work in practice for a lot of teams.

I will use this project to learn Ruby + Ruby on Rails… after the few big projects on The List already, but if someone else wants to hack up their own version, awesome! I’d like to see what is done with it.

Why will it not work in practice? Because politics, unfortunately, plays into programming decisions in some companies. As an intern, I was shocked to find out that this was true. It could be hard to give the thumbs-down to someone’s code on a Friday afternoon at 4:00 when you know that in a month, they will be your manager.

Not only that, but the workplace is not like the internet. When you flame somebody within the office, they could theoretically come to your cubicle and napalm you in the face. Not pretty.

The Reddit Programming System can only really work if you have a team that understands that everyone makes mistakes, and to just be an adult when someone corrects you. I believe that it can help small-to-medium sized teams, but the teams that would do well with the Reddit Programming System may already be the teams that are doing well with other methodologies.

I have no reason to suspect that it will help teams that aren’t performing.

It’s possible to program a computer in English. It’s also possible to make an airplane controlled by reins and spurs. - John McCarthy, 196x.

This is pretty thought-provoking for being a flippant remark on computer language design. I don’t 100% agree with the sentiment of this quote (which is hard to do in the face of the developer of Lisp), but it certainly raises some good issues.

The less written in a language to complete a task, the better the language. English could be used to program computers, but the result would be quite unwieldy. Why? To even talk about mathematics and algorithms out loud, mathematicians and computer scientists need to create precise, exact definitions of every single building block that they use. English doesn’t cut it, even amongst native speakers. There would need to be a big huge conference of the hive minds of language design to sit and decide what each of the notions would be and how they would be expressed in English, and even then the language would still suck for a lot of programming tasks.

The consequences of vague language are disasterous: proofs are wrong, programs are wrong, and people punch each other in the face. McCarthy has very real concerns: if you told your robot that it should kill time, your wall clock might be in very real danger. There are much better means of specifying algorithms and mathematics, and these should be used when describing algorithms and mathematics.

However…

As has been pointed out before [shameless self-reference], one of the main reasons that we have programming languages is to show other people how we talk to the computer. We don’t program in Lisp or Python or C++ or Fortran because computers explicitly speak these languages. They need to be compiled down to machine language. If we wanted to speak directly to computers, we should be using the machine language. The reason we don’t is so that we can share our code easily with others, and easily organize our own thoughts. Our languages are designed directly for humans to convey mathematical and algorithmic thought.

Likewise, we don’t steer airplanes by manually moving the flaps and pouring the fuel into the engines. We have a human interface that flies the airplane for us, that humans can talk to, and humans can listen to. The actual act of flying has nothing to do with moving a joystick or flipping a switch, but it is a handy metaphor.

English is obviously not the right language to manipulate math. However, SQL is little more than structured English, and it acts excellently as a data storage/retrieval language. Even those with no programming experience can get the idea of what a SQL query is attempting to accomplish BECAUSE it is simply structured English.

It all comes down to “the right tool for the right job.”

If you haven’t read a transcript of the talk "You and Your Research " by Richard Hamming, I highly recommend that you take the 45 minutes and read it.

Since you are unlikely to, I have found the issues most relevant to computer scientists and mathematicians, and discuss them below. This is by no means an exhaustive list of the advice that Hamming gives in this talk, but is some of my favorite advice. If you don’t read the talk, you’ll miss important advice, such as how to teach your boss.

The talk focuses on necessary conditions and sufficient conditions for performing great research. You may not be a researcher, but Hamming mentions some great general lessons that apply to all areas of life. When I mention research below, the careful reader should mentally substitute his or her own interest.

For those of you who do not know of Richard Hamming, all you need to do is peruse his list of accomplishments to get a sense of his qualifications to give a talk on world-class research. Enough is named after him that he starts to run into the Euler effect: if you take the right class, the answer to the question "Who do you think discovered this?" is invariably "Hamming!"

I’m not kidding, though: you should definitely read the talk .

More Than Luck: Courage

The first thing that the great researcher must have on their side, according to Hamming, is courage. The person who sets out to do great work should say to themselves, "I would like to do first-class work." Great work is not done by luck, after all.

Was Euler lucky to work on so many great math theorems? Was Hamming? How about Einstein? The fact of the matter is that it is partly luck, but that these individuals were trying to do good work. Luck isn’t the entire part of the equation. As Pasteur said, "Luck favors the prepared mind." Richard Hamming is even more assertive that luck has little to do with anything:

The prepared mind sooner or later finds something important and does it. So yes, it is luck. The particular thing you do is luck, but that you do something is not.
…
I want to dispose of this matter of luck as being the sole criterion whether you do great work or not. I claim you have some, but not total, control over it. And I will quote, finally, Newton on the matter. Newton said, "If others would think as hard as I did, then they would get similar results."

In reality, great work is done by those who dare to do great work. He uses Claude Shannon as an example. Hamming posits that Shannon’s "major theorem" was a theorem of great courage.

If you think you can’t, almost surely you are not going to. Courage is one of the things that Shannon had supremely. You have only to think of his major theorem. He wants to create a method of coding, but he doesn’t know what to do so he makes a random code. Then he is stuck. And then he asks the impossible question, “What would the average random code do?” He then proves that the average code is arbitrarily good, and that therefore there must be at least one good code. Who but a man of infinite courage could have dared to think those thoughts?

Plant Acorns

The most important part of Hamming’s speech is the idea of planting acorns. Even if Hamming himself does not think this is the case, he mentions the idea enough times that it would certainly get an honorable mention from him. Hamming also mentions that failing to do this will cause great scientists to only become good scientists, but more on that below.

In order to perform really world-class research, you need to work on lots of little problems, and file away the answers. If you develop general solutions to a lot of small problems, and write them so that others can build upon the work, then you will somehow be involved in their eventual solution. Either you will finally have all of the pieces that you need to attack a great problem, or you will contribute to someone else who puts all of the pieces together. After all, as Hamming notes, we should be standing on the shoulders of others, not their toes!

The Weight of Success

Let’s say that your intelligence and determination pay off — with a little bit of luck. You are now world-famous in your field, and everybody expects you to do great things henceforth. This is a critical tipping point, one where the rest of humanity is going to try to weigh you down.

At one point in the speech, Hamming declares, "The Institute for Advanced Study in Princeton, in my opinion, has ruined more good scientists than any institution has created, judged by what they did before they came and judged by what they did after. Not that they weren’t good afterwards, but they were superb before they got there and were only good afterwards." This is a hell of a condemnation of the scientific community: that they would needlessly bog down a great name rather than let the name do some more great work.

The biggest problem is that after your first success, people expect only success from you. You are supposed to only work on great problems, failing to "plant the acorns" that eventually lead to great work. Claude Shannon fell victim to this. After all, once you have developed an entirely new field as your first act, what can be the encore?

The Value of Kindness and Presentation

I feel that this is one of the important points that will be most overlooked, so make sure you read and understand these parts of Hamming’s speech. Hamming goes out of his way to point out to the audience that one of the best things you can do for your own career is to always be nice to the supporting cast of characters that surrounds you. Hamming gives several different examples of this, and speaks at length of the consequences of failing to bend in the right places.

Another personality defect is ego assertion and I’ll speak in this case of my own experience. I came from Los Alamos and in the early days I was using a machine in New York at 590 Madison Avenue where we merely rented time. I was still dressing in western clothes, big slash pockets, a bolo and all those things. I vaguely noticed that I was not getting as good service as other people. So I set out to measure. You came in and you waited for your turn; I felt I was not getting a fair deal. I said to myself, “Why? No Vice President at IBM said, `Give Hamming a bad time’. It is the secretaries at the bottom who are doing this. When a slot appears, they’ll rush to find someone to slip in, but they go out and find somebody else. Now, why? I haven’t mistreated them.” Answer, I wasn’t dressing the way they felt somebody in that situation should. It came down to just that - I wasn’t dressing properly. I had to make the decision - was I going to assert my ego and dress the way I wanted to and have it steadily drain my effort from my professional life, or was I going to appear to conform better? I decided I would make an effort to appear to conform properly. The moment I did, I got much better service. And now, as an old colorful character, I get better service than other people.

…

By taking the trouble to tell jokes to the secretaries and being a little friendly, I got superb secretarial help. For instance, one time for some idiot reason all the reproducing services at Murray Hill were tied up. Don’t ask me how, but they were. I wanted something done. My secretary called up somebody at Holmdel, hopped the company car, made the hour-long trip down and got it reproduced, and then came back. It was a payoff for the times I had made an effort to cheer her up, tell her jokes and be friendly; it was that little extra work that later paid off for me. By realizing you have to use the system and studying how to get the system to do your work, you learn how to adapt the system to your desires. Or you can fight it steadily, as a small undeclared war, for the whole of your life.

He also talks at length about other scientists who have decided to "assert their egos" rather than appear nice and play the game. If they decide that they aren’t going to make the "appearance of conforming", these people are not going to get extra help. They will need to fight at every moment in order to get the extra help, so they will be putting extra energy into the wrong pursuits in life.

At the end of the day, this can be reduced to swimming. How far are you going to swim with the current, and how far can you make it against the current?

Drive

We all know about quotes on drive by Edison , but Hamming says it best:

Now for the matter of drive. You observe that most great scientists have tremendous drive. I worked for ten years with John Tukey at Bell Labs. He had tremendous drive. One day about three or four years after I joined, I discovered that John Tukey was slightly younger than I was. John was a genius and I clearly was not. Well I went storming into Bode’s office and said, “How can anybody my age know as much as John Tukey does?” He leaned back in his chair, put his hands behind his head, grinned slightly, and said, “You would be surprised Hamming, how much you would know if you worked as hard as he did that many years.” I simply slunk out of the office!

Think Great Thoughts

Hamming clearly enjoys this particular aspect of his approach to life. He talks about how, every Friday, he would only think great thoughts. Not particular thoughts about work, but questions like "What will be the role of computers in all of AT&T?"

Putting yourself in the mindset of only thinking great thoughts for a particular period of time leads you to view oncoming trends and learn how to best take advantage of them. If you can see which way the wave is breaking, you will know which direction you will need to work towards.

Selling Your Work

Hamming himself admits that this is a particularly distasteful aspect of the job of a scientist, but it is necessary to sell your research. Everybody out there is trying like hell to find their own research, so you need to show them why your work is so great.

The first skill that you must learn is to sharpen your communication skills. You can’t show people why your work is so great if you can’t communicate this. In my opinion, this can sometimes be even better than being truly great: after all, Stephen Wolfram has walked into the scientific spotlight with perhaps as much bombast as science.

You must learn to excel at all forms of talking: not only should you be able to chime in during informal conversations and assert your viewpoint, but you also must be able to get up in front of large crowds of people and give excellent talks.

Hamming speaks at length about what is necessary to give a good talk. The first thing that the scientist must do is to overcome the urge to give an extremely detailed technical talk. Obviously, this is not always possible, but there are excellent odds that your audience will not be interested in a wholly technical talk. They would like to see an explanation as to why a solution is important rather than the details of the solution.

In general, it is important to examine closely the habits of those whose words carry great weight. What do they do differently? They are clearly causing an emotional effect inside of people, and it is important to try to learn from their presentation skills and mimic what they do properly.

Know Thyself

Hamming says that it is important to know what your strengths and weaknesses are. It is important to play to your strengths, it is important to help your weaknesses, but it is also truly helpful to be able to turn you weaknesses into assets. Hamming says that he was able to use his ego to his advantage:

I knew that most people who took a sabbatical to write a book, didn’t finish it on time. So before I left, I told all my friends that when I come back, that book was going to be done! Yes, I would have it done - I’d have been ashamed to come back without it! I used my ego to make myself behave the way I wanted to.

In Summary

Hamming’s conclusion of the speech says it best:

In summary, I claim that some of the reasons why so many people who have greatness within their grasp don’t succeed are: they don’t work on important problems, they don’t become emotionally involved, they don’t try and change what is difficult to some other situation which is easily done but is still important, and they keep giving themselves alibis why they don’t. They keep saying that it is a matter of luck. I’ve told you how easy it is; furthermore I’ve told you how to reform. Therefore, go forth and become great scientists!"

My parents have a long-standing Christmas tradition of making my sister and I wait for everything to be just perfect before we come downstairs and see the presents that had been laid out. When we were younger, my Dad would shake bells in order to announce Santa’s departure. My sister and I ran downstairs in a vain attempt to see Santa, only to have my Dad yell "You just missed him! Look at him go! Do you see him across the street?"

Obviously, little 7 year old me was suspicious. I had heard at school –to no surprise– there was no Santa, and there were a lot of holes in my Dad’s story. There was no way that my Dad was mysteriously able to see Santa. On top of that, Santa was supposed to come at midnight.

That year, I ran downstairs as fast as I could, but my Mom yelled for me to slow down, and I did, and I couldn’t prove that my Dad was the one that was ringing the bells — even when I found the bells! Santa simply left them for us. He’s a giver, after all.

That was a challenge. I was going to do the impossible. I was going to outsmart my parents the next year.

My plan was simply to practice running down the stairs as quickly as I could, in as few bounds as I could, and catch my Dad ringing the bells. My speed had almost caught him off-guard this year, and if I could actually let gravity carry me down half of the stairs, then I would land and see him. I was facing some pretty heavy constraints, in that my Dad has gotten up unimaginably earlier than I have my entire life, and my parents did not let us go downstairs on Christmas until they said so. I didn’t have access to camera technology. My only real option was to catch them in the act.

This plan is obviously weak, and paled in comparison to future plans to catch my parents playing Santa –which involved undetectable objects like bits of fishing line laid on the floor. It had a decent basis, though: I just had to surprise them. They would never expect me to practically jump down the stairs to catch my Dad pretending to be Santa.

I practiced throughout the year. I got pretty good at taking the stairs in two or three bounds and landing with nary a sound. Finally, Christmas comes, and my mom mischievously lets me go downstairs.

Jangle Jangle Jangle! goes the bells downstairs. My sister and I take off for the stairs, and I leap down the stairs in a few bounds (botched maybe a little in my excitement). I land and simultaneously look in the room triumphantly (as the bells did not stop), and I see….. a room with presents, devoid of people!

Shocked, I stared in the room for a few seconds, and then flew back upstairs to my parents room. They were lying in their bed, laughing at me. They asked if Santa had come, to which I had no reply. We went back downstairs to open presents, and Christmas continued like normal.

For years I begged them to know how they did it, and I had my own theories. There were just too many different ways that they could have done it. Tape recorders and well-placed neighbors were my two biggest suspects, but the truth turned out to be far better.

How They Did It

My parents knew that they had almost been caught when I ran down the stairs the year before. They perfectly predicted my next move: to get down the stairs as quick as I could. My parents wanted to figure out a way that they could beat me at my own game.

By providence, their bedroom was situated above the room where we opened our presents. My Dad, on Christmas Eve, ran a string out from the bedroom window, over the roof, and down to the window of the room where we would open our presents. He tied the bells on the end of the string. He said that he was worried that it wouldn’t really produce the same effect, but it worked perfectly. They could jangle it all they wanted from their room and make it sound like someone was shaking the bells in the living room.

My parents were sitting in the comfort of their own bed while I ran downstairs, puzzled over the empty room, ran back upstairs, and threw their door open in pure confusion.

They still say that the best part was the absolutely confused look on my face, knowing they had tricked me, not knowing how.

I looked at the following methodologies:

• Scrum
• XP
• IBM’s Rational Unified Process
• The Joel Test

Ideas such as literate programming were ignored from the list, as any of the processes listed above could also be done in conjunction with literate programming.

Here’s my list with explanations. I reckon that all of the methodologies are all an excuse for doing the following:

Think about what your code does before you write it.

"Of course you should do this!" I hear you screaming. However, even the obvious needs to be included in a methodology. For something so obvious, there were quite a few different ways of handling this idea.

The Joel Test, for example, asks "Do you have a spec?" This is similar to the Rational Unified Process, which demands a large up-front Elaboration phase to be mostly complete before any coding begins. These are up-front and monolithic methods of designing products, but it is difficult to argue with the success of either Fog Creek or IBM.

On the opposite end of the spectrum we have Scrum and Extreme Programming, which take release planning on a much more granular scale. At the beginning of the project iteration, you meet with the customers and decide what and how you will attempt to do over the iteration. The difference between Extreme Programming and Scrum is the length of the sprint iterations. Scrum requires that you meet with customers at the beginning of the sprint (15-30 days), and then freeze the requirements over the course of the sprint. Extreme Programming, on the other hand, sets this at about a weekly basis.

Make sure your own code works.

Extreme Programming and The Joel Test are both in-your-face in this regard. The Joel Test specifies that there is a bug database as well as an effort to fix bugs before new releases. Extreme Programming is a test-first methodology, so your code starts out failing the tests (as your code is not even written to begin with), and your task is finished when your code passes all of the necessary tests.

Testing is also a specified phase in the Rational Unified Process, which hints that there should be some form of an automated testing script. Scrum, as a methodology, does not explicitly have a testing requirement, but every single day the team is required to talk about their progress, as well as any roadblocks that they encounter. This is a good encouragement to make sure that the code works, as you will be talking about it on a daily basis.

Frequently check to see if code works.

This was one of the most common ideas between all of the methodologies.

The Joel Test specifies that the programmer should both be able to have a one-click build as well as be able to have access to daily builds. Extreme Programming and Scrum both focus on tiny releases. The IBM Rational Unified Process specifies that you should be able to "demonstrate value iteratively," which does mean to have frequent builds — once you transfer from business-ese.

Have someone else make sure your code works.

This was another string thread through all of the different methodologies, and nowhere was this more evident than Extreme Programming. First off, Extreme Programming dictates that programming is done in pairs. While you are typing away at the keyboard, another programmer is behind you, making sure that everything you write is a) valid, and b) in the spirit of the rest of the program. Unit tests also provide an independent verification (if the tests are correct).

The Joel Test strongly emphasizes this point. It specifies that the programmers are supposed to not only have testers, but are supposed to be able to easily do hallway usability testing. Your code is getting worked on from two different angles: not only are all of the module interactions being tested by the testers, but your interface is also being vetted by your fellow programmers.

Scrum and XP also have the results of the project placed in front of the customer frequently to see that what is being produced is ultimately what the customer would like to see.

The Rational Unified Process encourages the iterative development to bring the customers in on releases in order to allow them to weigh in on progress. It also has a specified testing segment, which encourages large teams to form individual testing units that examine the interactions between modules.

Fine Code Granulation

By fine code granulation, I mean that the code should be broken down into the smallest possible functional units. The Rational Unified Process, Scrum, and Extreme Programming all actively encourage participants to have refined iterations with deliverables at the end of each iteration. Granted, this does not necessitiate that the code is modular, but it certainly encourages it. The Joel Test specifies that there should be a daily build that can be tested and monitored for correctness.

In my own personal experience, this is one of the most important aspects of finishing a project quickly: it’s easier to figure out why a function named "determinant()" is failing than it is to figure out why the determinant section of a function named "matrix_inverse()" is failing.

My Question: Is this a list with all of the necessary and sufficient items?

Should source control be on the list? Probably, but some of the successful projects treat it as a fundimental assumption as opposed to a requirement. Is it always necessary for developers to have flawless working conditions, as Joel claims, or is it sometimes necessary to have the end-of-project crunch?

Truth is ever to be found in simplicity, and not in the multiplicity and confusion of things.

~ Isaac Newton, "Rules for methodizing the Apocalypse", Rule 9

In the article “Calculus via O Notation,” Alexandre Borovik transcribes a letter written by Donald Knuth where Knuth describes the idea of calculus in terms of notation. He shows that not only is it possible to use notation in integration and derivation, but that the notation also gives you a built-in error estimator.

While the notation is unfamiliar at first, it has a few added advantages. For one, the term of the equation describes the estimated error of your calculation, which is great for programmers.

O Notation via Calculus

I learned the opposite relationship between calculus and notation: that you can use calculus to derive the estimate of an algorithm!

The method uses integration, and the method is easier to demonstrate using a simple example than to explain outright:

Contrived Example: Let’s say that we want to find the algorithmic complexity (as measured by multiplications) in the following loop:

  int a = 0;
  for(int i=0; i<n; ++i)
      for(int j = 0; j<n; ++j)
          for(int k = 0; k<n; ++k)
              a*=2;

We can trivially rewrite the sum of the loop operations with sigma notation:

Therefore, the complexity of the loop is .

We can also, more informally, treat this as the definite integral with respect to n. If we look at the inner loop, since we are performing 1 operation n times, our output will be linear. If we have a linear output on the second loop, the output will be . If we can generalize the summation for any n, we can calculate the integral from 1 to n and determine the order by which the function grows.

(Note: For simplicity, I am dropping lower-order terms, since they obviously do not factor into the answer.)

Why Does This Work?

We are looking at the order of the growth of the area under the curve. This order will be the same order that the algorithm grows, as this is based on the same argument by which the rectangle rule works — the number of calculations for each n is a rectangle approximation of a continuous function and grows at the same rate for larger n.

It is important to note that this does not give you an exact computation of the number of operations in your algorithm. Instead, this gives you the order of growth of the algorithm with problem size n.

Unfortunately, I can only give an informal argument for why this should work. The professor who introduced this technique to me did it in an offhand remark, so I’m not sure whether this idea is applicable in all situations. If you have any remarks with a solid mathematical basis, I’d love to hear them.

Better Example: Mergesort

We all know that the number of comparisons in Mergesort grows in the worst case. Let’s use the integration method to double-check this.

Small Example: An array of 16 elements

First, we need to break up the problem in terms of a summation of n. Let’s pick the number of comparisons of arrays of size {1, 2, 4, 8, …} while Mergesorting an array of 16 elements.

First, we have all of the comparisons of arrays of size 1. We will be performing 8 different sets of comparisons, and we will need 1 comparison in each set.

Total comparisons: 8 * 1

Second, all of the comparisons of arrays of size 2. We will be performing 4 different sets of comparisons, and we will need 3 comparisons per set.

Total comparisons: 4 * 3

Third, all of the comparisons of arrays of size 4. We will be performing 2 different sets of comparisons, and we will need 7 comparisons per set.

Total comparisons: 2 * 7

Lastly, all of the comparisons of arrays of size 8. We have only one set of comparisons, and we will need 15 comparisons per set.

Total comparisons: 1 * 15

Second, now that we have the different sets, we need to look for a formula that will give us the right number of comparisons for each stage x.

Stage 1: 8 * 1 = 2^3 * (2^1 - 1)

Stage 2: 4 * 3 = 2^2 * (2^2 - 1)

Stage 3: 2 * 7 = 2^1 * (2^3 - 1)

Stage 4: 1 * 15 = 2^0 * (2^4 - 1)

Our formula for each stage x is therefore:

Third, we integrate our formula from 1 to n.

Our integral will be:

Plugging this quickly into Mathematica, we get the answer back:

which, after working through the Logjam, is found to be .

When is This Useful?

For some people, never: recurrence formulas and basic combinatorics is all they will ever need to solve recurrences. However, some students (mathematicians especially) may be more comfortable dealing with calculus than recurrence formulas.

It never hurts to have another tool in your kit.

“What we meant by that was when you start looking at a problem and it seems really simple with all these simple solutions, you don’t really understand the complexity of the problem. And your solutions are way too oversimplified, and they don’t work. Then you get into the problem, and you see it’s really complicated. And you come up with all these convoluted solutions. That’s sort of the middle, and that’s where most people stop, and the solutions tend to work for a while. But the really great person will keep on going and find, sort of, the key, underlying principle of the problem. And come up with a beautiful elegant solution that works.”

~ Steve Jobs: The Perfect Thing; How the iPod Shuffles; Commerce, Culture, and Coolness by Steven Levy

I may hang the last two lines of this quote over my computer. This is a really great summary of the creative process that I’ve noticed as I’ve attacked various math and design problems. Getting complex problems right is hard, and finding easy solutions that are applicable to a whole class of problems is damn near impossible. The ability to solve a problem elegantly is not a gift, but won through determination and practice.

A year and a half ago, I abandoned Visual Studio to try to use the two most popular code editors: Vim and Emacs. Both of them have their advantages, but fall short of being the perfect editor.

Vim

The first coder’s text editor I used was Vim. It took quite a while to get past its infamous learning curve, but once I did, it was wonderful.

Advantages

• Easy-to-Reach commands: The basic movement keys in Vim are right under your fingertips. Rather than wasting precious tenths of a second moving back and forth to the arrow keys, all you need to do is shift your right hand over. ‘h’ is left, ‘l’ is right, ‘j’ is down, and ‘k’ is up. This may seem weird at first, but after two weeks of using it, you’ll be disappointed whenever you’re typing in any other application.Not only that, but a lot of the extra movement keys are very close to the home row. ‘$’ and ‘0′, end and beginning of the line, respectively, are nearby. So is ‘^’, which gets you to the first whitespace character on the line. So is ‘G’, or the goto-line command. So is ‘w’, the “go to next word” command. No extra modifier keys needed.

• Modal Editing: A lot of the power that Vim has comes from the fact that keys work differently based on what mode that you are in. If you are in Command Mode (the default mode in Vim), the ‘o’ key inserts a line below the current one and changes the mode to Editing Mode (which lets you enter text). If you are in Visual Mode (which is a selection mode), the ‘o’ key moves you to the other end of the selection.I’ve heard some people say that this is a strike against Vim, but I have never had any problem with this.

• <action><location>: Once Vim beginners have learned all of the basic ways to move through a document (forward/previous character, forward/previous word, forward/previous line, searching, beginning/end line, etc), the next big epiphany is that you can combine these searches with commands. ‘dw’ deletes to the beginning of the next word. ‘d$’ deletes to the end of the line. ‘dn’ deletes to the next result in a search. The movements can be combined with commands to make complex text manipulation a piece of cake.Vim also comes with dozens of mnemonic commands, such as ‘daw’ (”delete a word”, deletes the word under the cursor, no matter where you started in the word).

• Easy Repetition: Vim makes repetition very easy. All you need to do is type a number before you enter the command, and Vim will repeat it that many times. Want to delete the next 6 lines? Type ‘6dd’. Delete 6 words? ‘6daw’.

• Quick Scripting: In Vim, this is one of the best timesavers available. If you have an action that you would like to do over and over again, you can store a key sequence in a buffer to recall later. For example, to start a macro, all you need to do is type ‘qa’, which will store a macro in the ‘a’ buffer. To finish, type ‘q’ again. To use the macro, type ‘@a’. To repeat it 100 times. type ‘100@a’. It’s that easy.

• Fast Search: Searching in Vim is fantastically easy: all you need to do is type ‘/’, and then type your search regular expression. Search and replace is a lot more arcane: “:%s/<search regexp>/<replacement text>/gc” will do a search and replace globally and ask you for confirmation for each replacement. This is a common theme: there is less overhead to executing Vim commands. Sure, there are exceptions, but the stuff you use 80% of the time has been optimized for time.

• Tabs, Buffers, Frames, Windows: All of the goodies you could ever ask for in this category. You have access to all of the standard ways to move data around. Miss buffers from Emacs? You get to use them in Vim. Miss tabs from Visual Studio? Type “:tabe” and use the tabs. Do you like having split screen code? You get that, too.

• Customizable: Vim has its own scripting language that allows coders to build extensions. The site has a few thousand extensions that have been developed by the community, but I’ve always found it difficult to navigate.

Disadvantages

• Chokes to death on multiple long lines: When I mean long, I’m not saying that Vim is a little slow on lines with 100 characters. If you had a file with multiple lines larger than the screen size (if you had a file of DNA sequences, for instance), you will probably not get the display behavior that you want with the default settings.

• The Learning Curve: When you finally get up to speed using Vim, it is fantastic. However, it will take you a few weeks before you get used to all of the new commands, and even longer before you stop mixing up the movement keys and the home row. However, this is the kind of tool that is optimized for experts and not beginners.

• Don’t Sneeze and Type: Have you ever started typing a sentence while in command mode and not in insert mode? Me too. I’ve watched half of my file disappear before my very eyes. Fortunately, the undo key (’u') is not very far away.

Emacs

Disclaimer: So that I don’t summon RMS from the depths of the Marianas Trench, mentally replace all instances of “Emacs” with “GNU Emacs”. It’s easier to type, and everyone knows what I meant, dammit.

Note: In key sequences, “C” means <Ctrl> and “M” means <Alt>. So C-M-Del means “<Ctrl><Alt><Del>”

Advantages

• Easier to Learn: Emacs has a better learning curve than Vim, as the user is automatically able to start typing. It’s not until they try to save that they run into their first problem. However, the file menu helpfully gives the users the proper command.

• Many Commands: Emacs has quite a bit of built in commands. To me, it seems like it has more than Vim, but that could just be a shortcoming of mine. It has a lot of helpful commands that Vim doesn’t have built in, such as transposition. This allows you to drag a word forward or backwards in a sentence or an argument list.

• Everything but the Kitchen Sink: The main beauty of Emacs is that you shouldn’t need to leave your text editor in order to perform mundane tasks related to coding. Sure, Vim lets you compile and debug from the editor, but Emacs lets you check email, use calculators, play games. You can also perform any programming-related task you’d like. If you know a little eLisp (Emacs Lisp), you can even evaluate Lisp expressions inside of Emacs by default.

• Better Auto-Indent: It seems like the coding modes in Emacs understand the document structure of programs a lot better, as they get tabbing right very frequently. Some of the modes are also intelligent when there is a tabbing ambiguity. For instance, in the Python writing mode, pressing the <Tab> key multiple times gives you all of the different possible legal tab positions.

• Great Extension Community: Combining the magic of Lisp with the magic of Emacs, the community has been writing every imaginable extension you can think of since the mid ’80s.

• Good Copy/Cut Behavior: By default, the copy/cut buffer in Emacs goes through “rings”, where you can repeatedly hit M-y in order to get previous items in the copy buffer. In Vim, you need to specify which buffer should be used as a copy, as it will continually overwrite the same one.

• Good Buffer Support: Once you learn the different buffer commands, they turn out to be a very powerful way to switch documents. You can open new buffers as a scratch pad and turn to old ones in the blink of an eye.

Disadvantages

• Ragtime Typing: Due to the use of modifier chords, you have to move your hands around quite a bit. The most commonly used key is the <Ctrl> key, so if your keyboard only has one, it is recommended that you swap your <Ctrl> and <Caps Lock> keys. For most of the simple movement, you need to use two keys to move instead of one: C-f to move forward, for instance.

• Emacs Pinky: After a few weeks of use, I actually started getting the dreaded “Emacs Pinky”, a numb sensation in the pinky from constant use of the modifier keys. I took it easy for a few days and wore a wrist brace to find out when I’ve been abusing hand stretches, and the problem has since disappeared. However, the phenomena is very real, so be careful.

Somewhere There Is a Great Text Editor

Both of the text editors mentioned here have a lot of great features, but they also have a lot of drawbacks that are not mentioned here. Some certain commands have a lot more overhead then they should. Granted, you can just rebind keys to the command you want. However, this doesn’t always work when you are bouncing back-and-forth between a lot of different computers.

It would be great if Vim had the “kitchen sink” philosophy of Emacs built in, because then I’d never have to leave Vim and could forever revel in its modal glory. A lot of the buffer/window/tab commands in Vim feel like they have too much typing overhead. For example, typing “:tabn” over and over again to switch tabs gets old.

In turn, it would be great if Emacs had a lot less typing overhead for some of its commands. Viper (using VI bindings in Emacs) is a fair compromise, but it somehow feels cheap, and doesn’t really get away from the Ragtime Typing problem for anything but the most common movements.

In general, I’ve found that Emacs is a better writer than Vim, as it understands the structure of the document much better. However, I’ve found that Vim is a much better editor: I can perform a lot of the common editing commands a lot faster in Vim than in Emacs. It’s missing a few, like word dragging, but that is easily replaced by deleting the word and retyping it in the necessary location.

I think that a great text editor would have the following criteria:

• Modal (helps cut down on keystrokes).
• Low typing overhead for 99% of the most common editing tasks.
• Easy on the C-M chord modifiers for the common tasks.
• “The Kitchen Sink” philosophy. The programmer should never need to leave the editor to do common tasks like check email, the weather, their RSS reader, play basic games, etc.
• Great understanding of the document structure, not just best-guessing the tabbing like Vim does.
• Easy tabs/buffers/frames/windows.
• Great integration with OS and local tools.

Anything else?