I have learned that the fastest way to write good code is to write crap code

Good code is something that is fit for purpose. What the client wanted.

Crap code is unoptimized, slow, badly commented, with lots of short cuts (say, calling out to shell to do something rather than writing more code)

Optimize is to clean up, make fast, make clear where it is needed and only there.

Hmmm... good code is a bit more than that. Fir for purpose and with a chance of being useful to the client outside of it's initial purpose.

If we can switch "optimize" to "refactor", you probably have my vote.

refactor is a process that you go through in order to optimize.

Optimize, in my view, is the better word. It is generic, it doesn't have any overtones from any particular methodology. Unlike refactor.

I agree with Patrick. That's why optimization has largely got an "evil" rep.

Sometimes a tangled web of spaghetti is better than not missing a deadline. I'd prefer to deliver crap that was fit for purpose on time than nice code 3 weeks later.

It's only code. Somebody will always be able to fix it. When the client needs is the key thing - not when they don't need it.

In other words - writing clean, readable code is necessary only to the point the client needs it. Since much of it will be thrown away, writing it all as good clean code might be simply vanity.

But that's not what optimize means:

1. To make as useful, effective, or functional as possible; as, to optimize the speed of a computer program.

I agree there is a tendancy to talk about it in just speed terms... but clients understand other kinds of optimization.

Then you're missing the point. The point is that the people who write crap slowly are trying to write good code. I've never seen someone write crap slowly when that is what they meant to do.

The biggest mistake I see in the programmers I mentor is that they try to write "good" code. If instead you try to write "crap" then you don't worry about the quality or the readability or the dirty hacks.

All those things can be optimized through refactoring.

I'm trying to use the language that I use when I teach people. They mostly get it (actually, they do get it - that was just englishness again).

You can optimize speed, memory usage, etc. I'm agreeing, but my interpretation was to learn code, you have to write code. Practice makes perfect.

Robin you're right.

I have learned code. Clearly there might be a lot of people who vote "no" because they haven't learned this *yet*.

To learn code you have to write code. But it can take a lot longer to fix crappy code than to write it well in the first place.

Don't think that your crap code will just be thrown out. There's code written in COBOL 40 years ago that's still being used.

Yeah. And that's probably mostly good code now.

crap is crap. deadline is overrated.

In my experience one can get away with crap code under limited conditions: low complexity, small or isolated, one-two developers, short code life expectancy (demo, proof of concept), limited target environment and audience (platforms and users).
I'd call it quick and dirty and will be very reluctant to use it as the basis for anything worthwhile. It will cost less to start from scratch with a realistic timetable.
For anything but immediate term, it's better to cut features than code quality. It is easier to add features later on a solid code base.
And there's also the happiness factor. Crap code == unhappy programmers, QAs, users, and support.

I made another related claim about optimization.

I tend to follow a principle of "controlled crapness". That is, the system is ostensibly well-designed but it deviates from the design in several places where it makes things quicker to flesh out. It's okay to take shortcuts if you know what it would take to repair them later.

The deviations should be marked with FIXME:, HACK: or other such comments so that firstly you can find them to fix them up later, should it become necessary, and secondly so that other developers that might get put on the project are better able to grok what you were trying to do, despite the fact that it's currently a bit tangled.

There's nothing I find more frustrating than being asked to work on someone else's code, and being sure that there must be a method to the madness but being unable to find it because they didn't explain themselves.

That's interesting.

A friend and colleague of mine (a very succesfull commmercial programer and team leader) takes comments out of code by his programers. His contention is that code should explain itself and you should be able to read it.

Module level comments are ok, he says, because they explain the point of the thing at a high level... but comments on code should be avoided because they're just a maintenance problem.

I don't necessarily agree with him... but I do think that code is the best communication mechanism between programmers.

Oh. And mostly code is unreadable when it is clever. Try and avoid clever code and you'll be alright.

Have you read the Wizard book? Structure and Interpretation of Computer Programs?

I try and make variable names and procedures (or methods or whatever) sensible. I try and follow any doc standard that the language has (java was a real step forward with that).

And *I* do do intra comments.

But Eddie's argument is a really good one. A comment is something else the programmer has to maintain. A lot of the time they change the code, or cut and paste, and don't maintain the comment. So reading the comment is now suddenly misleading. Better to have no comments.

Also, comments are harder to write than code.

The problem with that statement is the "what's necessary".

A lot of the talk about this claim and the others around it could perhaps be cleaned up by me specifying the sort of programmers I have to deal with in corporate Britain. These are people who known the bare minimum about their craft.

5 years ago I taught a bunch of newbie Java programmers for Thomson. I had to explain what a hashtable was, what an exception was, what a class was. These were people who were considered by Thomson to be senior programmers!

Whole different audience then. I also deal with some really clever people who are really bad programmers because of it. They find it very difficult to hire people because they want everybody to do the same mad crap that they do. It's a bit like letting Roly go with Eclipse.