Write good code now, improve it later.
Jack Cheng quoted Adam Wiggins’ Order of Operations for writing code:
- Make it work.
- Make it elegant.
- Make it fast.
- 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.
I disagree with Marco, unless the problem and solution are already perfectly defined (which is rare). In a world of fast changing requirements, you want to be in a prototyping mindset. Make it work. See it, use it, tweak it. You’re not going to get the interactions perfect the first time. This goes back to 37signals’ Getting Real idea - don’t waste time doing lots of planning, just start building. Only after the requirements have stabilized do you want to commit to production quality.
My guess is that Dave and Marco have different ideas of what it means for code to be elegant. To me, elegant code is simple, readable, and meets the current requirements. This should be a developer’s default style. Ideally, “make it work” and “make it elegant” is just one step.
This usually doesn’t mean that you have to spend tons of time planning or designing to produce elegant code. When starting a new task, in many cases you can think about it for a few minutes, maybe talk it over with a teammate, and then start coding. Write simple code that reads clearly. Do this over and over as you add features (refactoring and improving as you go) and eventually a nice design will fall out.
If you’re writting to ship to production, secure and “fast enough” need to be part of the requirements. If your code isn’t either of these, you aren’t done yet.
If you’re just coding up a prototype, there’s a decent chance that your code will eventually grow up into a real product (whether you like it or not). Being sloppy in an attempt to get your prototype done faster will only slow you down in the long run. Naturally, a prototype wouldn’t be a prototype if it took as long as the real thing… the corners you cut to build a prototype should be in requirements and features, not in readability or simplicity of the code.
10 months ago