Communication is half-duplex

September 20, 2012 Leave a comment

Communication.  It’s something that we technical folk are traditionally un-awesome at. Sure, we can do things like read Strunk and White to make our blog-writing better, which fits nicely into our world view. Those two guys have provided a succinct set of technical rules, with examples and counter examples, on how to write well england. Which is great. The least effective method for communication is now a solved problem. Hurray. Blogs, however are clearly a better method for communicating things, well ok, slightly better – because they at least have a comments section where, given enough eyeballs, all misunderstandings become shallow. Or you eventually get to arguing about Why Hitler Was Bad.

So why is Documentation hallowed as so necessary and important, if reading it (often far removed in time, space or both from the original author) is such a terrible way to gain understanding? Sometimes I read documentation. But mostly I only read a small portion of it. In almost all circumstances, I’ll go and talk to an actual person who I know to have been in that portion of the code. The document I have referenced most in the current company I work for is the definition of a protocol. Not a design document. Not a UML diagram suggesting the structure of the code base. A protocol. And I look at that the most because I periodically have to pick apart a stream of it to figure out where a bug is hiding.

Read more of this post

Filed under Uncategorized

TDD – a better option for developers with ADD

September 8, 2012 3 Comments

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

Filed under Uncategorized Tagged with ,

Scrum is boring.

September 4, 2012 2 Comments

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

Filed under Uncategorized Tagged with , ,

Software is a Total Mindset

August 25, 2012 2 Comments

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

Filed under Uncategorized

Talking for the sake of it

August 18, 2012 2 Comments

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

Filed under Uncategorized

← Older posts

Newer posts →