Yes, but Joel has told me I’m not pretty enough to be a duct tape programmer. He implies you need special talent to be able to “ship code”. That’s ridiculous.

Joel’s blog post is simply not logical. It’s duct tape blogging. But the sprit, yeah OK, I guess you were feeling benevolent today.

And I agree with almost everything you’ve said. The truth is still out there, but but it’s somewhere closer to Joel’s worldview. Sure programmers should be very smart, but the reality is most are mediocre. And sure there are “architecture astronauts” that understand how and why to use specific technologies, but in my experience most people only think they know these things, creating maintenance nightmares. Tell me I’m wrong – I dare you.

As for testing, you’re both right. TDD is the right way to do it, and it is also like flossing – everyone thinks it’s a great idea, but most people never get around to it.

I get a feeling Uncle Bob is trying to be politically correct this time regarding Joel’s views.

“Being politically correct is believing you can pick up a turd by the clean end.”

Both Joel and UncleBob left off a very important part of software life cycle – what happens AFTER “git-r-done” in Joel’s case shipping.

Guess who is going to have a maintenance/improvement nightmare on their hands? Not the TDD crowd for sure.

Here are a couple of thought provoking nuggets on twitter by people who see through this:

“never take software advice from a bug tracking system salesman”

“The anti-TDD people ought to realize that many of the pro-TDD people did many years of development before coming to TDD. It’s not like we just haven’t experienced the joys of cowboy coding and once we do we’ll drop unit-testing as unnecessary.”

“duct tape programmers – sacrificing tomorrow’s productivity, today!”

Regarding flossing.

If you aren’t flossing EVERY SINGLE DAY, you are a blithering idiot. Do you have any idea how valuable your teeth are? Do you want to have them when you are 56? I don’t want to hear the excuses. I don’t want you to even THINK about not flossing. FLOSS damn you! FLOSS!

“I get a feeling Uncle Bob is trying to be politically correct this time regarding Joel’s views.”

As do I.

Flossing every day is overkill, you won’t lose your teeth if you only floss every other day.

Same can be said about unit tests: you can produce quality software without any tests. Companies do it every day. Programmers do it every day.

That’s Joel’s point.

Bob. I was going to respond with a comment on Joel’s blog, but I think that I’ll just link to your blog. This is almost exactly what I wanted to express, but I would not have done so as well as you have.

If you skip flossing, at least 2 bad things will happen:

1. Your gums will bleed because they’re not used to the activity. 2. You will stop flossing all together. You no longer have a HABIT.

Same for TDD. Do it all the time. Don’t code if you don’t write unit tests. My spikes are through automated tests first, not console apps.

I’m “Clean Code” guy too. Clean code make me feel good.

Though I think the metaphor has been stretched as far as it can go, here’s my thought on duct tape programming:

Duct tape is a patch, not structure. You can’t build a house out of duct tape, but you can patch a hole until you have time to do the right thing.

Joel would have an argument if he didn’t take years to ship new versions of FogBugz.

I strongly agree with Uncle Bob:

“The programmer who spends weeks building the perfect structure does just as much harm to the project as the programmer who hacks a bunch of crap together. Neither have struck the balance that’s required.”

Everyday I see both kind of creatures around me.

I think a lot of this issues are motivated by a short term vision. The “Ship it now” requeriment from the managers is a path for future problems if it is not properly handled. Inmature programmers never think about maintenance or operational aspects for the software running in a production environment. Getting the things done quickly perhaps is a victory for today but a nightmare for tomorrow.

The most inspiring argument from Joel’s post is (quoting Zawinski):

“A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.”

I enjoy reading both posts. I think reading Joel’s and then this one gives you a lot of inspiring thoughts to be a better developer.

Please give the TDD crap a rest already.

For those who don’t believe unit tests are necessary: try coming on to a project that has been going for two years that has NO unit tests and lots of complicated, messy logic. Then try defect fixing on said project, or even adding new features. It is a nightmare!

The developers are scared to touch code in case it breaks existing code. And they are right, because they have no way of knowing if they have broken anything.

Unit testing is essential.

Agreed, except for threads. Almost nobody is smart enough to use threads without getting into trouble. They are part of the problem, not part of the solution. We need to figure out a way to sugar-coat and de-mystify functional-programming techniques so we can have concurrency without insanity.

Surprising post by Joel, since I’ve actually find good content in there, for example his post about encoding has been useful.

TDD is a design tool that allows me to write better code faster. There is a line between that and under/overspecification. Clearly Joel doesn’t see it that way, unfortunately.

It is very selfish not to unit test. It creates feedback loops of failure which slow the project in unpredictable and unaccountable ways. This upsets everyone from QA testers to deployment to BA to customers. TDD is a good way to have unit tests done in a way that everyone can share the value.

Why doesn’t anyone stress the fact that even with TDD you can cut time out of initial development phases and ship earlier with it? I am already noticing that with TDD I can go days without launching a debugger!

How do you check your work without automated tests? Manually! So in effect you create manual tests in your head and then aren’t even polite enough to share them with the next developer (let alone your future self) and somehow this makes you a “pretty” developer?

There are times when it makes sense from a business perspective to cut corners and ship early. But at the end of the day we do have to realize that this is a debt we have to pay back. Otherwise, we are being dishonest with our customers about the amount of work we can get done in a given amount of time and will set ourselves up for failed expectations in the future or pissed off clients.

I felt compelled to comment on Joel’s post as well. I’m glad you blogged a reply, as it gives me a place to put my thoughts!

I disagree that our only job is to ship a product. Maybe that makes sense if you’re competing on price alone, but the companies that I want to work for use price AND quality to differentiate themselves from the competition. That means the job is to ship something on time, that works, AND is constructed with some amount of care and precision so that it serves the customer’s future needs as well as the immediate ones. Too much duct tape, and an attitude of “I don’t need no stinkin’ fancy pants ”, are a bad thing.

