I hate FizzBuzz and Will Analyse anyone who uses it

One FizzBuzz Interview so far.... News flash... The moment I am asked to write FizzBuzz during a technical test I intentionally stop and ask the questions from there on out.  I've done this a couple of times.  And you know what I learned... I learned a whole lot more about the interviewer and their processed than they found out about me.

Let me take you back to a technical interview I had about five years ago.

I drive up to the building, it is way out in the sticks; just about still in my home county, but so obscure it's in a part I have never ever been in.

I pull up and the building is like a box of black glass, no character, no soul, just a box.  The non-native tree species planted around it to discourage birds actually using the tree's and the austere grass puts me off.

Things don't get any better, for I walk through the door and there's no secretary, no desk, nothing... The lights aren't even on; this doesn't bode well.  I look around for a buzzer, a phone even a limp notice of what to do.  When a door opens and a man approaches offering me a hand to shake.  He leads me to a similarly deserted corridor with a chair in it and I'm left to my devices once again.

I read some inane notice about some award some member of the staff had received (this is important later in the interview) and I read the fire evacuation notice.  It's quiet, quiet and silent.  There's one door nearby with a few people within and another which is a closed office piled with stacks of desks..... Empty corridors - which would be dev spaces, massive rooms with a few people in them, no secretary and piles of desks?  What have I walked into?

About ten minutes later I'm ushered into this room, I've brought my CV a few piece of detail about me and some references to my technical projects at home; as well as references to some of the discussions I have on these very pages and my github.  You know actual technical things, which you can see me achieving.

I can't talk about my current work with them... Heck I can't talk to you guys about my work now.  But I do it, and I pay a mortgage; that's all the proof I can proffer.

Anyway, I seat myself and a lady explains their technical lead will come and perform the technical test, he enters a moment later with a massively overpowered gaming laptop.  I hate gaming laptops.

I much prefer a simple sleak laptop, a decent screen, nice keyboard and plenty of battery life; and I do my work on a remote machine via SSH or whatever machinations you wish.  I do not generally work on my laptop, it's a portal onto other more powerful machines which are tethered, and this way I can go take my laptop with me anywhere and get amazing performance from it, as I'm only interested in a bit of internet, RAM and then remoting into other services.

Anyway, he plonks this behemoth down and proceeds to tell me about test driven development... TDD.

I HATE TDD.

Now, I know test have a place, heck I really like doctest, including tests into code you've written, to ensure it is within specification is perfect, and validates your progress.

My hatred comes from writing tests up front, I find this backwards logic, and I don't think you could ever persuade me otherwise.  Define the scope of your input, validate it in your code (I often assert up front when data is unexpected or malformed, or at the very least bail early) and then you run your code, and then TEST the result.  I do not believe you should write a test and then further write the code to fulfill that test.

You will miss something, you will be thinking about the test as the solution, rather than the solution itself.

If anything writing the test and then producing the code to meet that test may very well be called TDD today, but when I was a lad it was called Prototyping.  And though I'm sure we can all agree prototyping is best done in a language different to your final product, it is not really prototyping when you are not producing the product, you're producing a test.

I find it wasteful of time, and often ignores enough scope, for instance I've seen a fair few hundred thousand up front tests written and then the code to meet them in my time, never have I seen a validation of the input data, the input has generally been hard set into the test.  That's not as wise a test-scope of ensuring the result after the fact.

