11–20 of 25 posts
After coding the first implementation you will always realize things that you didn't anticipate that could improve the design. It's easier to get it working quickly, find the holes in the algorithm/design, then refactor it to be pretty and maintainable.
It may be unelegant, it may lack any number of "best practices", but if your code solves a problem, doesn't break other things, and can be refactored effectively, it doesn't count as bad.
It allows you to get to grips with the problem and prevents you from just copy-and-pasting large chunks of the "i'll rewrite this later" code into production.
I tend to write my prototypes in Perl as I used to use it a lot in the past for hacking things together. It translates well both to Ruby on Rails (front end) and to C (with low level server magic).
Write prototypes in a language that you don't use in production. It allows you to get to grips with the problem and prevents you from just copy-and-pasting large chunks of the "i'll rewrite this later" code into production. I tend to write my prototypes in Perl as I used to use it a lot in the past for hacking things together. It translates well both to Ruby on Rails (front end) and to C (with low level server magic)…
The RSpec book is a pretty good introduction to this topic.
I used to say that "temporary is the state before permanent". Unfortunately, the crappier the initial code base is, the crappier the production code will be, unless you have a lot of free time to rewrite everything, which about nobody has.
Write prototypes in a language that you don't use in production. It allows you to get to grips with the problem and prevents you from just copy-and-pasting large chunks of the "i'll rewrite this later" code into production. I tend to write my prototypes in Perl as I used to use it a lot in the past for hacking things together. It translates well both to Ruby on Rails (front end) and to C (with low level server magic)…
There is a similar dilema in the creative writing field: "I don't know the right way to say this idea" or "I have writer's block." The general advice from the workshops and masters is to write something , even if you know it's terrible, so you have a place to start and revise (what we would call refactoring). The theory is that revising words is much easier and can be helped along by someone else moreso than a blank…
Amen. Nothing beats the instructive facility of running code and a usable UI.
> However, I've only seen it work in practice when you do go back and refactor. Too often the smelly code gets left behind, and that is why I usually ask others to think through code before writing.
Well, of course it won't work if you don't refactor. You get results analogous to writing with no revision. There's also the trick of knowing when you've revised enough -- amateurs stop before the pros.
"Nothing lives longer than temporary code." Love this quote. I assumed it was an existing quote/idiom, but it looks to be original.