Like you said, sometimes the clean, thoughtful application of duct tape IS the right move. Sometimes, its not. And anyone that says that unit tests are disposable has yet to discover that test-first is as much about WRITING THE RIGHT CODE as is is abut ENSURING THE CODE WORKS RIGHT.

Oh well, back to work. Where’d I put my liquid nails….

“Same can be said about unit tests: you can produce quality software without any tests.”

I could not disagree more. I would amend this to, “you can produce software without any tests.” But quality software, I think not, and certainly not in the software world of today. I think the term “quality” is to some degree a relative term, and also highly subjective. “Quality” might mean something slightly different to every programmer, given technologies being employed and available, as well as the actual time period which we’re referencing. Is quality readability? Conciseness? Performance? Maintainability? Some of these might be at odds with each other. These will undoubtedly be prioritized differently depending on the language and the resources available, which also might relate to the time period (i.e. ruby, given it’s memory footprint, theoretically would not have been a viable solution 15 years ago, given the cost and capacity of system memory). What might have been considered “quality” code ten years ago was held to a different standard then than it would be now, given the differences in tools and landscape, etc.

That said, the landscape is changing, and rapidly. We’re moving/have moved into an era where software without tests is simply not “quality”, though it certainly might be software.

If you aren’t flossing EVERY SINGLE DAY, you are a blithering idiot. Do you have any idea how valuable your teeth are? Do you want to have them when you are 56? I don’t want to hear the excuses. I don’t want you to even THINK about not flossing. FLOSS damn you! FLOSS! ”

@Uncle Bob you have obviously not traveled enough, Lots of people in the world do not floss and they have perfectly fine teeth at old age.

I love the fact that some guy took “You Are Clueless” as his name!

Without intending to turn this fully into a discussion of TDD, I love those guys who say, “Who tests the tests!?” As if using them over and over, verifying that what you’ve written does what you were intending, and that continuing to write them to guide how you’re building the rest of the system isn’t beneficial and is not a test of the tests itself.

Good point, Av. Even as a consultant, I feel that leaving a steaming pile of code for my clients to pick up after is embarrassing, and is what I try to avoid at all costs.

TDD is very useful but practically and emotionally I cannot write test code all times. Hence I like Joel’s view more.

http://en.wikipedia.org/wiki/Anecdotal_evidence

The problem is that with an industry as large as programming is, it is easy to find a shop or many shops that support your personal views.

Is Joel or Bob correct? I don’t know.

But in my experience, small project teams can easily tolerate some of these “get it done at all cost” attitudes. Larger teams tend to suffer. Getting it done tends to make you management’s poster child of shipping software and public enemy #1 for the poor fools who have to support your work.

Of course, it is easy to counter that over design and endless polish causes its own sort of deadly problems. But you have to ask yourself are you looking at the extreme cases in both arguments to support your own position. If you are, then your argument is weak.

Often you do find yourself having to do dirty things in order to ship code and make enough money to survive. Personally, I sure hope that your are doing what you need to do make sure that you can still ship software after that first version.

“I want you to ship, but I don’t want you to ship shit.”

This reminds me of something the 37signals folks said in their book “Getting Real”.

When you’re just starting out, you won’t have enough time, resources, or understanding of the problem to implement the whole solution.

That’s ok.

But make sure you’re building “half a product”, not a “half-assed product”.

In their case, they were talking about straight “feature counts”: ship three great, well-done features rather than six decent ones. But the same idea applies to development techniques.

I tweeted this with the caption “Uncle Bob is my hero”.

I like Tim’s comment.

Automated testing is wonderful. I really like unit testing as a design and documentation tool. I really like acceptance tests as a regression and business communication tool. I’m really thankful that there are those individuals who are more passionate than me about testing pushing the tools forward (Selenium, Cucumber, TestSwarm, etc). Joel was really really wrong to dismiss “unit tests”.

That said, testing is far from a silver bullet. The problem is that tests are overhead, the marginal cost is low, but not free. You have to pick what to test, and some things are very hard to test (people are steadily chipping away at that, but let’s be honest, some things will always be hard to test). No test offers as complete coverage as an actual human performing an acceptance test. Common programming techniques lead to an explosive number of edge cases that are all but impossible to enumerate and therefore test.

That brings me to my agreement with Tim Bray. Functional programming is the most powerful tool for ensuring program correctness that we have in our bag. It’s really about leveraging thousands of years of mathematical practice in proving symbolic statements and applying that to software. If we can remove side effects from our code, our ability to reason about code is increased by several orders of magnitude. It certainly is inconvenient at times, but forced purity can give you guarantees that no amount of tests can ever provide. Of course it doesn’t preclude the need for tests to ensure algorithmic correctness, but just imagine the power of a unit test if the function is guaranteed pure.

My approach is a little bit of what Joel said and what you said. I prefer to use the simplest approach possible, but code it up using TDD. Ship fast, but ship the code clean.

You can produce quality code without writing unit tests…

But how do you know it’s quality code?

Years ago I wrote this editorial for a small magazine named Eiffel Outlook>

http://rbielak.inquitoris.com/writing/computers/eo_199509.html

@Tim Lesher – I think you brought up an excellent point. We all have to balance theory and the real world. Isn’t that one of the tenets of engineering anyway? But the problem surges when that balance is done by cutting corners instead of cutting features.

You say: make sure you’re building “half a product”, not a “half-assed product”.[/quote]

And and that is the difference, in my view, between good programmers and bad ones. Bad ones drop commenting, testing, frequent check-ins, and so on. Good ones maintain their development discipline but trim features, avoid over-engineering, etc.

The world we live in is somewhere between Joel and Bob. And it is a constant struggle between opposing forces. The maverick style of Joel brings a note of pragmatism to the table. The more academic (for lack of better word) style of Uncle Bob reminds me that there are ideals to pursue.

