8th Light Blog

> I've yet to meet an anti-TDD zealot who has actually spent a month developing the art of TDD. The detractors tend to be people who write really brittle tests that are a pain to maintain.

OK, sure. I'm basically pro-TDD, seeing as how everyone's taking sides. Yet there's a problem here, which is that (as Martin says here) bad testing is basically a design problem. To write better tests, learn better software design - which is to say, you do not do it (or at least most efficiently) by doing more TDD.

This stuff is not in the brochure. And it should be; because without it, the claims made by TDD evangelists are somewhat misleading. No, it will not make you a better engineer on its own, at all. No, it is not a substitute for getting your whiteboard marker out and drawing a few boxes, or thorough code reviews, or whatever else.

Sandi Metz makes this point in Practical Object Oriented Design in Ruby[0]; and the chapter on testing is right at the end of that book, presumably for the same reasons (get the design sense first, then you'll get a sane red-green-refactor thing going).

Note that I'm not talking about Ian Sommerville here - I'd never heard of him until this whole contretemps, but I'm given to understand he knows a thing or two about design. Perhaps if he really stuck at TDD, Bob Martin's favourite bit would flip[1]. For less experienced programmers, who have not yet felt the pain of maintaining a ball-of-mud and learned a thing or two about separating concerns, TDD…

Wait, since when TDD become a best practice?

I know this author is advocating it, but has 0 (zero) solid data or evidence to back this assertion. He is just trying to sell another religion. What I have noticed, TDD is being pedled heavy by RoR contracting shops that just care about billable hours and not vested if the startup or company is going to make it on the long run. I see often that it is the usually youngish and guidable engineers that fall in the trap of eating it up. TDD is something that makes younger and less experienced developers feel good (more locs) and a false sense that the code is correct while there is solid data that even 100% unit testing coverage finds only 20% of defects, at best.

Having shipped many world class products, and none of the processes that build those products had any resemble of TDD in them. So, to all the pragmatists out there feel free to ignore the advice on the article. I'd yet to hear a super successful startup that used TDD.

Having Tested Code (which is a good goal) != TDD. TDD to me is putting the carriage in front of the horse. Anybody that have created large systems from scratch, TDD is a major slowdown on the refining process. Your job is to SHIP a working product. Testing is only a small part of it, and its positives should be considered alongside its negatives and side effects on the shipping timelines.

Having worked for over 10 years in the industry I have to meet any great programmer that preferred TDD. I hate to…

I want to shine some light on one side problem, scratched here:

The problem today is (out of the perspective of a developer): To many companies rely on just "hire any (cheap) developer" to ramp up the product. I see it all the time: Quality is not asked for, many companies (specially in the web business) just want the cheapest developers. They search for a student (at best), because he is cheap and will just make a small time estimation and an even smaller fixed price offer for the project. The student will happily work overtime that is not covered by the initial estimation.

Than the companies go mad, when either the programmer is running away or the whole project runs into a blind alley (or both at the same time), because the "totally expensive" programmer had not enough experience e.g. with database development and the database structure just lets you shiver. Then the shouting and anger is big: "Damn programmers -- all are liars and lazy!"

What went wrong, stated Uncle Bob correctly in his Blog: http://blog.8thlight.com/uncle-bob/2013/11/19/HoardsOfNovices.html

But the "cheap, cheap!" culture seams to be unstoppable. If you tell people in advance about "quality" and "professionalism", they don't listen or just laugh at you. It seams, all the people just have to find out the hard way -- but I guess, even than most of them will not learn at all.

http://blog.8thlight.com/uncle-bob/2013/09/23/Test-first.html

Read that and read oldie, but goodie Extreme Programming Explained, and IMO they do a good job of painting the bigger picture.

TL;DR Tests are live specs that break when you change the underlying spec of your code without updating the spec in the test. If you can express your code's spec in a test, then you have a much higher chance of deeply understanding your design... hence the article's recommendation that you first know what you are doing before diving into writing tests.

As for tests in the larger practical sense vs. the trivial... The vast majority of large systems are compositions of small, seemingly trivial pieces. A large system's code needs to be organized so that all its component pieces/concerns are comprehensible and separate; otherwise, it's an unmaintainable monolithic soup. The unit tests adhere to the same principle, in general, and follow the composition of the system.

There is a whole movement around this called Software Craftsmanship. There are a lot of companies involved and typically they are using the apprenticeship model to bring on new employees and grow the company. The one I'm most familiar with is 8th Light which started in Chicago but is now in Los Angeles, London, and New York City too.

Their approach is more spend 5-9 months having the apprentice do mostly directed self-study, then a kind of final project and other work and, if they pass, an offer of employment. It's a really interesting model that seems to have worked well for them -- they attract developers from both traditional backgrounds and non-traditional.

They have a page that goes into what apprenticeship means to them here: https://8thlight.com/apprenticeship/

A few years ago, I tried to use Core Erlang as a compiler backend. It's fairly straightforward to learn even without thorough documentation. I wrote a bit about my process to try to help the next person [0]. For my particular project, I ended up abbandoning the approach and generating BEAM bytecode instead [1]. That was definitely more challenging, but it was neat to see Erlang's commitment to backwards compatibility in action. I believe that BEAM modules emitted by the first versions of Erlang are still valid on modern implementations. New functions are added and old ones are deprecated, but the actual file format version indicator hasn't changed.

[0]: https://8thlight.com/blog/kofi-gumbs/2017/05/02/core-erlang.html

[1]: https://github.com/hkgumbs/codec-beam