How I stopped writing awesome code(jhovgaard.net)
jhovgaard.net
How I stopped writing awesome code
http://jhovgaard.net/how-i-stopped-writing-awesome-code
3 comments
I'm by no means a "purist" regarding any specific practice - I agree you don't HAVE TO test everything, write interfaces for everything and all in all write "awesome" code. BUT:
- how often do you interact with other programmers?
- how long is the usual life span of your code (in other words, what's the longest timespan you can expect to touch code you wrote in the past)?
- how big is the app/system you work on?
Imho, this approach ONLY works if the answers to above points are "never", "a few weeks max" and "very small"...
There's a time and place for every coding "style". Neither "TDD everytime" nor "cowboy style forever" are the definite answer.
- how often do you interact with other programmers?
- how long is the usual life span of your code (in other words, what's the longest timespan you can expect to touch code you wrote in the past)?
- how big is the app/system you work on?
Imho, this approach ONLY works if the answers to above points are "never", "a few weeks max" and "very small"...
There's a time and place for every coding "style". Neither "TDD everytime" nor "cowboy style forever" are the definite answer.
> You don't need armor and life, if you kill in one hit!
I don't adhere to the philosophy, but there is something to this if you refuse to do TDD or write unit tests. It's better than nothing and it will catch the most blatant issues if you replicate the user stories carefully. It's what I call "minimum viable testing" (MVT!). However, among other problems, it won't help at all with refactoring.. but I suspect a developer who gives up on unit tests isn't one who's doing much refactoring or structural work anyway? (Points 2 and 4 imply this.)
My personal result of doing all of this is productivity and better products. I can't tell if I did it all wrong, and that's why I'm writing better code now, but I truly believe that I'm not alone. In fact I think that most of us regular web developers, tend to do the same "mistakes" as I did.
There's room for argument over the meanings implied here, especially in tossing up productivity vs code quality. Is ad hoc, spontaneously designed, poorly tested code that's doing the job in production "better" than well planned, well tested code that's still sitting around under development? It could be yes or no, depending on your viewpoint, but it's important to appreciate the nuances and the balance involved.
I'll note, however, that more developers than not do develop in this way and mostly do OK at it. While there's also a large group of developers who'll jump up and down about architecture, clean code, TDD, and various other philosophies (me included sometimes!) there's also a whole world out there unfamiliar with such concepts and still putting together passable software. The key is knowing when and why certain things matter or are useful, and I suspect the author of the article has been getting a feel for that and coming to terms with what disciplines his sort of projects really require (i.e. not many).