Jak Charlton - Insane World : TDD, Rants

Ship it, or Ship Out

Jak Charlton — Fri, 25 Sep 2009 08:38:00 GMT

Joel, in his inimitable way, posted the flame bait of all flame bait posts yesterday, explaining the role of the Duct Tape Programmer.

To my surprise, the Twitterverse started to reverberate with commentary, but weirdly, almost all of it was very negative about the post, many claiming that Joel was just creating straw men and knocking them down, or was characterising developers who care about quality as being poor developers.

I was surprised, because I read the article totally the other way around - and had said so earlier in the day to someone on Twitter, saying I largely agreed with it. It seems that there were two ways of reading the article, and mine differed substantially to most people I follow on Twitter.

I was quite pleased to see Michael Neel post last night in a semi-defence of Joel's standpoint, and I thought the 140 char limit of Twitter wasn't enough for me to post my opinions.

Background

Joel has a bit of a record on this, he isn't best liked by a large proportion of the developer community who see their focus and remit as producing high quality, well tested and highly maintainable software. His original tirades in a podcast about his deep distrust of Test Driven Development and of Unit Testing in general brought uproar. And on that matter he was so far off the mark, it was understandable why he had riled so many people - he really just didn't understand or "get" TDD or testing in general.

But, what he had done, in conjunction with Jeff Atwood, was to deliver a website, stackoverflow.com, that was proving hugely successful, and was being used extensively by all those same developers who railed against his podcasts and blogs.

That website, as Joel and Jeff explained, was not done with TDD, was not well tested (via Unit Tests), was badly hacked together in places, and used "old" technologies like TSQL over "modern" solutions like ORMs

Whether Joel "got" TDD wasn't important, what he and Jeff had done was to ship a product, get it to market, and build upon that release to make stackoverflow the massive success it is today. It's so successful, that soon after stackoverflow was released, they used the same code and model to release other Q&A sites, and they continue to do so.

The Duct Tape Programmer

So with all of that in mind, it was sort of obviously flame bait for Joel to make a post that basically boiled down to "shipping it way more important than fancy patterns and great tools" - he certainly has a way of putting such a simple message that can antagonise the meekest of individuals (and some not so meek).

It was a terrible choice of label, but I guess "Pragmatic Programmer" had already been taken.

Time, Quality, Functionality

I read the article slight differently - I read it as an urge to maintain your highest priority as shipping the product your business wants you to ship.

There are three factors involved in a project (if you exclude Resourcing, which falls under Brooks Law):

Time
Quality
Functionality (or Scope)

If you try and maintain all three factors as fixed, your project is doomed to fail. Something will, unless you are really lucky, break. And then one of those factors will suffer, and it will be luck as to which it is. At best you can fix two of those factors, and then the third has to be allowed to slip when the unexpected happens (as it always does).

But, the important part here, is that which of those factors is fixed, and which is allowed to slip is NOT a developer decision - it is a business decision.

Much of the outrage about Joel's article stated that he isn't a developer - and they are correct - he is a business owner, and prior to that a project manager. His focus is therefore on shipping his product, and inevitably from that perspective, the instinct is to fix Time and Functionality (ship as soon as possible, with as much functionality as possible) and to let Quality suffer to achieve that objective.

This is a TOTALLY VALID business decision - it is just one that developers don't like, it offends their sense of code quality and high standards.

Why Do Developers Care So Much About Quality?

I'll start with the cynical view: development is only fun while you are trying new things, trying to perfect a tricky algorithm, or make some great new OSS component do some magic. By nature, the developers who care deeply about quality are also perfectionists, they like to make sure they have done a good job, and have written the best code they can.

Go on, admit it, if developers just did routine coding all day long, our jobs would be boring. We like new toys, new language features, we like to play.

And we know that better code will be easier to maintain - and developers HATE bug fixing duty, so we want to ensure we don't have to do much of it.

To a developer, the most important factor in any project is Quality, followed by Time (because we know our bosses will be mad if we miss our deadlines), but we are happy to slip Functionality because it matters little to us if a new feature isn't included in the release.

Fundamentally We Are Not Aligned

Developers and business owners are not aligned in their goals - we prioritise the three factors very differently, and for different reasons.

Only two things can happen here, your developers need to align with their business objectives, or the business needs to align with the developers - or they can both compromise.

Agile is all about the compromise, making both sides aware of the issues involved, and then coming to an agreement, but fundamentally - it is STILL A BUSINESS DECISION.

While it is the responsibility of a professional developer to explain all the problems they see with low quality code, and to make their boss aware of all the potential future issues this may cause, it is also their professional responsibility to go with the decision their boss makes.

They have one other option - resign and go somewhere that is more closely aligned with their values.

Ship It or Ship Out

Whatever your opinions of Joel and Jeff's understandings of TDD, Unit testing, maintainable code or just code in general (and I'm sure yours aren't too far from mine), you have to admit they delivered a product to market (many in fact), and have turned it into a huge success. They may have to pay for that speed to market later, but that was a business decision they were willing to take.

Never underestimate the value to a business of being fast to market - there is a risk the product will be so bugged it will backfire - but there is a chance they could steal the march on their competitors, and gain critical traction. Business is all about assessing risk, that is what a business owner has to do, and if they do it right their business flourishes.

If your boss wants a product shipped by a particular date, and that is their highest priority, you have a responsibility to ship it. If they won't sacrifice functionality to achieve that goal, then code quality will have to suffer - in that case do the best you can do with the restraints you are under. And if all that fails, quit, go somewhere that appreciates your values and dedication to your art - you do not have a right to hold your employer to ransom.

So, Ship It or Ship Out.

Testing Is Not Technically Hard, It Is Hard Because It Requires Clear Thought and Understanding

