I went on a couple of interviews where the interviewer said “We use test-driven development.”
Even my sister thinks that test-driven development is stupid. How can you write tests before you write the program?
I try to be polite, even when the interviewer says “I’m a retard. Do you like working for idiots?” I express polite skepticism, over whether it’s a good idea.
The reaction of the interviewer is interesting.
When someone disagrees with me, I try to convince them. If someone is completely hopeless I give up, but I try to answer reasonable questions.
For example, many people express skepticism about agorism and really free markets. I answer any reasonable questions. However, wasting time on pro-State trolls is stupid. I wonder if the interviewer sees me as a troll who hasn’t drunk the “test driven development” Kool-Aid.
That is a subtle distinction. “I don’t waste time on stupid people who disagree with me, because I’ll never convince them.” and “I don’t waste time on people who disagree with me, because I’m stubborn and don’t want my false beliefs challenged.” I’m pretty sure that I do the former and “test driven development” idiots do the latter. The psychopath behavior mimics the behavior of a real leader. A real leader won’t waste time on fools. A psychopath won’t talk to people who question his leadership.
Here is the amazing part. No interviewer has tried to convince me that “test driven development” is a good idea! If it really is awesome, then the interviewer should be trying to explain to me why it’s a good idea!
When the interviewer is insane, interviewing for a job is like trying to join a religious cult. If I say “I’m not sure this is awesome!”, then the interviewer says “I’m not hiring FSK!” rather than “I’m going to try and convince FSK that this is a good technique!”
That is strong evidence that “test driven development” is a fad with no merit. If it really was awesome, the interviewer would try to explain the merits to me. Instead, they reject me because I don’t already think that test driven development is awesome.
In case you are confused, I do favor automated test scripts. I question the wisdom of writing the tests first. If I’m QAing someone else’s code, I look at the code and try to pick tests that use every bit of code. At my last job, they had really sloppy QA, even though they were a huge financial institution.
When an intelligent person disagrees with me, I try to convince them. I really am openminded. However, the people who advocate for “test driven development” don’t try to convince me, when I express polite skepticism. That is evidence that it’s hype-based and not merit-based.
There is one situation where “test driven development” is useful. If you and your subordinates are unqualified twits, then “test driven development” helps you wring some productivity out of clueless people.
As someone on the high end of the ability scale, I would be shackling myself, if I were forced to write a ton of tests before writing the code. Most of these “frameworks” and “development methodologies” are really methods for maximizing productivity from unqualified losers. It’s silly for me to shackle myself like that. I really can be 10x or 100x more productive than most people.
A long time ago I met a recruitment consultant. He told me that he aimed to give better service than the vast majority of other recruiters as a means of getting repeat business.
In fact this guy was worst than the rest because he totally sold me down the river to a venture capital company with no software and no customers (the hiring manager effectively lied to me) and I got fired after making the company loads of money. He was friends with management and he must have know what was doing on there i.e. no customers and no software.
Anyway he told me that the software industry is like the FASHION INDUSTRY.
FSK may be seeing a symptom of this. Now the fashion is test driven development. The last fashion was Agile development. Some old fashions were UML or Waterfall.
Companies should hire people good at writing code. But stupid managers need to make themselves feel useful and this means being the clever clogs that recommend silly methods that have nice books written about them.
If you have a large enough codebase that one person can not hold it all in his head at once, then someone making a lot of changes to code is going to badly break it in hard to detect ways unless you have module testing in the form of regression tests at a fine enough level to instantly detect bad changes. One can leave working code alone and avoid this, but then one ends up with the big ball of mud pattern and it becomes impossible to fix bugs or make even small changes without inadvertently breaking things in subtle ways anyway. One solution to this is allow for refactoring things to redesign in place before making major changes to it, but to do this safely requires that one have comprehensive tests. The thing is though that people won’t write tests after the fact when stuff is working, so to get it to happen you have to require that tests be written first, before the code.
So that’s why they are doing this. If they aren’t doing the whole set of things though, it’s all pointless. The testing is to support the ability of one person to refactor code written by another without breaking it.
BTW, my post is not to advocate but explain the reasoning and set of circumstances that led some to advocate doing this.
Of course as your post hints at, a gigantic problem with this is if you can write tests before you write code you must know exactly what the code does and be writing to a spec that is completely nailed down and which has been thrown over the wall from the architect to the analyst and then from the analyst to the coder.
If it turns out that The Code Is The Design, and the developer is also the person who makes it all work, then it’s obviously not possible to write tests first most of the time because we don’t yet know how something is going to work.
One solution to this problem is to, as you say, have someone such as a QA department write the tests, to test functionality as described by the technical writer who interviews the developer or just looks at the code. But most companies don’t even have QA. It’s really funny when they’ll be going on about the necessity for heavy methodology and they don’t have a QA department that is capable of writing tests to check the code.
(note: “thrown over the wall from the architect to the analyst and then from the analyst to the coder” of course means Waterfall methodology or BDUF)
Your insight about whether they can explain it back to you is the key. If they don’t understand WHY they are advocating building tests first, then they aren’t qualified to be advocating it and should just let people do whatever.
I never said that I was opposed to automated testing. My complaint was against “tests first, code later” or “test-driven development”.
I had two people advocate for it in my recent job interview cycle. Both of them seemed like fools.
The key insight is that, when I express skepticism, they dismiss me rather than try to explain to me why it’s a good idea.
My new job is the opposite extreme. They don’t have a QA server. They don’t have a dev server; their other developer directly edited production. I asked them to set up a QA/dev environment on my PC, and they didn’t know how to set it up and configure it.
If you never do a restore, then you’re never doing a backup!
Methodology fanboys don’t realize that a certain methodology of works for certain types of software.
Suppose you are writing a new type of 3d engine or a complicated parser or are doing experimental stuff in trying to write a totally better type of software… Then the software is so complicated and so time-comsuming and the problems so difficult then having to do up-front tests won’t really help you.
I agree with the need for tests in large amounts of software, but if the piece of software you are writing is really advanced and difficult, it may be better just to get the thing working first and solve the problems first. Some software is so difficult you only know the problems once you start the work. Business analysts can’t help with this kind of work because they don’t understand it.
“Test Driven Development” is a buzz word.
However, there are some techniques I’ve picked up over the years that might be considered “Test Driven Development”.
I write test code at the same time I write my code (not before)…so I might write a little code than write a little test harness code to execute that code to be sure it’s working properly and than repeat.
I try to isolate code that accesses external resources (database, web services, etc) so that I can test the logic in the code without having those resources available all the time.
I once worked at a big company who did ‘test driven development’. The analysts wrote tests for every module, and handed them over to the developers. A typical test might read: if parameter A is 2, and parameter B is 3, then the module should return 5.
All the programmers at the company were boys. The management decided they were a bunch of flaky, undisciplined prima donnas. So they hired a girl – let’s call her Stella.
Stella was a marvel. All her code was absolutely perfect. It checked in, and never broke the build. It flew through all the automated tests without a single flaw. And she was amazingly fast. Meanwhile, the boys were constantly running late, and checking in code that either broke the build, or failed the tests.
Stella was given a commendation, a bonus and a glowing reference, and swiftly joined another firm. The boys struggled on, and some months later, the program was completed, tested and deployed into production. It wasn’t long before the customers noticed the program was giving nonsensical results.
The source code was retrieved, and someone reviewed Stella’s code for the first time. Every one of her modules, hundreds of them, contained one statement which simply returned the expected test results, for example:
IF ParameterA = 2 AND ParameterB = 3 THEN RETURN 5
That is a good story.
No matter what performance review metric you use, someone will always find a way to game it.
“Test driven development” is stupid. How can you write tests before the code?
Automated testing is good. The best tests cover problems that actually occurred once.
When I did QA, I reviewed the code. I came up with specific tests that illustrated bugs I found.
Another amusing lesson is “When you do a lousy job and con people, switch jobs before your results catch up with you.”
Another fundamental flaw with TDD is that — by definition — it cannot be known, when the test is first written, i.e., before the code it is tests has been written, whether the test ITSELF has bugs. Tests are themselves software that can be buggy. Therefore, the initial status of the test as failing may be due also to the test being buggy, not only the code under test’s being incomplete. So now, during development, when you are struggling to get the automated test to pass, you’ve got two places to worry about. Debugging is all about eliminating variables and isolating problems, not adding variables. TDD — specifically, the “write tests first” part — is asinine. I’m glad someone is calling it out, good work!
After spending a lot of time with PHP and Javascript, I started doing some C/C++ again. It’s amazing how nice it is to use a strongly typed language. The compiler catches so many bugs for you! The compiler catches mistyped variable names, unused local variables, wrong function arguments, and more. Plus, the compiler error messages in C/C++ are so much better than the barely-useful messages you get from PHP and Javascript(firebug).
Also, how do you qualify for having your own Wikipedia page? I thought they’re pretty strict. You work at Wireless Generation? They used to spam Craigslist job ads but I haven’t seen them in awhile. I never got an on-site interview from them.