One day without flossing won’t make you lose your teeth. All of us will have days in which we forget or are just too busy or tired to floss. But every day we don’t floss make it easier to forget it again the next day. We must avoid losing the habit of flossing by constantly being aware that our teeth need cleaning.

Nothing highlights and makes this equation more important that running your own software company. The need for quality and the need to ship are both very, very important. Sometimes one sacrifices a little of one for the sake of the other. It is a sliding scale – perhaps like a see-saw. If you get over to one side too far you are lost. One can balance a segment somewhere near the middle – but go too far in one direction, and you are toast.

We’ve still not found a perfect ground. One of my ventures is on the “clean/no duct tape side – not shipped yet – but it is an industry where you don’t/can’t ever recover from a bad quality first release. The others are on the duct tape side and it is probably hard to determine how many lost sales were a result of all the duct tape-iness.

Shipping is good. that is how you get revenue.

Shitty code is bad. That is how you lose customers and turn users off, not to mention ensuring sky-high development costs in the future and maintenance issues so big you might not get to versions 2, 3 and 4

@Tim, @David: I agree 100%. I personally try to test first as much as I can and also get to the point that I can’t test everything from time to time.

Especially when you’re working in teams where testing habit and techniques differ, you simply have to accept that a high (or even full) test coverage is neither pragmatic nor efficient. You end up by trying to just cover the functional stuff, since this is the main focus why you’re writing software for.

Like David said before, I don’t think that this is per se a bad thing. We always need to find a balance – from project to project and context to context.

Yes, the world is somewhere between Joel and Bob.

However, my feeling is that it’s better to aim Bob’s world instead of Joel’s – from both economic and engineering perspectives.

I respect Zawinski, but is he really a good example to follow here? Sure, Netscape jumped out on the front of the Web craze, but how did that work out? I don’t think it’s any accident that the majority of the browser had to be rewritten from the ground up when it shifted to Mozilla. Jamie complains the email team never completed their component to display messages, but why did they have to write one at all? They should have been able to reuse the browser display code, but I’m guessing their “duct tape” solution was incapable. If they had unit tests, it would have been easy to add functionality that the email client could use without breaking the browser.

In the end, I guess duct tape solutions are fine if you’re just looking to ship product in whatever state, make a bundle, cash out, and buy a nightclub, but woe to the developer who has to come in behind you and actually maintain your “brilliance”. Maybe these guys missed their calling working in the finance industry.

Let’s just not hand excuses to Duct Tape programmers. Those few who know when is the appropriate time to use duct tape simply do it, no matter what the “rules” are, and are perfectly capable of justifying their choice (for starters, with working, shippable software).

The rest should just be told to never ever do it. If they can’t argue the case for using duct tape solutions, they’re either wrong or not capable enough of to trust them with it.

(One other thing such mediocre programmers should be told to never do is take Joel seriously. But luckily most of them can’t even be bothered to read that stuff.)

After reading Joel’s blog, I wrote this in my drafts…

The best comment is the comment that you didn’t have to write. The best code is the code that you didn’t have to write. The best design pattern is the design pattern that you didn’t have to use. The best inheritance hierarchy is the inheritance hierarchy that you didn’t have to use.

Yes, sometimes a programmer that uses inheritance and design patterns too much is worse than one who doesn’t use them at all (especially when there’s software to ship). But the best programmers are the ones who understand that the secret to design patterns, inheritance hierarchies, comments, and just plain old code—the secret is to know when not to use them.

Yes, I stole the first one from Clean Code. I would’ve give Uncle Bob due reference, of course, but now he’s put it even better than I ever could.

So I’ll just link here!

I consider TDD as essential for several years. However, I dicovered one thing, that is (seemingly) not particularly popular. TDD and unit testing is not an easy skill. It is important, because their ROI depends directly on their quality. I have already seen some extremely valuable tests, many ok tests and way too many bad tests, that actually got in the way of development, providing less value, than costs of maintaining them.

Therefore, I’d like to stress, that it is crucial to use TDD the right way in order to get its benefits. No wonder, that many people fail to see value in unit testing, when they are most often confronted with poor-quality test practices. Uncle Bob, keep on spreading your knowledge! The more people start to get early ROI from their tests, the less people will remain sceptical about them. Seeing is believing. Eventually Joel is going to see it, too… or he’s not, let him alone and keep getting benefits from testing techniques :)

Nownow, Visual Studio ain’t such a bad thing…as long as resharper is installed.

As for TDD, one thing people seem to forget: I have noticed that it is possible to program when you are drunk, provided you write, one-by-one

• do: a test expressing what you are trying to achieve and
• making it pass;
• goto do;

The code may not look as usual but it will be functional. Now anything that makes programming easier is a good thing, innit?

Bob is right and Joel is wrong about unit testing. Really, "unit testing" is just testing, but done in a way that is standardized so you can easily re-run your tests as part of your build cycle, and see which ones are failing. Unit testing your code doesnt take any more time than simply testing your code any other way, and anyone that ships code without testing it is a moron. In my company unit testing is a requirement, and any programmer working for us that doesnt want to unit test better polish up their resume, because theyll be in the job market soon (in reality, we wouldnt hire such a programmer in the first place). This is not because weve bought into some ideology, its because weve tried it both ways and unit testing saved time, reduced stress, made debugging easier, and made the shipped product better. I should point out that we ship a product which, if it doesnt work properly, can cost our customers thousands of dollars a day.

Sorry to be blunt, but Joel Sposlki has a much better track record for shipping and selling software than Bob Martin does, so Joel’s points will resonate with programmers who have to ship software to make a living, a constraint that Bob doesn’t have.

Harold, Would you trust someone who ships bug tracking software to be worried about whether you ship bug free code?

Kevin: again, just because you don’t have tests or automated tests doesn’t mean that your product is not good.

I know nothing about FogBugz (never used it) but it seems to be doing quite well and to be receiving good feedback overall, so I would say that it’s quality software.

