The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code.

I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering. Writing good code is way faster, almost from the get-go. You reap the benefits on _day two_, literally.

I am not sure what they taught you in SE - I found most of what I learned to be true in the field, however, I also found it shocking how little this seemingly common knowledge is used out there.

I directly benefit from the incompetence of most software engineers out there, but I much prefer to work with good people.

I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering.

You keep saying this as if you believe that writing unit tests automatically means you've written good code. You can possibly have good code without unit tests. You can, more importantly, have awful code with unit tests.

For me, a major axis of "good" for code is maintainability. Therefore, writing good code means spending some time considering names rather than just using the first ones that pop into your head as you type. It means thinking about whether these superficially similar pieces of code are really related enough for code reuse to be beneficial, or whether it's only incidental similarity and really should exist in both places independently in your codebase. It's about writing small pieces of functionality yourself when otherwise you'd drop in a library that dwarfs your written code -- sure, dropping in the library is fast and easy, but if something goes wrong, you're now debugging 100K lines of someone else's code instead of the 1K lines of in-house code it would have taken to do just what you needed...

Writing good code in this way often takes considerably longer than just cranking out something that works for now, and the largest factor is not time to write unit tests, but time to think about what you're doing rather than coding at the speed you can type.

Actually he didn't state there was a causal link between writing unit tests and writing good code. In fact, if you look closely, you see that there is a full stop in between those two statements, they are in different sentences!

I'd happily believe that someone who writes good code can also write good unit tests.

I'd also strongly assert the negative of that. Someone who writes bad code cannot possibly write good unit tests, because unit tests are code.

Everything else you say I agree with 110%. Good names for code entities: yes, indeed. Taking some time up front and thinking about the design and how it will fit together... yes, a thousand times yes.

However, the last bit about it taking longer to do this than just cranking something out I (and I think the person to whom you are replying) would disagree with except in the most trivial cases.

If what you are doing can be done by banging out a perl one-liner, by all means do that and move on. Except that of coruse if you ever need to debug it or maintain it there is a higher cost involved. For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out.

Well, idiomatically, the second sentence is a kind of restatement of the first. My comment was really a reply to all nikster's similar comments in this page; he's talking about unit tests, and those he's talking to are mentioning good code, so it seems as though he believes that good code is essentially the same as "have unit tests", which is what I took issue with. :)

For all code, as soon as you start debugging it you start reaping the rewards of doing it properly. For non-trivial code, those costs will rapidly outweigh the initial savings of just banging something out.

I actually don't disagree with this at all. It's just that I don't think the costs will necessarily be in hours spent, though sometimes they will be. Sometimes the cost will be that you have to find someone at least as smart as the original coder, and that might be hard. It might be so hard that hiring someone to completely rewrite the system from scratch might be cheaper.

So, I'm not saying that people shouldn't take the time to write good code. I'm saying that it's possible to write working code at the speed of typing for some people on some projects, and this can be kept up for long enough for the savings to completely outweigh the other costs if the number of bugs is small enough. I wouldn't recommend depending on this being possible for a given team and project, but I've seen it done -- I've done it myself. The result wasn't what I'd call good code, but it worked and it was done in time to be sold for enough to keep the wolf from the door; if I'd spent half my coding time writing tests on that one, I would simply have failed to deliver.

Like what?

"It's crazy to spend months designing software, "

Months? No one said anything about months!

You're doing the standard methodology bait-and-switch evangelism trick. Specifically, that the only alternative to $flavour_of_the_month methodology is Waterfall. Which is rubbish.

But by all means, enjoy your strawman karma.

"Most of the stuff taught in Software Engineering courses is complete bullshit"

Geez Louise, is that what set you off? The mere mention of Software Engineering? I'm sorry your experience with your software engineering course was so negative. We learned about useful things like big O notation and the mythical man month. Now I'll be the first to admit that I don't necessarily apply that stuff every day (particularly the big O stuff as I avoid premature optimisation... oh wait, that's another software engineering thing, shoot, sorry about that). I think for instance it's been almost 10 years since I had a discussion with someone about cyclomatic complexity (he wanted to twist the code in strange and bizarre ways in order to avoid it, I wanted to handle it by checking the parameters were good at the start of the function instead. I won because my way was simpler, more robust, faster to implement, and actually worked :D ). But knowledge of that stuff is useful whenever I do testing, and it informs everything I do, I have synthesized it.

Sounds like your comp sci professors sucked. Sorry about that, mine were very good (or rather, I avoided the courses of those that weren't)