How I stopped writing awesome code

http://jhovgaard.net/how-i-stopped-writing-awesome-code

by jhovgaard • 14 years ago

12 3 14 years ago

Point 1 is about not writing unit tests and instead focusing on acceptance tests since they can replicate the experience of the boss or customers who might ultimately complaint to you. If they can't notice something's wrong, hurrah!

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).

Estragon• 14 years ago

  > You don't need armor and life, if you kill in one hit!

This is why the approach is working for you: you're doing simple stuff.

herval• 14 years ago

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 I stopped writing awesome code

Related Stories