The fact that the founder of that company thinks so little of TDD and unit tests is telling us something important: yes, you can ship quality software with mediocre testing.

Harold : you missed my point, his entire business is based on people making buggy software and needing bug tracking software. Why would you listen to him if you were seeking any advice at all in regards to code quality. Even if he did think highly of TDD, why would he say so? Also, ask FogBugz users why it takes years for new versions to come out? He is supposed to have the best of the best up there and they crank out software slower than most of us “mediocre” programmer driven companies.

Harold : and also, good feedback does not necessarily mean quality software any more than no unit tests means crap software. But hey, you know FogBugz and his company so well, you must know better than me right? wait a min…

Anti TDD folks seem to consistently overlook that TDD isn’t slower. It simply isn’t, the folks who complain to me about have never tried it. Also as previously mentioned we write the tests in our heads anyway.

Anybody ever thought about the nice half hour of unit testing done in the visual debugging environment that then gets discarded once the bug is fixed?

Where I work we use test cases as documentation for future maintainers of the code. It also helps the original authors recall what they were thinking about back then.

I also agree with some of the other posters, it does take some practice to realize what to test and what not to test.

Why would you trust someone like Uncle Bob who doesn’t ship and sell his own software but rather sells consulting services and in fact makes more money when deadlines slip and consulting projects run longer? In any debate about balancing speed versus quality, an actual software company has far more credibility than a consulting/training company.

I’d trust Uncle Bob because he’s still actually writing and shipping code. Go check his github account. Joel’s opinions on software are outdated and irrelevant. He personally hasn’t coded in years, and his attitudes towards modern coding practices show it. It’s like asking a buggy whip factory owner about his opinion on how to properly manufacture Priuses.

No Kevin, Bad Kevin – Did I say anything in regards to Uncle Bob? You guys are fun with your pretending to argue a point I never made. I simply said “Would you trust someone who ships bug tracking software to be worried about whether you ship bug free code”. You guys can dance around that question all you want and keep thinking highly of Joel and attribute an entire company’s success in sales to him. I know every line of code I write is all because my boss is smart.

Kevin: oh ok, I see your point. Fair enough.

Then again, Bob is working for a consulting firm, so selling methodologies (and ideally, methodologies that change every year) is also a good business plan where you can just come in, write some code and never have to maintain it, so we should take what he says with a grain of salt as well (and we do).

I tend to hold in higher regard people who actually do stuff than people who talk about the best way to do stuff.

Both Joel and Bob fall in the latter category somewhat but Joel has way more do-stuff cred.

Why do people feel they need warship Bob or Joel?

Can’t you appreciate they are both great programmers who both ship products and have good track records.

Don’t you see that thousands of programmers have learned how to better themselves through both of these guys blogs, teachings and conferences.

They are both great programmers that can use whatever methodology that suits their needs.

I prefer unit testing and know the benefits of it. But if there is some quick patch or fix needed that when you have enough experience you can ship that patch without unit testing you would be mad not to. You can always clean it up later.

So I think people should learn the pros and cons of each method and use what their experience tells them is appropriate at the time.

@Fo Sho! What “do-stuff cred” are you referring to that Joel has done? He pontificates about software, but by his own admission, he hasn’t written actual software in quite some time.

Bob still writes codes. And lots of it. I hold his experience in higher regard than Joel’s for that simple reason.

There’s a typo on the third paragraph. I assume you meant “spirit” instead of “spririt.”

Wow, i didn’t know people still read Joel and Jeff’s blogs.

TDD does slow you down and I hope one day the community of amateur software verification testers realise this. Study some type theory and what it means to prove a logical theorem (see C-H Isomorphism), then tell me your clumsy TDD fashion is saving you time.

@corey.furman & Uncle Bob

We floss our teeth to clean them, so if it is a Dentistic metaphor we are after, rather than TDD = flossing, we should go for Refactoring = flossing, since refactoring is the TDD phase in which we clean our code.

But, as Refactoring Tools: Fitness for Purpose says, not all refactoring is flossing:

We call one tactic “floss refactoring”; this is characterized by frequent refactoring, intermingled with other kinds of program changes. In contrast, we call the other tactic “root canal refactoring”. This is characterized by infrequent, protracted periods of refactoring, during which programmers perform few if any other kinds of program changes. You perform floss refactoring to maintain healthy code, and you perform root canal refactoring to correct unhealthy code.

If we adjust our metaphor to take this classification into account, we soon extract from it the following admonition:

If you don’t do Floss Refactoring, you end up doing Root Canal Refactoring.

I found it curious that Joel chose to associate an ugly, unmaintainable system including multiple inheritance with design patterns.

I hope some day he actually makes the effort to try test driven development. Then he can drive a truck through his own arguments.

Trying to recall why I used to follow Joel’s blog posts.

(Loving the tweet: “never take software advice from a bug tracking system salesman”)

I think that any programmer that’s not smart enough to use tools like that is probably not smart enough to be a programmer period.

Most IT programmers I’ve met in the last decade are not smart enough, nor should they be programmers. But they are filling the demand for someone, anyone, to man the computers.

was horrified by Joel’s post for the most part. As usual, Bob takes what is useful and tosses what isn’t.

As far as the stupid/mediocre programmers, unless someone shows them how to be better, they will always be stupid/mediocre. It’s up to any smart programmer who cares about the profession as a whole, to help them along and make them smart programmers too. Then, we all win.

My $0.02 ~Lee

I am in the middle between Bob’s and Joel’s viewpoints. I think unit tests for every class is overkill. Likewise having interface for every class and mocking is in general overkill IMO.

I use JUnit (etc.) to write automatic tests, but they more functional tests. For example for a simple interpreter that I wrote I have tests for the Lexer, Parser and Interpreter but I don’t bother with mocking the Lexer or Parser or testing the Token, ASTNode and other classes like that. So the tests are covering that the lexer generates the correct tokens, and the parser tests make sure it is creating the correct AST.