(This does not mean test suits after the fact are the best, I just think they're the best for my style; not least as they are opt-in, for those times you are in a swing, and easy to add later).

So, TDD... Why is he telling me about TDD?

He does, he explains they have a method and that method is structured, he does not offer me any test framework specifically, instead he opens notepad and asked me to write FizzBuzz.

And the interview stops there; I don't think the guy realised it, but I stopped being interviewed at that point, I was not going to accept their job even if offered, but I wanted to see where this lad (and he was young) was going with his thinking.

This half empty hulking building and they're trying to hire engineers, and he is going on about TDD but FizzBuzz?

So I play total dumb, I simply start to write "int main"... And he surprises me.

"No No, start with the test".

Ohkakkkakay....

I have NO idea what test suites he has installed, I don't use G-Test or Boost-Test, I use doctest.  So I write a SCENARIO; he blinks and just takes the laptop off of me and starts to open some other window... I didn't know he would allow me to open some other window, this isn't my machine, I don't know what he has installed.

This sort of sums up TDD to me, the tools aren't easily defined.

Anyway, twenty minutes later and I just about have it Buzzing on 5's and I'm not very interested, I've come to a conclusion.

He isn't impressed; rightly so, but he has no idea he's just been investigated by an older and more cynical mind than his.

He leaves and no less than three people come into continue the conversation, and boy do they, they talk to me for a solid 120 minutes; I timed it... I was so bored.  But I engaged a little when they talked about their award winning technology.

I recall the poster for the lady who had won this award and mention her, by name.

"What, how do you, who has been talking to you?"

This is very strange, "no" I assure them "no-one, I saw the poster on the notice board".  One of the two girls flanking the chap in the middle here makes a note.

They talk to me about the company a bit more, they talk about their re-shuffling engineering and wanting to press their position forward to a virtual machine the customer hosts on hardware; previously they had been providing a dedicated box.

I'm terminally not interested in this boring black blocky building which now perfectly reflects the boring blocky people inside.

And I give up, I lean forward, elbows on the table, and I gather the copies of my CV from the hands of the three people and I say:

"Look, I've spoken with your technical lead, and I'm scared to my core of your processes, I don't like what I've heard, it seems you're struggling to recruit and there are reasons for this you will have to identify yourselves; I don't think I can help you"

They are scowling a little here, I'm sure they're far more used to candidates who want the job.

"Indeed, I think somewhere you have a beige room with ranks of screens and engineers in stuff suits not talking with a great board or wiki with all the failing builds traffic lit from your little test driven development board...."

At this point the lady on the left looks at the guy in the middle, who has a little switch to his eye.

"And such a stifling, control freak, desperate development environment is not one I wish to be part of"

They thank me, and I thank them sincerely.  And I leave.

As I come out of the building the sun has come around, the black glass face of the building is now not so black, instead I can see inside, there are three long benches of PC's all facing a pair of chaps at the front sporting bluetooth ear phones in one ear.  Above their heads is a large TV screen with a list of running continuous integration tasks and each has a traffic light.  As I watch one goes red, one of the two larger men touches the headset at his ear and an engineer on one of the benches glances up and starts to scrabble about on their machine.

It is a sweat shop.  I was not only right, but so happy I'm driving off.

I felt like going and knocking on the glass and cooing at them "Come, follow me, be free, be free".

But instead I just drove home.

Prior me: Just coming into edit this before it goes live on Friday, guess what I'm watching... 

And I disagree with the approach of analysing FizzBuzz; analyse the interviewer.

IT Sexism : What is Modern Development (for a Woman)?

Recently, I was challenged, almost to a fault, to enthuse myself about "modern development"... The quiz master expected me to extol about the virtues of distributed code verses centralised, to effervesce about sprints, about round tabling, about all these other buzz words and cockeyed concepts.

I simple asked the quiz master, quite what they meant by "modern development" ...

So surprised were they that they broke through a little bit of their shell and just talked to me, it was a refreshing change, moving away from methods and procedure, we talked about the system itself, avoiding even the language they were working in.

It soon became apparent we both worked from the same hymn sheet, just perhaps mine is an older copy... For you see, to me a good development job, doesn't necessarily sit with the work at hand, it sits with how you are allowed to approach that work, if you are just bombarded with red-tape and requirements and  micromanagement, then the person micromanaging you may as well just do the job on their own; and I have worked as the poor soul doing the work in just such a situation.  And it soon became clear this was the problem with the team this person was controlling.

It appeared they had gone through personality, philosophy and finally technical clashes, to the point that the four developers on the team didn't do much more than talk to one another about computers and draw their cheque each month.

The manager was doing all the work, not because she wanted to, not because she was female and they pushed it onto her, but because she had set high standards and promised delivery, but was getting no input from those below her.

In a paradoxical, and pretty toxic, situation, she was enabled to hire one more head, but not able to fire the useless four... She had ideas I might be that fifth chair, not a thought I relished as the conversation expanded into the actual problems she faced.

Now I've run into dysfunctional teams, but I know in the end the work either gets done or you all get fired, sometimes both.  But to sit and provocatively do nothing in the manner these folks did was tantamount to embezzlement, when I was introduced to them, they just sniffed and looked at me; I was egging myself onto ask them technical questions, but I was whisked into a private meeting room where this sad talk unfolds from.

After twenty minutes lamenting the problems I asked "What do you use as a way to leverage the work, what is that pedal you press to put on the pressure or get results?"...

She looked at me rather blankly, almost as though I were a magician showing a dog a card trick, as her eyes blinked she started to reel of a bunch of methods... Waterfall this and sprint that, and engagement in progress... yadda yadda yadda....

I put my hand palm up and asked again "not what procedures, what do you physically do?"

She didn't do anything, she sat in her office away from them all day and did code.  She never got out her chair and challenged them, she never spoke to then, she never pushed them in person... "Why not?"

And I was flabbergast to hear an intelligent, clearly able, mid twenty something, graduate and clearly decent programmer trying to manage a team say to me... "Because I'm a woman, they don't listen".

She was serious too!  Going on to explain that when she started she worked for a chap about my age, and they listened to him, she was one of them, but took a lot of ribbing, she moved into the supervisory role, still in the same room as them without issue, then was appointed to manage this new project when the other chap left... And that's where the problem started.

I wasn't sure whether it was green eyed envy at her progressing above them, or just because she had boobs, but whatever the reason I thought it extremely uncomfortable.  I saw her wanting, desperately to have a puppet in a more senior position to the team, to invoke her will upon them, and wanted myself (clearly 10 years older than them, and twenty something years her senior in age) just as a sort of enforcer and inquisition.

And I thought, her idea was "modern development", lots of buzz words and concepts, she had lost the "just talk to people" vibe.  Sadly because she was being intimidated, perhaps even sexually harassed... That, was the sad state, I found modern development in... Sickening and not a place I wanted to involve myself.

Software Engineering : Test Driven Development (TDD)

"Test-first fundamentalism is like abstinence-only sex ed:

An unrealistic, ineffective morality campaign for self-loathing and shaming."

 - David Heinemeier Hansson, 2014

I was very recently inflicted a case of TDD... I didn't like it, like the bad taste of medicine it lingered on my mind, so that I had to do some reading to even wrap my mind around the concept, and in wrapping around the idea my mind is made up to throttle it out of existence anywhere near me.

I come from the very much more formal days of development, from systems where you had very limited resources, there wasn't space to run a test suit on top of your editor next to your compiler, indeed the systems I learned to program with one had to chose to swap the editor and compiler and even a separate linker in and out of memory to achieve your build.

Taking that amount of time to do a build, it makes you learn from your mistakes quickly.  Such that I find myself now a rounded, and I'd like to think good, programmer.  I'm not the best, I've met a few of the best, but I'm good.

So combine a propensity to think about the problem and the drive to achieve a solution in code quickly, I'm used to thinking about testing after the fact, used to at least in part sticking to the old mantra of "Analyse -> Design -> Implement -> Test -> Document", with each step feeding each other.

For you see development today is not serial any more, you don't have time to stop and think, you perhaps should.  This was perhaps the only positive I see in employing TDD, and indeed it was one of the positives myself and the chap I was speaking to commonly came to, it makes you slow down and think about a problem.

However, if you're a traditional programmer, a goal orientated programmer, like myself, you've a plethora of patterns, design and experience to draw upon, which tell you your goal is achievable a certain way.

Design patterns and library implementation style, and simple rote learning of a path to a solution can drive development, peer review can share you ideas and impart new ideas on yourself, so why should you let the test; something which intrinsically feels like the end result, or the last step before accepting the solution; drive development of the solution?

I really can't think of a reason, and have now to take to the words of brighter stars than myself to express how it made me feel...

It felt like a litmus test, something being used to make me feel unprofessional, in a single trivial class, which should have taken five minutes to write and check over, an hours struggle ensued where hammer blow by hammer blow by the grace of TDD I was held up as a heretic.  "Thou dost not know TDD", the little voice in the back of my mind said, and I felt low.

But beyond how I felt, it seemed so inefficient to work in that manner, when one has programmed or engineered or done any task for long enough we build a reflect memory of how to achieve that task again, walking, reading, driving, programming... All these life goals and skills we just pick up.

Training in Karate was very much like this, one had to teach people to do things with care... 10 Print Hello 20 goto 10... Then we had to show them how to do more complex packaging and reuse of code procedure example(p_value : integer) and eventually we could let them free fight int main () { std::cout << "Hello World!" << std::endl; } and during this building up we let them drop the earlier teachings into their muscle memory, into their subconscious, we exercised, but didn't re-teach the same things, didn't cover the same ground.

Yet that coverage of the same ground is exactly where I felt TDD was taking me, and it seems to be the consensus among other "non believers" as to where it takes you, to write a test exercising your code, then to iterate over changes, sure it drives efficient code in the end, it drives out tested code before a single functional line has been written, but was it the quickest way to the same solution?

For a seasoned, experienced programmer like myself, No, No it was not, it bypassed so much of my experience as to know my self-confidence to literally brow beat me into worry.

I therefore stand and say "I do not write software test-first", and this is based on having to learn in an environment where one could not afford the processor cycles or memory to test, nor did one have bosses open to the concept of micro-design and iteratively pawing over code, one had to get the job done, and get it right or not have a role any longer.

Huib Schoots over at AgileRecord can be quoted as writing "TDD is a method of learning while writing clean, maintainable, highquality code", I would have to paraphrase that statement as "a method of learning today from scratch whilst writing modern, clean, maintainable, highquality code"  for a programmer setting out to learn their craft today is never going to have the benefit of the environment I learned in, they're not going to catch up to my twenty plus years of industry exposure and some thirty years academic experience on the topic.  They need to learn, and if teaching test proves a good starting point so be it, however, once the learning curve plateau is reached, even before, one has to question whether you need to take that next step back, step away from micromanaging the development process and evolving your code to just delivering the final product in a working form.*

Others on the topic:

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

http://beust.com/weblog/2014/05/11/the-pitfalls-of-test-driven-development/






* Please note, with this statement I am not advocating stagnation, and not saying that old-boys like myself are superior, however, TDD appears to me to dismiss any other way of working, to a fault and in my opinion its own ultimate flaw is itself, test your development, but don't drive your development with the test, you will seriously only be putting the cart before the horse.