When To Write Bad Code
brandonsavage.net
When To Write Bad Code
1–10 of 25 posts
Re: When To Write Bad Code
#2This is a really interesting point of view.
Re: When To Write Bad Code
#3There 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 page.
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.
Re: When To Write Bad Code
#4In most of the code bases when 5+ people work on the same code, it's really hard to add some non-trivial functionality by writing it the proper way from the beginning. BTW I think sticking with the attitude "first specs, then code" is old school in most situations. Some very rough spec will be fine, but a lot of the things you haven't thought of, you encounter while actually playing with the app/widget, or stepping through the debugger (unless you've worked on a product for a very long time and know it inside out).
I find "write working code & then refactor" ridiculously easy when working with Git. Add some tiny new things one-by-one and commit early each time it is more or less stable (so you can revert quickly when you screw it later, instead of doing some crazy debugging). When it's done, squash the commits and refactor.
Re: When To Write Bad Code
#5> When the code is working and you’re ready to move onto the next phase, then you can work on making the code pretty, readable, well-documented and tested. While this flies in the face of concepts like test-driven development...
I disagree that writing "shit code that still works" and TDD have to be mutually exclusive. In fact, if I'm going to go the "just get it done" route, I will almost (but not always) try to set up a few tests for it.
Because nothing sucks harder then going back to crap code and trying to decipher what it's doing. If it's crap code, then it's likely non-orthogonal code, which means changing it will likely break something...etc. etc. Tests help me do the refactoring later.
And, also, how do I know that my shit-code-just-works actually works? Sometimes, it's helpful to write a kind-of-shitty-test to at least verify that it kind of works, if not perfectly.
Re: When To Write Bad Code
#6From the sounds of other developers, I think much of the development community is moving towards this paradigm. Developers have been so inundated with needing to use patterns, designs and other forms that has lead to inefficiencies in designs that were well thought out, but do not apply, instead of inefficiencies from bad code.
Re: When To Write Bad Code
#7> When the code is working and you’re ready to move onto the next phase, then you can work on making the code pretty, readable, well-documented and tested. While this flies in the face of concepts like test-driven development... I disagree that writing "shit code that still works" and TDD have to be mutually exclusive. In fact, if I'm going to go the "just get it done" route, I will almost (but not always) try to set…
The person I was mentoring (that prompted this blog post) was having trouble getting ANY code down on the screen. Being able to write SOMETHING was the hurdle for this developer to overcome.
In most cases though, I agree with you.
Re: When To Write Bad Code
#8"Nothing lives longer than temporary code."
Love this quote. I assumed it was an existing quote/idiom, but it looks to be original.
Re: When To Write Bad Code
#9Isn't this just usual prototyping? I rarely consider best practices when trying to implement a non-trivial prototype because flow and creativity is broken when attempting to adhere to best practices at the same time (in my experience at least).
My current project contains some non-trivial code so there was a lot of prototyping. If I spent time ensuring this code was also well written, I doubt the problems would've been solved because half of my energy and concentration would be spent on scaffolding and not the actual building.
Having said that, I still find documenting the prototype as important as real code. When it comes to refactoring the code, it helps a lot.
Re: When To Write Bad Code
#10"Nothing lives longer than temporary code." Love this quote. I assumed it was an existing quote/idiom, but it looks to be original.
It's not original to me. Not sure where I heard it, but I know it's not mine.