From my experience, TDD slows down the initial release, but it will increase the speed of maintenance and adding additional functionality :) So in the long run, it’s better

Not to put words in joels mouth, but I think he is pointing to a problem a lot of developers have, me included; that we can’t put our selves in the users perspective. To the user it doesn’t matter what happens on the inside, as long as the outside works.

“When the user presses the button, what is supposed to happen, happens; withing a reasonable time frame.” This is the full extent of what the user cares about in most cases.

Everything else, is just for ourselves :)

““never take software advice from a bug tracking system salesman”

yes, but also,

““never take software advice from a methodology consultant” ;-)

I’m shocked no one pointed this out but when weighing pros and cons I usually consider the penalty and probability of failure when cutting corners. Has anyone EVER tracked you down after you wrote sh*tty code and called you out? Has crappy code ever kept you up at night (if so I think you should get a gf or something). Its not like anyone is keeping a FICO score for developers so provided you’ve had a few years of full cycle development experience under your belt, no one is really going to care. On a side note, I am responsible for refactoring and fixing my office mate’s code. He is very good at pumping out crap code to meet a deadline and I am getting better at fixing his crap faster then he can write it. The clean coders need the pretty boys to look good and your boss needs the pretty boy to look good. Eat fresh!

Once the assertion that every programmer is not equally skilled is made and accepted then adding the argument that TDD is desirable is delusional.

What makes anyone think that a programmer who writes mediocre code can write accurate and comprehensive tests? Is there some part of the brain that will kick in to accurately test a thing the programmer cannot comprehend adequately in the first place?

- krasicki

I agree that TDD is important. Having at least some tests will ensure minimum acceptable quality.

So, even as we make some adjustments to ship early, we know that what we are shipping is at least of a certain quality which will not break down once the software starts getting used.

— Regards Parag

From my experience, TDD slows down the initial release, but it will increase the speed of maintenance and adding additional functionality :) So in the long run, it’s better

Not to put words in joels mouth, but I think he is pointing to a problem a lot of developers have, me included; that we can’t put our selves in the users perspective. To the user it doesn’t matter what happens on the inside, as long as the outside works.

“When the user presses the button, what is supposed to happen, happens; withing a reasonable time frame.” This is the full extent of what the user cares about in most cases.

Everything else, is just for ourselves :)

I suppose it is redundant to point out the irony that Netscape no longer exists. If you read the Wikipedia page about Netscape, you can see the history of buggy releases that drove users away from the product. Microsoft’s involvement was no longer an issue when AOL finally disbanded Netscape.

Even later versions that AOL made were not based on the original code from Mr. Duct Tape. The open source codebase was abandoned because it was so bad.

He got the code out quickly and doomed the product to failure at the same time. That is the only lesson to learn from this.

Yes, there is a difference between Just Ship and Clean Ship. Just Ship is, as per Joel’s terminology is Mr. duct tape, which I consider mixture of technical debt and mess (depending upon programmers goodness). Well, the difference can become more clear if you ask – how long you would like to see your software running? If its just for version one Duct tape is acceptable, but if you want your software a-horse-of-long-race Mr. clean ship always wins.

I would like to echo famous quote on unix little bit differently: Cool-ness (like templates, COM, TDD, patterns and practises, refactoring, etc) is simple. And it requires smart brain to understand cool-ness.

Mr. Just ship would always refrain from changes (or the acceptance will result into mess over mess, a patch for patch scenario) while Mr. Clean ship will always accept the change (stolen directly from Agile manifesto shamelessly).

At the end I would appreciate Joel for his ship-biased spirit and thankful to uncle bob to bring that spirit to clean level.

“In short, it’s bad to use too much duct tape. But I’d be suspicious if I didn’t see some duct tape!”

Totally agree with that. I worry when folk put layer and layer of abstraction in when a simple bit of understandable, and maintainable “duct tape” would do. “Duct Tape” was invented for a damn good reason. The number of coders who refuse point blank to use a global variable, or static is amazing.

“I found myself annoyed at Joel’s notion that most programmers aren’t smart enough to use templates…”

I would rephrase that… I would say most aren’t smart enough to use them “properly”. And I would add that there are heaps of stupid coders – I’ve worked with plenty. And that’s not stupid as in eating coal, but stupid as in silly designs when, with a bit of thought… they would have thrown it all away. Stupid as in no one too many, but several layers too much abstraction. I see this a lot. Simple is not only good, but far more maintainable – and I don’t put this down to experience.

The sad fact is that most coders are simply not very good. MOST coders are in fact bad. But these days, you can be a bad programmer and still churn stuff out. Machines are powerful, and you can get away with a LOT of bad code but the product still looks more or less as intended, and while it may run a fifth the speed to should, machines are fast. Hell… look at windows!

There are only a small percentage of truly great programmers, a slightly larger percentage of really good one, a large percentage of “normal” ones, and a huge percentage of crap ones. But in today’s market of simply needing bodies to type, we still need crap coders to make up numbers and get code typed in! It’s annoying… but true.

I’ll say I agree with the “spirit” of this response, but I really don’t think it goes far enough to address Joel’s contempt for those who try to pursue craftsmanship in what gets shipped.

Yeah, we might as well just go back up into the trees. Who needs all this “polish” like cars and shoes and stuff, who needs to live “comfortably”?? At the end of the day all that matters is having some food, somewhere to sleep, and someone to sleep with.

I disagree with you. Maybe this kind of approach works for employees … but when you are an entrepreneur and need to get the think done real fast not because your boss is asking but because if dont do that you are dead … the Joel approach is much more realistic.

At this scenario, the idea “Be smart. Be clean. Be simple. Ship! And keep a small roll of duct tape at the ready, and don’t be afraid to use it.” is just impossible. You have to choose and you have to choose really fast.

