Hacker News Reader

Comment by BurningFrog | Hacker News Reader

"Over a development cycle of 12 months, 35 percent is another four months, which is huge,” Nagappan says. “However, the tradeoff is that you reduce post-release maintenance costs significantly, since code quality is so much better."

Another way of describing this is that the non TDD teams weren't actually done when they shipped.

View on HN

I viewed this as a trade-off. "If you can spare 35% more time, write your tests first. If speed is so important that you can slough off on testing at the end, don't."

Sometimes partially perfect and released beats better but later. (Perhaps not for Microsoft, but certainly for lots of their competitors) How many more bugs can you find with software "in the Wild"?

This isn't to say it's worth tossing crappy code over the transom, just that real tradeoffs do exist.

> Sometimes partially perfect and released beats better but later.

Especially since "later" implies a new market, with new demands on the product. "Better" then becomes a moving target, and with "Best" you might as well say "Stop building the road when you reach the horizon and the sky stops you".

Yes, it's a tradeoff. Not doing TDD is trading quality for speed. See the Iron Triangle of PM: fast, good, or cheap, you can pick two at most.

I think this is a fallacy and a hard one to fall into. By shipping buggy code, you will end up creating a larger number of incoming bugs. Consequently, the amount of time you spend on incoming bugs will increase from 5% of sprint to 30% to cases where you have to do bug-only sprints.

In the short term, TDD will look like it's costing more (especially if the product is not released). But if you want developers to maintain confidence in their code or for your team to depend upon the dev team's ability to deliver robust code, it's an important safeguard to have.

Also, what if the non-TDD were given another four months just to fix bugs after the release?

In that light, TDD might just be a ploy to buy more time.

Yes, call it PRR (Pre Release Refactor) and people will buy into it.

>Another way of describing this is that the non TDD teams weren't actually done when they shipped.

Was ANY code, TDD or not, ever "done" when it shipped?

Absolutely. Off the top of my head, the first thing that comes to mind are video games that were shipped on ROM cartridges. Bugs or not, when shipped, it's done.

Those days are long gone. Even in an deeply embedded world like automotive or AV equipment, code is (or can be) frequently updated.

In the very deeply embedded world, there are often no update mechanisms, period.

Possibly pacemaker firmware? I have no real knowledge of the subject, but I'm guessing it'd be kind of risky to equip a pacemaker with Bluetooth to accept over-the-air firmware updates.

There were headlines in 2012 about pacemaker vulnerabilities. Apparently, they could be commanded to deliver an 830 volt shock, probably fatal, by someone with a laptop nearby.

You'd probably be right about the risk. But a buddy of mine has a pacemaker, and the version he has now allows wireless updates and tuning. It's possible that a firmware update still requires direct access, but it's possible it's wireless.

Of course, you'd better be darn sure the update works (firmware updates always scare me a little, never mind on a pacemaker!)

I've long argued against people who say TDD is 'just as quick' when you get used to it. It's simply not true. I still test everything however, the payoffs are multitude. It's important to accustom your product managers to your velocity when tests are included.

TDD, or at least effective use of automated tests can make implementation much faster and code better.

Mappings + conversions are such a case.

For example if you're using an ORM being able to test the mappings in seconds will increase velocity. Or if you've written a function to convert type T0 to type T1, then automatically testing all combinations of T is very effective.

Absolutely agree that it can. For cases like you mention, where it's convenient to be able to rapidly test the outcome of a piece of code, it can be orders of magnitude faster and you have a greater confidence in the end result.

On average though, it takes longer (as summarised in the article).

This is why I don't trust TDD proponents. I'm not against TDD itself, or unit testing as a whole, but I'm also not 20 y/o college kid. There is absolutely no way the increase in workload of TDD doesn't have a cost.

It's a question of tradeoffs, something I've said many many times, and the research appears to be bearing that out.

No one who is being honest can really say with a straight face that development with TDD is actively faster unless they're naive or they're using cherry picked examples.

Its faster in terms development + time spent fixing bugs.

If you want it out now, but have loads of bugs sure. But i'm pretty sure most managers don't mean that, when they say they want it out sooner.

Not even the research bears that out.

> There is absolutely no way the increase in workload of TDD doesn't have a cost.

TDD has both costs and benefits. Like most everything else.

Reply on news.ycombinator.com