Apr 082004
They’re advertising Colby Cosh’s blog on ESPN now. “What’s Cosh writing about?” “Hockey.” “What’s he writing about next?” “Hockey.” I’m getting the same way about programming. We will release the honest-to-god production version of our software Monday, and the experience has been, shall we say, instructive. The lessons include:
- The trouble with most programmers isn’t that they’re too lazy, it’s that they aren’t lazy enough. Never write anything until you absolutely have no other choice. (Regular readers will note how well I have absorbed this.)
- More classes = less code.
- “Marketing” tends not to attract the sharpest tools in the shed.
- If you refuse to test your own code righteously enough, eventually you can con somebody else into doing it for you.
- You cannot write good business application software unless you understand the business better than the people who make their living at it. This is mostly why business application software sucks, especially when it’s written by people in the business.
- In a client-server application, given the choice between working on the client or the server, always take the server. This is a lemma of the more general principle that at any job you should strive to stay as far away from the customer as possible.
- You never discover the right design until you have written an enormous amount of code based on the wrong design.
- A mediocre programmer is useless. His time would be better spent washing dishes or picking up trash.
- The better two programmers work together, the likelier they are to end up despising each other.
- In programming, especially, is George Pólya’s dictum true that it is often easier to solve the general case. In fact solving the special case is usually a waste of time.
- I’d rather be blogging. Honest.
It is the Way of Code. We test airplanes 6 ways from Sunday before we let them loose on the country. Programs are for the users to test. If there are too many bug reports, we call it "beta".
The problem, of course, with commercial software, is that when we try to make it foolproof, we find out that the fools are more dedicated than we are.
I have no excuse except my obvious national inclination toward Playoff Fever (intensified through sublimation in this case by the failure of my own team to make the postseason) and an extremely dispiriting week that left me somewhat devoid of suitable whimsy and snark. Daylight Savings jetlag, an unusually large bale of hate mail, and whatnot.
"You never discover the right design until you have written an enormous amount of code based on the wrong design."
Which leads to the conclusion that the "initial design phase" should be relatively short, and coding should begin almost immediately; the first round of coding actually constitutes part of the real design phase.
Which also means that a programmer who waits until he is absolutely sure he isn’t going to program himself into a corner before he starts writing code is going to be a remarkably unproductive programmer; such certainty will never exist. Being too much of a perfectionist can kill you in this business. Of course, so can being not enough of a perfectionist and commiting yourself to bad code that ought to be replaced.
Ken: You correctly point up a certain cognitive dissonance between Heuristics #1 and #7. This is the very problem that nearly all modern methods, notably Extreme Programming, try to solve, none of them, in my considerable experience, successfully. Not that I have the answer either. Ultimately the best method for programming may be the same as the best method, according to T.S. Eliot, for literary criticism: to be very intelligent.
"Be very intelligent,’ and have a manager who trusts you to do the right thing.
Then it becomes much simpler. Always work on the most important problem that you have (or can get) enough information to solve–the most important problem as YOU see it. Sometimes that will be your previous solution. And sometimes the important problems you don’t have enough information to solve evaporate before you get to them.
I have to agree with you Will, all else being equal, working on the "most important problem" is the key to success in this or any business. It is also true that a suboptimal solution is actually the optimal solution to any business problem.
Aaron once replied that hes not a very good tester. Actually, Aaron is a very, very good tester. He just never tests. Unfortunately for me, I fell for heuristic 4 and just happen to be on the "marketing" side of 3.
You cannot write good business application software unless you understand the business better than the people who make their living at it. This is mostly why business application software sucks, especially when it’s written by people in the business.
Word.
In a client-server application, given the choice between working on the client or the server, always take the server. This is a lemma of the more general principle that at any job you should strive to stay as far away from the customer as possible.
You won’t get the customer hassle, but you also won’t get as much recognition from the non-tech part of the company.
A mediocre programmer is useless. His time would be better spent washing dishes or picking up trash.
A sufficiently bad programmer is worse than useless, as otherwise productive programmers must take time to throw his code out and substitute code that works.
Great link to George Pólya. From there, Escher too. Way, way good.
"The better two programmers work together, the likelier they are to end up despising each other."
Really? Please explain–it’s certainly counterintuitive.
Programmers usually work well together because they have complementary qualities; an excellent architect and sloppy coder, for example, will do well with someone who is the reverse. Programmers tend, like everyone, to overrate the qualities they possess and underrate the ones they lack. In my example, the architect thinks of his careful partner as a code monkey, while the coder thinks of the architect as a bone-lazy fuckup. Meanwhile, the software gets done.