I think that duct tape programming is good thing. For the start. All of us were duct tape programmers anyway. And then, after couple of years doing it like that, when you have things done behind your back, only then you can improve your skills with clean code practices, simply because you already have experience, and you can recognize mistakes and benefits of a good and clean code.

Cheers ;)

oh, yeah, unclebob, instead of spinning when I hit button submit for my comment, it says: spinner :D ;)

Good to see someone else making a bit of sense, though I’m a bit more miffed myself at the whole denigration of testing – maybe we need to introduce to the Computer Science courses the same kind of Famous Failures 101 course that Engineers get…

I love the Joel blog and I generally agree with his development thoughts (I’m an old fashioned C/C++ developer at heart, and so are all my products: http://www.workingprogram.com ), but my faith was somewhat shattered by FogBugz, which I don’t think beats Bugzilla when it come down to usability.

@Philip Schwarz – You misunderstood me to take a position, to which I only eluded to. I really do think TDD is important. I just also think that less people do it than claim to.

I’ve stewed over these two articles. I think to compare the positions of Joel and Bob is to compare apples and oranges, in the sense that what Joel seems to really be getting at – at least mostly – is the people at the extreme of perfection crafting vs. the people who manage to get something sellable, whereas UB is focused more on what all we should be striving for. I think there’s room to agree with both.

At the end of the day, your boss wants both, but he much prefers the sellable product.

Programming without TDD is like building a car with bandaged eyes! You feel the single parts (classes, units, methods) but you can’t see that some of them have defects.

Many steps later the result doesn’t look like a car, it looks like crab.

In the real world it’s very easy to identify defect parts by simply looking at it. In the world of software you have to test each part.

As most people have pointed out the most important thing for the client is the end product.

They don’t care if you take them by bus, limo, or on a bike as long as they get to their destination and that sometimes forces a lot of people to become duct tape programmers.

Also there are different types of software some have to be released in a few months (or even weeks), while others (as you pointed out) have years to be released so you can’t really compare both.

I find very interesting what Apple has done with iPhone. The first release looked gorgeous, but it was missing very basic features, so their compromise was ‘cut the features, but keep quality very high’. That turned out to be a good choice because people wanted a gorgeous object more than they wanted a complete tool. On the other hand I am happy with the fact that I put my not-so-gorgeous, cheap Nokia on the table near my MacBook and I can use it as a bluetooth high speed modem, so I guess there is no universal answer. Joel values robustness and speed of development as indicators of quality while Bob values maintainable, clean code as an investment for the future and they are indeed both right. What is missing in the equation, though, is the end user. How will the average end user evaluate the quality of your product? Based on beauty? Ease of use? Robustness? Completeness? Flexibility? How important is it that you ship right now? Steve Jobs had clear answers to these questions and when you make tough decisions you should have them too.

Sorry…..I’m not buying it. You’re thinking you can have it both ways utterly. Don’t in one sentence say “I’m the ‘Clean Code’ guy”, and then say, “I’d be suspicious if I didn’t see some duct tape”. Enngh. Sorry, it doesn’t fly both ways. If you have to strike a balance like that, then both sides must concede their radical views on the matter.

Either you fly by the seat of your pants, or you’re strapped into your seat all comfy, cozy, and confined.

All the TDD in the world can’t save bad design, and all the duct tape can’t keep shoddy workmanship together.

Real artists ship ?! Bah ! You think artists ship ? Artists don’t ship, they simply stop at a point where they think “There’s nothing more I can do for this one”, and move on. You actually think Van Gogh pined away, questioning why didn’t find a place for just one more perfect star ? Actually, he was a little fruity, so perhaps he did. But the point is still that artists don’t ship, they simply STOP, and move on.

And that’s perhaps the problem. In may ways you can’t “just move on” like an artist, or slave over code like “gee, did I miss some edge case unit test ?” ( and I’m not advocating simply glossing over that latter on, mind you ). But Geeze Louise, this is no way to make products. TDD is not the be-all-end-all, and neither is Duct Taping. They’re tools and skills for the toolbox. Period. So, “fit and finish” cannot be the end game, and neither can “it works now”.

Two remarks from comments I like a lot:

“At the end of the day, your boss wants both, but he much prefers the sellable product.” (corey.furman@gmail.com)

“TDD is not the be-all-end-all, and neither is Duct Taping” (Marcelo L)

It is the quality and time, that matters. Properly done TDD helps to achieve this. However, it does require skills to go faster with TDD, and even then: “Sometimes we abandon a complex test case because we need to finish the task, and visual inspection or manual testing is sufficient” (your own words, Uncle Bob).

That leads me to a question: forgetting about TDD for a while, what other choices do we have to ship quality software fast? There are IMO interresting directions you could explore, one of them being functional paradigm and, in general, programming at a higher level.

Desing Patterns being workarounds for C++/Java limitations, many unit tests seem to be necessary only because of low-level and imperative-style of coding. For example, take an algorithm, that does an inner join of two tables in Java. That task pretty much begs for a unit test. Compare it with the equivalent SQL command: things got simple and clear, there is nothing to test now. The more you use functional style, the less tests you need. Parts of your code start to be too simple to test.

I don’t think the issue is that the average programmer is not smart, more that as soon as you start using any complex technique, it becomes harder to pick up and understand what’s going on with the code, regardless of how smart you are.

Understanding the concepts of dependency injection or mix-ins is easy, writing code to take advantage of them is easy – understanding someone else’s code that makes heavy use of them . . . is far harder.

I guess this is because in the ‘simple’ case, you simply need to read code to see what is going on – everything is explicit – in the ‘complex’ case, you need to build a mental – or paper – model of the design.

“What makes anyone think that a programmer who writes mediocre code can write accurate and comprehensive tests? Is there some part of the brain that will kick in to accurately test a thing the programmer cannot comprehend adequately in the first place?”

Actually, YES! My experience (25+ years developing software in all types of environments/languages) has been that TDD changes the way a programmer thinks while they are coding. Anybody who does it for any length of time comes out thinking differently. It’s like playing an instrument. Not everybody who picks one up is going to end up in Carnegie Hall. But music is proven to have stimulative effects on the brain and behavior far beyond the ability to play an instrument. The same is true for TDD, IMO.

As for the Duct Tape Programmer I have three words for everyone: Red Green Show. Seriously. Google it. Find the videos on on YouTube. Better yet, here’s a link: http://www.ilaugh.com/the_red_green_show. This guy epitomizes what happens when the Duct Tape Paradigm is taken taken to an extreme. Note the bad ending that comes to each of his projects.

Final note, that guy who can roll out of bed and come to work without a shower, combing his hair, brushing his teeth, and wearing yesterday’s dirty clothes - Joel’s ultimate duct tape programmer - is the same guy who can look you in the eye and lie to you without blinking when you ask him whether he’s tested and if his code is /ready/ to ship.

Jim

another marketing strategy, huh?

HI i come form china

this is my web http://www.26sou.com/ 26??? ?? ? ??

I am not seeing the point of difference here.

One of the behaviours of effective teams is that each person tends to hand off work to the next person in a way that gets the team closer to the objective they are trying to achieve. This goes for teams of cooks, carpenters and programmers.

Avoiding work that does not get your team closer to its objective and testing are both good ways doing this. Avoidance obviously beats testing (some code will always have at least as many bugs as no code and take longer to implement) but if you have to write some code then you will usually be more effective if you can get it working in a way that it won’t come back to you for fixing later.

Testing can help you get your code right before you hand it off and TDD is one way of testing.

Applying any practice dogmatically tends not to be effective but TDD is one of the easier software management methodologies for pragmatic software developers to assimilate into their effective daily routines for the reasons described above.

You don’t have to floss all your teeth – only the ones you want to keep ;-)

