Justin starts a blog

Write bad code now, improve it later?

mikehudack:

marco:

Jack Cheng quoted Adam Wiggins’ Order of Operations for writing code:

1. Make it work.
2. Make it elegant.
3. Make it fast.
4. Make it secure.

I disagree. The biggest problem is that this ignores reality: once it works, how likely are you to go back and make it elegant, fast, and secure? If it’s for personal use, how likely are you to care? If it’s for work, how likely is your employer to be willing to devote resources to “clean up” something that already works? Even the best developers, and the best employers, are pretty bad at this.

You should be writing elegant code very early in the process. There’s always room for improvement, of course, but there’s never an excuse to write sloppy code, even if it’s only running once and you’re the only person ever seeing it.

“Make it fast” can arguably be a lower priority for simple optimizations and constant-time reductions. But algorithmic complexity needs to be considered from the beginning.

And saving “Make it secure” for last seems like a disaster. Imagine how you’d feel, and how you’d even begin to tackle this problem, if someone handed you a pile of another programmer’s code and said, “Make this secure.”

Write good code the first time.

Charles exalts the merits of Red, Green, Refactor development, which is similar. I think it’s OK to make things work first, and then go back and make it fast and elegant.

I agree that security isn’t something that you apply as a refactoring. It’s inherent in the way you design and in the adherence to a methodology. You write secure code because you have a heightened sense of paranoia, both about the users out there, and about the other developers who may come to rely on your code. To apply that paranoia as a refactoring would seem to leave open the possibility of missing things.