Comment by lgleason | Hacker News Reader

Comment by lgleason | Hacker News Reader

Parent Full thread

Uncle Bob has great advice that a large swath of the industry can benefit from. Keep in mind that a large portion of the industry, especially in corporate America, writes really bad code and his advice helps these people to put guardrails around that. The 10% bad advice I would attribute to the 10% of instances when "the rules" should be broken. But the key to breaking the rules is having an understanding of why the rules are there and as such why they should be broken.

His dogmatic approach is partially, from what I've seen, a counterbalance to the sloppiness that a large part of the industry, especially corporate America, has with software development. Can you take it too far and create beautiful software that does not solve any problems? Sure, but on the flip side it is also easy to create a lot of technical debt.

With things like TDD, when devs are new to it, part of the learning process is to take it too far first and then as you understand it you learn the right balance.

Uncle Bob gives some very bad advice. For example, he advocates passing temporary state between methods implicitly in instance variables instead of explicitly (and nonshared) via arguments and return values, increasing the statefulness of the code and creating complex ordering constraints and preconditions for method invocations. E.g. https://softwareengineering.stackexchange.com/questions/2887...

One can’t recommend his books with good conscience to anyone who doesn’t already have a very good judgment regarding software design and can pick out the parts that actually make sense.

Uncle Bob sees classes as animals with internal state, not as abstract structures grouping together consumable APIs and their internal workings.

Calling bound functions ”methods” is perhaps a bit misleading.

TDD has been around for two decades now. One would expect there to be some high profile success story. Yet none of the important software projects we use on a day to day basis seems to utilize it. Not even one.

The whole idea that something has to have a high profile success story available to the public for it to be an actual success doesn't really hold. Lots of people are far more busy with their work than they are with blogging and/or publicity. There are plenty of examples in my practice of quiet successes, some using TDD, some without and for those companies it may well have been a factor.

Depending on the industry, reliability and ability to ship software that functions as advertised from day #1 can be a huge advantage, and for others it can be a wash or even a competitive disadvantage if it consumes too many resources. But I would not dismiss any such tool out of hand just because you personally have not seen or heard about the success stories.

Oh, absolutely. It's the lack of quiet successes that is notable here. Like Linux, or apt, or nginx, or Python, or at least a popular Python module. Or anything, really.

After two decades of consulting in the software industry, you belong to a certain professional network. People love to talk, even if they won't always name their customers. I know people using formal methods and verification, in niches of the industry really, but have no indication that TDD is utilized for any big flagship products where it really matters.

I'm sure there are a few highly blogged about industry stories somewhere, but there's a world of a difference between those and a long time success in software development as a whole. There were high profile books written about Rational Unified Process, for example, and ~ nobody uses that anymore.

agreed

I've sort of half-suspected that TDD doesn't actually exist. I've never met anyone who does it. I've seen people talk it up a lot, and programming shops sometimes claim to be all about TDD, but when you look at how they work it's not TDD at all, but some token unit tests after the development is finished.

I have met one. His excuse for pushing broken code to trunk was "but it passes the unit tests". The same person also managed to write unit tests with >90% line coverage that just didn't check any results.

Wrong?

https://github.com/linux-test-project/ltp/wiki https://github.com/neovim/neovim/tree/master/test https://github.com/openssl/openssl/blob/master/test/README.s...

What are you trying to say, that people don't write tests for their code?

Are you trying to say that “Test-Driven Development” is “writ[ing] tests for their code”?

Test-Driven Development means that the tests are written before the features.

That's a common misunderstanding, but it's not true. TDD involves writing the tests at the same time as the code in tiny little steps. Write a few lines of test code that fail --> write a few lines of production code to make it pass --> refactor if needed to clean things up --> repeat.

> Write a few lines of test code that fail

OK, write the test…

> write a few lines of production code to make it pass

…before the feature.

I recognize the color you’re trying to add (it’s more like TFTFTF than TTTFFF), but it remains Test-Driven Development.

Sure, if you insist. I've seen enough people misunderstand TDD to be TTTFFF that I think it's important to clarify.

Writing tests and doing TDD aren't the same thing. The commenter is talking about TDD in particular I think, not saying "unit testing has no success stories".

No. Those are most integration tests (neovim has some unit tests)

You're conflating unit tests with general testing

Uncle Bob makes it very clear that he only considers "unit tests" to be valid

So, no, these dogmatically "don't count"

(they do count when Uncle Bob supporters want to play half-truths and push for TDD instead of more realistic tests)

I'm an Uncle Bob supporter, but also support pragmatic testing techniques depending on the platform. The two are not mutually exclusive.

Linux and OpenSSL are two great examples of projects that probably should, but doesn't bother, to do much testing at all. Even if they are both steadily getting better at it.

They obviously produce useful results and most would love to see more of it, yet it is tacked on afterwards and often by completely different people than the original developers, not as part of the development process.

They have a long way to go to have good enough tests that could be relied on for integration purposes. TDD isn't even on the map. And will probably never be.

I would agree with this, but perhaps the commenter has a different definition of "high profile" ¯\_(ツ)_/¯

I'm not sure what tech stacks you work on, but I've worked with lots of tech stacks and high profile projects that use it and also saw the quality that resulted from the practice.

How do you know what testing/designing practices all "important" software projects use?

Do you expect it to be advertised?

It's been twenty years. People would have moved on to new jobs, and spread the word with them. Some would have applied for jobs there. After all, non-googlers know a thing or two about their infrastructure, despite being mostly a trade secret.

If nothing else, apparently there are enough of disciples out there that it would be a great way of hiring the right people.

You'd have to believe there is some sort of cabal, completely bent on keeping this enormous advantage to themselves in absolute secrecy, to argue that it is a software development success story.

Reply on news.ycombinator.com