Thank you for using the word ‘Balance’.

Am I the only one who thinks that Joel is ironic in that post?

The primary product of Joel’s company is bug-tracking software. Duct Tape Programmers ship shit with logs of bugs that need tracking and fixing. Coincidence?

Come now.

When I worked in taxes we hated confusing tax laws even though it made people pay for our services because they were as much trouble for us as them, nor do any of my friends in the medical field promote disease as a way to drum up business.

Don’t pretend that JS will want to drum up bugs to bolster business. The world has plenty of bugs and feature requests.

Let’s argue on merits more and sources less. I disagree woth spolsky partly but not because of fogbugs. When I disagree with bob it isn’t because he’s a consultant. Such attacks on character draw attention away from the essentials.

i say don’t unit test ever, that way your software sucks for maintenance and my software can beat your software’ s ass.

You guys should realize that Joel is making a people-point not a methodology point.

Everybody in the world loves coders who repeatedly hit dates on time. Even better than coders who hit dates, coders who hit dates with clean code! Sometimes though the date is more important than the code cleanliness. Sometimes shit is acceptable to hit a killer date. Those are business decisions that teams have to make together. A perfect example is a start-up, you may have a very real date (for instance you’re about to run out of money). Its probably better to ship before that date.

The good news is that you guys are right – most productive coders are generally relatively clean coders who write things like unit tests. Its really difficult to be a shitty programmer and still be productive. I’ve worked with a shitload of developers and I’ve never, ever seen that combo – shitty programmer who regularly hits dates. I’m sure JZW (the developer refered to) writes really good & clean code, he did ship a really stable version of netscape that was really damn successful… without any unit tests!!! Thats really f’n impressive!

TDD is one great tool to deliver quality quickly. Sometimes TDD is not the answer though – here’s an example of when… some software can be really simple functionally but really difficult when dealing with scaling & performance (think Twitter). In that case a waterfall style with heavy performance tool dev’t might be a better fit than say TDD.

jwz’ reaction: (from http://jwz.livejournal.com/1096593.html)

“It’s such a strange article, in that it’s mostly favorable to my point of view but with such a breathless amazement to it, like he’s just discovered an actual unicorn or something. “Look, everybody! Here’s a hacker who actually accomplished things and yet he doesn’t fetishize the latest fads that I and all of my friends make our living writing about!”

heh!

Has jwz actually DONE anything, anything at all, in the last 10 years? I thought he died and went to a night club.

(Don’t take software advice from people who haven’t done anything new for 10 years)

> I want you to ship, but I don’t want you to ship shit.

In the real-world, sometimes shipping shit becomes unavoidable. Any conscientious developer/manager, however, will address this shit at the next available chance. This is something you can do only in the field software!

AFAICT jwz isn’t handing out software advice – the articles in the book reflect his time in the industry, and the fact that he’s chosen to apply himself differently since then shouldn’t necessarily

When it comes down to it – he has a lot more public code out there than ‘uncle’ bob – and it’s generally a lot more functional.

A lot depends on the intended lifecycle of what you are producing. If you are in the early startup experimental phase, where you are trying different things to see what works, then fewer tests, lots of duct tape, and creating that fast go-cart design faster is a good thing. It’s the perfect approach for finding what works.

However when you then need to move from that into something that’s going to go into production, and will last for a few, sometimes MANY YEARS (look at all the COBAL code out there still if you doubt this happens) longer than anyone ever thought, then you need quality maintainable code. You need unit tests and you need for developers to not be afraid to make fixes because they’ll more often break two other things for every thing they fix.

Yeah sure you can make quality code without unit tests. in the same way however that a even a broken clock is right twice a day. You do it by getting lucky, not by design.

What you can’t do without unit tests is RELIABLY and CONSISTANTLY make quality code that is not a nightmare for whoever has to maintain it.

Writing production code without using BDD or TDD and ample unit tests is a lot like running a budget deficite. You’re taking the easy and expedient route to get an immediate result with what you perceive is less pain, and are expecting someone else down the road to pay for all your sins.

@Chuck vdL: nothing more, nothing less

At the same time if the messy-maintenance-nightmare parts are cleanly separated from the healthy unit-tested core, you can control the scale of damage. Should I always clean up such messy parts and arm them with unit-tests before shipping? The answer for me is: it depends mostly on their size and criticalness.

I fully agree with respect to system treated as a whole. Lack of unit tests is a straight way to a nightmare. Keeping small messy parts here and there, when cleanly separated from healthy parts, is a whole different story for me though, given you really maintain the clean separation.

As a manager of application development, I have fired developers for not adopting TDD because I have seen the benefits of having the tests, and the cost of not having the tests.

One person was so sure I was going to fire him that he quit before I could. He wasn’t wrong, just a bit faster than me. ;)

