TDD – a better option for developers with ADD

So I’m back on the unit testing kick again.  In my defense, I do spend an awful lot of time thinking about them – either feeling guilty about not writing them, or thinking about them as I code them, then (optimistically making it sound like I write tests first) or thinking about the testability of a particular piece of code as I write it.  They are dear to my heart, in a strange kind of way.  Part of me loathes them – being a pale approximations of actual applications behaviour,  and the rest of me has only ever found them useful.  Either proving my code, having decisions I (or those before me) have made confirmed to be conscious or driving my design.  And that’s what I want to talk about.  Test Driven Development.

I’m fairly convinced that most people don’t have a firm grip on what Test Driven Development is.  Before we begin properly, I’d like to mention that I have actually read the book by Kent Beck.  Including the code examples!

Now that my credentials are clearly proven and sufficient, I’d like to start by saying that test-first and test-driven development are not the same thing. That’s where most people get it wrong. Both are Good Things, but I favour test-driven development for a couple of significant reasons.

Read more of this post

Scrum is boring.

Well, more specifically, planning meetings are boring.  A colleague pointed this out to me and it was indeed a big shock to me.  I think I must have been too busy sleeping through the planning meetings to notice it for myself.  It’s a technique I perfected working my previous menial-labour-for-hire job; being able to appear like a functioning person whilst actually being sound asleep. The empty coffee cup in front of me is just for show.

But why is planning so boring?  The same colleague postulated that surely it should be exciting, taking a fresh look at all the wonderful new work we, as a team, are about to embark upon.  Surely this is where our Scrum happiness sourced – this is a meeting all about anticipation. Google is very happy to produce results which suggest that happiness is derived from the anticipation, not the event proper. And yet the fact remains – every single person I talk to about having their planning meeting has the same, resigned tone in their voice. Oh no, it’s planning day again.

So now I suppose I should be asking the really probing questions – what, specifically, makes the planning meeting a less pleasant alternative to a tooth extraction? What makes it worse than other meetings? (which, granted, aren’t exciting, just merely irritating) The following presumptions are based on my own experiences, and your mileage may vary.

Read more of this post

Software is a Total Mindset

Like every other team sport, software requires that everyone is pulling in the same direction.  I know, I’m shocked at the deep and original thinking that went into that one, too.  But oddly enough, it’s something that in my short and sheltered experience, that’s really quite difficult to achieve.  The more people in a given team, the harder it becomes.  Once again, no real surprises there.  But it’s something that is usually not outwardly stated.  Agile teams are usually recommended to be kept small, but the reasoning behind that is usually restricted to factorial communication network explosions.

But it’s more than that, isn’t it?  Getting software developers to all work together, try as we might, is actually a bit like herding cats.  A quote which I like to trot out every so often is “An Engineer without a problem to solve, will readily create one”.  Though I’d like to make a slight adjustment to that; An Engineer who’s bored of solving a problem will readily move on to something more interesting.  So what if a particular team is bored of solving the problem that the business has told them is the most important to it?

Read more of this post

Talking for the sake of it

Software Engineering is a group activity.  As part of this, I like to talk about the work I’m doing.  It can spark conversations about how I’m implementing a particular piece of work or even self-illuminate.  As part of that, I have a bit of a habit of talking about my work quite often.  This is especially true in my current team where I still feel like I’m quite new (as I’ve only been in it about nine months, with a five month break in the middle).  I’m sure we all agree in theory that communicating with some other person, whom we presumably consider to have reasonable opinions on such matters, is useful.  But in practice, it seems to be more difficult than that and interacting with the soft and squishy parts of software development tends to result in http-like results.  <gratuitous_geek_joke>269, 307, 413 and on particularly bad days 418.  It is almost uncommon to get a 200 straight away</gratuitous_geek_joke>  Maybe that’s unfair – the guys I work with always try their best to be accommodating, but they do want to get their work done too…

I haven’t yet formed a complete opinion on talking about my work.  It’s quite possibly something that, sigh, doesn’t have a hard and fast rule.  Sometimes, like I did this week, I needed to explain what I had seen to someone else, such that I could be certain that my levels of sanity were unchanged from normal, for a given value of normal.  And sometimes, I want to vent my frustration at the stupid code and why it’s not playing ball.  It’s not exactly asking for help, but that’s the intent that is often assumed.  And when someone sits down to pair with me, I rarely push them away.

Read more of this post

The Usual Suspects

I’ve often looked at the contents of my home directory and sighed.  I’m very good at sighing.  I have many half-started and even some half-finished projects on the go.  I’ve previously described myself as ADD when it comes to programming projects – I’m very good at starting, but find it difficult to get to version 1.0.

I can count 10 repositories on this computer, which only accounts for around the last year, give or take a couple of long-running projects which have had enough activity during that time to make it on here.  There is a raytracer (in two languages), a C compiler (well, most of a C preprocessor so far), a website and catalogue program for a family member’s business, a Tetris clone, a Serial Terminal, Personal Kanban web app and a copy of the gtkterm repository, along with a couple of work-related items.

So why is it that I have so many?  Clearly I run out of drive, but is it a problem?  I hear of other people who have got their main project that they work on day after day.  In the extreme case, there is Linus Torvalds working on the Kernel, but there are less notable examples, such as Minecraft, which was originally developed by just one person.  Is it just that these people have one main project that continues to hold their attention, along with a smattering of un-noteworthy forays?  I’d like to think so.

Read more of this post