Jak Charlton — Wed, 01 Oct 2008 08:46:00 GMT

This whole "lets make TDD easier for the masses" thing is getting out of hand.

Unit tests are not technically hard, as Udi points out, what is a test? Anything with TestFixture on it?

It is not a technical challenge to write a unit test, any half trained monkey could do it. A few attributes, a couple of classes, a few new() statements, and a few Assert statements. We don't need magic mocking frameworks, we don't need any mocking frameworks for 90% of our tests, we don't need application of 12 GoF principles before we can write a test, honestly.

Testing and writing automated tests is hard because it requires a strong understanding of the user stories that sit behind your code and project, because it requires you to think as a user and not as a developer, and because it requires you to be able to think of multiple conflicting axioms, test cases and class interactions, and how to cover the weaknesses of each individual test with other complementary tests.

Bad tests have no value - none. The only "value" that matters is "business value", and a bad test will not reduce your development time, nor will it reduce your maintenance time ... in fact quite the reverse, bad automated tests will require significant maintenance themselves, will force your code to become rigid and resistant to refactoring to a better code base, and give people relying on your tests as a form of usage doumentation totally the wrong ideas, or worse still confuse the hell out of them.

A project with no automated tests is verifiable by observation and UAT. A project with bad automated tests can still be verified by UAT but will now be complex to refactor or fix when problems or bugs appear. A project with a few key *good* tests around *key* functionality will provide a good balance of verification and sanity checking, and still allow the project to be maintained later.

By all means start writing unit tests, but make them Spikes, and you will soon see how your Spikes project becomes fixed in time, with most of them not working after a few weeks of development - now imagine they were automated tests you were maintaining ... /shudder

I can teach someone every part of SOLID they need to be able to write a technically competent unit test inside a day, teaching them how to write tests that have value takes months or years, there is no substitute for experience - but gaining that experience on your employer's time is only valid when the business says it has value to them, and when they understand it will result in a significantly longer delivery schedule - otherwise pay some good testers to do what testers do very well.

Morning rant over, your normal service can now resume.

Is Alt.net Duplicitous?

Jak Charlton — Wed, 21 May 2008 09:54:00 GMT

Roy makes a number of accusations about the Alt.net community, particularly centred around their espoused ideals clashing with their comments and blogs. I respect Roy greatly, his blog was one of my first real sources for great TDD information, and he has consitently put out great blog posts and software. Largely his complaints come down to TypeMock (who he now works for) not getting an overly warm welcome by many people in the Alt.net world.

I don't for one second question Roy's sincerity, he really has shifted his view on how testing and mocking should work, for what he sees as all the right reasons, and now he seeks to convert others to the same cause.

I'm not what you might call a "paid up member" of the Alt.net movement, my blog address appears on altnetpedia.com, I frequent the Alt.net mailing list, but I have never attended one of the conferences, nor do I put the Alt.net logo on my site. I read a few dozen blogs, probably a third would be classed as Alt.net people, most would not be. I guess I have a foot in Alt.net but dance with the devil.

I am however one of the people that has commented a number of times on TypeMock and its suitability as a mocking framework (for my needs), and Roy's obvious frustration comes down largely to his perception that people are bashing TypeMock unfairly, or out of dogma, and not seeing his vision for a better way to write software that TypeMock can help with.

That is perhaps the case with some people. TypeMock has some fervent supporters, and there are some people that think TypeMock encourages bad practices and should be avoided - software for some reason is one of those things people become almost religious about. I suspect that most people, myself included, are somewhere in the middle.

TypeMock is to me largely irrelevant. It has some plus sides (debugger support, mocking legacy and framework classes easily), and it has some down sides (it makes it "ok" to couple your code, or to use concretions over abstractions)

But mostly I just cannot see the point of TypeMock as it exists. It is, if you exclude the plus and minus points I just listed for a moment, basically the same as Moq or Rhino Mocks. It does more or less the same things, in more or less the same way, except both of those options are free, and TypeMock is one of the most costly development tools you could own.

I'm certainly not against commercial software, I own personal licences for all the software I use on a daily basis, but those products I choose to purchase are the best in their class, or solve a particular problem I face. I also weigh up the cost to value benefit.

The best comparison would be against unit testing frameworks, which are all to the best of my knowledge open source. There are commercial tools which make them easier to use, but there is no need for a commercial unit testing framework, as they are at least 95% feature complete.

The same could be said of mocking frameworks, Rhino and Moq are at least 95% feature complete, and pretty much (in all day to day ways) the same as TypeMock. There is for me, no one "killer feature" that TypeMock has that justifies it's price or putting a dependency upon it within a code base.

So is Alt.Net guilty of the duplicitous charge that Roy has made?

Expecting all people who frequent the Alt.net world to be constantly flicking between technology and tool choices is not going to hold water. A typical software project may last weeks, months and possibly years. You cannot switch and change that frequently, you have to make choices and go with them. That doesn't stop Alt.Net people wanting to become aware of more options, but it also means that new options have to get compared to existing options, and even when a better option comes along, it is frequently not going to be used because of historical reasons. People still have their favourites, they still have their personal biases, and they still consider themselves as capable individuals who can evaluate these things.

I honestly don't think TypeMock in it's current form is that revolutionary that we should be sitting up and rushing to use it. The few new things it brings to the mocking party are different, not much better or that much worse. So picking the right tool for the job, means most of the time I prefer to write a wrapper or abstraction (a few wasted minutes) as opposed to changing an entire mocking strategy, all for the sake of a shinier toy. Others make take another approach. When I encounter a real world scenario where I need the power that TypeMock has, I'll re-evaluate.

Sometimes, the newer tool isn't the right tool for the job.