I find it amazing that, just with the other portions of the Agile Religion, people are blithely making claims that would imply that it was nearly impossible to ship good software without using practice X, while they build their software on an ecosystem of other software which was practically 100% built without using practice X.

Yes, TDD can be better than not using TDD. But if not using TDD was the disaster people claim it is, resulting in software so bad it can’t be trusted to function at all, you wouldn’t be able to build your software today, would you? Because neither Windows nor linux would work well enough to use; neither your Java nor your C# development environment would work well enough to use; your web browsers wouldn’t work well enough to use; etc.

Some perspective is urgently required at this point.

Thanks for sharing these info with us! I was reading something similar on another website that i was researching. I will be sure to look around more. thanks…

Where’s the ‘economy of scale’ discussion? TDD, Agile, and duct tape are all great, provided they fit with the product/project/organization.

I love a duct tape programmer when I need one, same as I love a great developer working with the latest technologies when I need one. What I don’t want is to get the guru when I need a duct tape programmer or a duct tape programmer when I need a guru. I think this all depends on which company you are. I guess if you let anybody choose what car he would like, he will not pick the same car he “can” buy. The same happens in software development. When you are short on money, you will not complain if the car taking you work is not a Ferrari, as long as it takes you to work. If you are loaded with money, you will get picky about the leather smell of your Rolls Royce Phantom you just purchased. Some times you need a cheap car to take you to work, sometimes you need a Ferrari. The critical thing is to know which car you need when you get it, and not always aim for the Ferrari.

I consider myself as a duct tape programmer. But I also love my code to be elegant and clean. The missing factor is time. I usually get things up and running and afterwards, I like to do some backtracking and refactor my code. In that way I can assure the managers that my product will ship at a specific time, but not how pretty the code is going to be. For me it is more important to finish projects before deadline than code-elegancy.

Maintenance can require more effort than the first shipped version.

Are we going to keep patching with duct tape for every release?

I understand that Joel may have some points, but why do I have to put up with the juvenile style of writing that it’s one side or the other. If I get bad service at a restaurant, must I keep silent just because they have great pizza?

And quite frankly, while a newbie programmer can be excused for just “gettin er done” (translation:using StackOverlow and/or Google to find the answer), a senior programmer ought to know more than just hacks. Hacks are why I find 16 nested tables used for layout.

A senior programmer ought to know of the following: GoF, Posa, Fowler, Beck, Liskov, Meyer, Crockford, Booch, TDD, DDD, IEEE, ACM, CI, and REST.

The ideas are pretty nice: Keep it simple, ship code, don’t show off using advanced language features no one can understand let alone maintain. A shame Joel and his Duct tape guy show some incredible ignorance flaming C++ (and doesn’t give a good reason why). A book of 16 “greatest programmers”. Yeah, right.

For Christ’s sake, they were not flaming C++. This was 1994. Few people knew how to make a browser in 1994, or even what a browser was. Things like STL, templates or even namespaces DID NOT work in 1994. The most popular OS at the time was Windows 3.1, so multithreading did not work in 1994 either. It is from that perspective that they are offering their opinion. Do you really think that there is no template, or multithreading, or COM code in the Fog Creek source tree?

I agree with most of the spirit Joel puts into his posts. He does write a good blog. An excellent blog, in fact.

But I think it is a bad idea to simply ignore some of the very ignorant specific advice he proposes. At this point he is viewed by many novice programmers as a beacon of light shining in the darkness. Bad advice and silly stereotypes about languages and tools (c++, templates etc) being bad “because he says so” are just going to perpetuate the silly traction they already have in new developers.

The messy go-kart analogy was also worrying.

I’ve written a post (before I noticed you had one) detailing my thoughts on the duct-tape programmer post here, I encourage anyone to let me know what they think on my blog or via e-mail: http://mutedvision.net/blog/?p=44

Someone said that larger teams need more tests and smaller teams can get by without tests. That may be. Or may not.

I have observed that smarter programmers can get by with less tests when they go to make changes to a system they are not familiar with. If you are going to hire dumber programmers then you definitely need more tests for two reasons. 1-It helps them find what they need to change and 2-It helps make sure they don’t mess up the working code.

I have also observed that the way I draw the line between smarter and dumber programmers, the population on the “dumber” side is larger.

The basic issue here is that Spolsky is moving is backward and away from serious software engineering. Like real engineering duct tape can be used in high pressure situations, but once that situation has passed you really need to figure out what went wrong.

The name Duct Tape programming reminds me of the Red Green show. Hardly a way of writing software.

Welcome to Freshstyleshop, the hottest urban clothing site on the net! We offer great products from Gucci sneakers, prada sneakers, LV shoes, True Religion Jeans and many more! Our selection of products are always increasing for the fact that we have new items added weekly to our selection. All products on our site are already marked down 40-60% off retail price. Freshstyleshop also backs all its orders with a 110% satisfaction guarantee, making sure that our customers are left satisfied with the hottest products on the net.

I wonder ifthe differences in opinion that you have with Joel come from the nature of your businesses. My understanding is that Headspring primarilally does contract work and FogCreek does boxed software. It seems the perspective of having to sell something you have already spent time and money on would lean toward the duct tape method. Where as a contracting outfit has already agreed on a price (for the most part) and are working do deliver something for which they have already been paid.