I have a better reason

I write good code that works the first time

J

It is possible to create quality code without tests, and it is possible to create lesser quality code with tests (specifically of the 'bad' variety).

Since I know you, I'm sure you do a better job of presenting it in person, but you make it seem like you aren't aware of the previous point in your post.  

And while I am a firm believer of 'You can get more with a kind word and a two by four, than you can with just a kind word', you might want to consider not suggesting that you can't produce quality code without testing, since that will just turn some people off to your message.

Missed you at the Nov Chicago Alt.NET meeting (know you are NC-bound).  Wanted to heckle you about something.

YMMV.  HTH.

My employer does not pay me to write quality code... I struggle with this on a DAILY basis and they just don't get it. The mentality there is I want an application ASAP (sometimes day of).

You've been kicked (a good thing) - Trackback from DotNetKicks.com

#4 is where I'm at right now, but I'm trying to work around it. I have an existing project that was not built with testability in mind - this was before I began my recent best practices learning spree - but have been slowly getting under test in recent times.

I've got a lot of code that is difficult to test because it touches the database, or the filesystem, or HttpContext. It's a work in progress, although an intimidating one. I'm using Feathers' book as a guide to refactor code to a more testable state. Will probably need to start some DI soon.

I'm with you, Derik.

Writing code for testability has afforded tremendous improvements for me personally.

Pingback from  Dew Drop - Weekend Edition - November 15-16, 2008 | Alvin Ashcraft's Morning Dew

>>>My employer does not pay me to write quality code... I struggle with this on a DAILY basis and they just don't get it. The mentality there is I want an application ASAP

Unfortunately, this sums up Corporate America and is why the US is going to go downhill.

>>>Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint

are you absolutely sure about that?  I am willing to bet based on the code & run corporate world IT lives in today, that people definitely have.

I am 100% in agreement with Derik.  However again, the corporate arena and horrible management these days do not facilitate this type of culture or process in more IT shops I've come across myself.  Most of them with the exception of about 2 are piss poor and shit ass managers.

The reason why testing and writing testable code aren't popular among the developers is simply because <a href="itscommonsensestupid.blogspot.com/.../testable-code-who-cares.html">the managers or the clients don't care about testable code</a>

I agree with Jon.

I could take my time and write well tested quality code and give the higher ups a flawless program in 3 months. Or I can hack together some buggy spaghetti and deliver in a few weeks.

The suits will always choose option 2 even if I explain that will be costlier in the long run.

inb4 quit your job - not in this economy

I have to disagree with your 'lazy' reason since if those people that you are referring to were lazy then they would test their code.  I am lazy and I do test.

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #225

Well said Derik,

Also regression tests (writing a test that fails before fixing a bug) really save you sometimes when "attempting" to reintroduce an old bug :-)

There's at least one more reason: There are some things that can't be automatically tested. That's no excuse to write no tests at all, but it's true anyway, and it has little to do with "poor code".

Derik,

Its one thing to take the moral high ground and risk your financial well being when it comes to Guantanamo Bay or something like that.

Its another thing to risk your financial well-being (and that of your family) for TDD.

Agreed 100%!

TDD is hard! Especially when you are developing User interfaces.  Almost always it feels like its not worth spending that time while working in UI code.  Most of the examples out there talk about testing the business layers.

>>>Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint

LOL. Plenty of people have. People I know have.

Corporations generally don't care about you writing quality code, they just want to see nice things on a screen in the least possible time.

Whenever I've worked for anyone else, you can talk them round at first, but soon they are back to demanding to see pretty pictures quickly and you can no longer afford to write tests.

My advice: Find a good idea, quit and do it yourself. Properly. Good quality is a long-term win. The other corps will get short-term wins and then find themselves with an epic fail.

Management doesn't care about testing until there is a problem.  Then it's "What!  Why wasn't this bug caught during testing!"

A recent project (planned using waterfall), management calculated about a month worth of testing (developers had short iterations that included testing) over the project lifecycle.  Well, to 'streamline' the project and get it completed before the due date (management *loves* to get things done 'early') they removed the testing 'roadblock' saying "You can do that sort of thing later".  Now that the project is live, certain kinds of searching can bring the web site to a stop, lock up the database or worse (yea..think 'SQL Injection').  Like clockwork  .."How did these problems slip through testing!!?"

>>>David

You don't risk that but you certainly DO NOT PUT UP WITH IT.  What I mean is, if you have any respect for yourself as a developer you would not stay in a code & run shop and just "put up" with a pile of shit.  You should start looking for a job and get the hell out for your own sanity and just development to become a better coder.