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.

Virgin Media : Poor Internet Speed Misery

You know that moment in Misery where Annie (played by the excellent Kathy Bates) raises the lump hammer to Paul (James Caan's) ankles?  That hopeless moment, where you know what's coming, and she's determined this is the best, and he's helpless to change things....

Yeah, his feeling at that moment is the same feeling I get whenever I try to solve my service problems with Virgin Media.  I've tried in the phone centre, they either won't talk to me, or deny I'm an account holder - the account being in my wifes name, but I'm a registered up user of the account etc etc.... Or they simply deny there's an issue....

"I can ping you now sir"....

Really, a few ICMP packets get through and you think it's a-okay do you?

Or I get told, reboot your superhub...

Or variously asked "are you on wifi or wired"... It makes no difference when the speed recorded by either is less than 2mbits!!!

And I've just been told in a reply on twitter "If you have been told about an Area Issue were you given an estimate as to when the issue will be resolved"... I've not been told anything about any area issues, nothing, nada, zip.

Therefore I'm still not best pleased, remember I went down from paying through the nose for Vivid200, as I never ever got anywhere near 200mbits/sec ever.  I did record regular speeds of around 34 to 50 mbits, therefore the safer, more cost effective option was to pay for Vivid50.  Simple, see, simple logical option, if they can't meet the expectations of their own service, play the system at it's own game.

However, it seems that in reality, Vivid200 should be labelled Vivid50, and Vivid50 itself should be called Vivid1... Because breaking the 1mbit/sec barrier seems to be too much for it.

I have therefore decided to create something anyone can interpret, a chart... Managers love charts... People can interpret charts....

This chart is going to record the internet speed (recorded from my linux server, on my wired Cat5e directly to my 1gigabit router, which is directly wired to the Virgin Media Superhub 2 set into Modem Mode).  No wifi, no confusion, no bull, and my router has pfSense, so I can see there's no shenanigans, just the pure speed through put.

I'm going to record the speed with "speedtest-cli", which you can see yourself how to install here.

I will collect my results by running a python script, which runs the speed test and outputs the time, the upload and finally the download speed into a CSV file.

Find the source on my github... 

import subprocess

import time

from time import gmtime, strftime

# Open a simple text file for writing the result

resultFile = open("speedtest.txt", "a+")

while True:

# Header text & placeholders for our result

print ("Starting Test...")

timeStr = strftime("%Y-%m-%d %H:%M:%S", gmtime())

downloadSpeed = ""

uploadSpeed = ""

# Action the process to test our speed

# capturing it's output

result = subprocess.run(['speedtest-cli'], stdout=subprocess.PIPE)

# Process the output into text & split the text

# at each new line character

btext = result.stdout

text = btext.decode('ascii')

lines = text.split("\n")

# For each line, check whether it is upload

# or download

for line in lines:

# For Download, take a split against space

# and the middle value is the speed

if line.startswith('Download: '):

speedParts = line.split(" ")

if len(speedParts) == 3:

downloadSpeed = speedParts[1]

# Likewise for upload, the middle  value is

# the tested speed

elif line.startswith('Upload: '):

speedParts = line.split(" ")

if len(speedParts) == 3:

uploadSpeed = speedParts[1]

# Print our output result as a CSV

print (timeStr + "," + downloadSpeed + "," + uploadSpeed)

# Write the result to a file also

resultFile.write (timeStr + "," + downloadSpeed + "," + uploadSpeed + "\r\n")

resultFile.flush()

# Count down until the next test time

count = 10

while count > 0:

# The line is repeated, so we use the end=""

# and a return carriage to print over and over

print ("\rTime until next test " + str(count) + " seconds", end="")

time.sleep(1)

count = count - 1

# Print a new line to stop the next text appending

# on the time count down line

print()

I will then load this CSV file into a spread sheet and create a chart, here's one I created earlier with 5 test data points.

The blue-line is where I'm most concerned, that is my download speed, as you can see within three minutes I had quite a difference, ranging from a high of 2.24 mbit, to a low of 1.23 mbit.  Upload speed has been more consistent giving a measly 3.5 to 4.0 ish.

I already know where VirginMedia will take the conversation, they will talk about "based on average peak time download performance".  However, I want to immediately counter that their speed information states that speeds are based around "Movie based on 4.1GB file size a single user and wired connection", and this chart is provided.... 

Average download speed at peak time (8pm to 10pm) the time's I have mostly messaged to them on twitter are sub 1mbps... Right now at just before 11am they are still reporting as extremely low.  And yes, this server is the ONLY machine on in the house, the wifi is off, the other wire into this hub removed, there is one wire to one machine and one wire to their Superhub...

And yes, I can get 1gbit disk to disk over NFS on this hub, the wires to and from it to the machines are perfect, and I've also swapped the wire to the superhub.

I'm going to run this for a few days, and see what speeds we get in the dead of night, or early mornings, and see if there is a pattern.  I have known for years Virgin will throttle speeds, however, their table of speeds is labelled "Average", one can only believe we're on the lowest ebb of that bell curve, and I am not a happy customer.

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.