(Unit-)Testing State of Mind

My mind has been steeped deep in the quagmire of automated testing for the past few days. If ever there were an area of software development where I wished for a silver bullet that I could just load and fire…

I’ve gone from a job where testing was predominantly a lightly automated activity, to a job where large swaths of the testing effort are automated to a high degree. I definitely prefer the latter in principle, if only there were a definitive book of recipes and best-practices to follow.

I enjoyed watching the Pluralsight video on Code Testability; it has the best explanation of what makes testing code hard that I’ve ever seen. The side-by-side examples in which he shows how using dependency injection increased what he calls the “sphere of influence” (or the directly testable surface) of the code was an A-Ha moment for its sheer clarity.

And another video that has gotten lost in the blur in my memory made a great point regarding keeping tests descriptive and linear. Unit Tests are easy to write because they do not branch or loop. They test one thing well at a time, and as a result feel more reliable; being able to read and trivially understand a test is a major strength.

And yet… it bothers me when a lot of the hands-on examples in videos still show how to test an “ArgumentException” type gets thrown. I blogged about exceptions what feels like an eternity ago (Exceptions – 3 specifically), and ArgumentExceptions should not be caught; they aren’t for code to deal with, they are for code to try and avoid at all cost. So why test them? Like… ever?

There are plenty of proto-guides on (unit-)testing best practices, but few if any get beyond the obvious: isolate your test cases, pick structured names, be wary of mocking, test one thing only. But that still doesn’t really give any guidance on what is worth testing. Writing tests is easy enough, writing the right tests, and no more than necessary, is the hard part.

Are there resources out there I haven’t found yet?

2015-06-08 - Header

On Communication

“We need more communication!”

Odds are, if you’re working in any organisation that isn’t small enough for everyone to know everyone, this is a complaint you’ll have heard at least once. Communication is hard. Everyone knows this.

Odds are, once you heard this complaint, you did something about it because you’re trying to be an effective manager and you want everyone to be informed… you added extra presentations, a regular newsletter, you wander the floor and talk to people.

And then the next time you ask, communication is still touted as the biggest problem everyone faces.

The bad news first; communication is always the biggest problem you’ll face in your organisation. And once you address it, communication will still be the biggest problem you face. Always.

The good news; you’ve probably misunderstood what people are trying to tell you. There is one very deceptive word in that first phrase. Okay, maybe two, but one in particular that sent you down the wrong path.

What can “more communication” mean?

  1. You don’t talk to us enough.
  2. You don’t talk to us about the right things.
  3. You talk to us too much.

Yes, really. Even that last one. Stick with me

1. You don’t talk to us enough

It is possible your understanding of what your staff and co-workers need to know about is too narrow.

Are the details of the next project a distraction while we are still finishing our current work? Or could advance knowledge let my staff make some smart decisions about laying foundations for the next thing while finishing the current thing? They’ll get annoyed if they never find out in time they could have done something smarter for the company.

Are competitive pressures just going to worry people about their jobs? Or am I missing an opportunity to engage the creative capacity of my staff to innovate us to the top of the pile? It is very dis-empowering to feel like you’re just sitting in coach while your life is in the hands of the pilot alone.

Is it actually better to not say anything when you have nothing worthwhile to say? Silence lets people imagine all kinds of far-fetched reasons for that silence. Sometimes a trivial or obvious update is less harmful than letting a fear of unspoken horrors fester and grow.

Cast a very critical eye over all the things you don’t tell staff and co-workers. Why don’t you?

But…

Even when there is a genuine lack of communication, be careful how you fill that void, or you’ll be back to re-read this post for points 2 and 3 in no time.

2. You don’t talk to us about the right things

So, how about I talk to everyone about the next big project that is coming up, and how I need to negotiate it past the VPs and legal team of the company we are selling it to…

Bzzzzzt, wrong…

Yes, talking about the next big project is a great idea. But your needs and concerns aren’t that of your audience. What possible use could your developers have for knowing you are locking horns with legal over whether the solutions you develop for their specific problem domain will entitle you to ownership of those solutions… *snore*. None of that can possibly help them do their own jobs better.

Figure out what they actually need to know, and tell them that instead. And yes, maybe painting a little context is valuable, but do not turn it into an epic about the heroic way you are fighting through your own obstacles… it may be entertaining if you are a good storyteller, but they’ll resent the time they just lost once they realise they had their own jobs to do. To paraphrase Kathy Sierra, “it isn’t about you, it is about your staff”.

Tell them what the VPs want out of the product so they can tell you whether it is even feasible.

Tell them what is going to be non-negotiable so they can start thinking about solutions early and often.

Tell them how to firewall development of features if you are concerned over legal ramifications down the track.

Make sure the information is pitched so it is relevant to your audience, otherwise it’s not communication, it’ll just be talking and listening. And it’ll be a waste of everybody’s time.

And yes, this takes more effort, because you’ll have to think before you speak.

But sadly, that’s going to be unavoidable.

3. You talk to us too much

You’ve been trying to address the communication problem for a while now. You’ve added meetings, newsletters, presentations and extra face-to-face contact till you simply have no more time left in your day for anything else. You’re telling me that was all the wrong thing to do?

Not necessarily.

You may have started with problem 1 – not enough. And you may have wandered through problem 2 – not the right things. You have addressed both of those and there is still a communications problem. What happened?

Everything that isn’t “1” or “2”, is “3”.

Everything you added that wasn’t addressing one of the first two problems has now contributed to obscuring the real information everyone wanted. You’re talking so much that they cannot tell what is important any more. Or they simply cannot find what they care about in the deluge.

Luckily this is the easiest to fix. But it takes courage.

Trust that you’ve worked out what is important, and then ruthlessly discard what was not.

And yes, it may mean that you need to segment your communication. You may need to write a separate update to your staff, and to your boss, and to PR, and to support, etc. And it will take you extra effort to tailor all these messages. One message may feel more efficient, but when one tree falls in the forest and nobody can agree which one it is, does it really matter how quickly you could write it all down?

When “more” isn’t “more”

And by now you have probably worked out the problem with the opening phrase. “More” implies a quantitative problem. It calls for more of something.

But communication isn’t merely the combined acts of talking and listening. It requires relevance to both parties involved. So “more communication” can be either a quantitative or a qualitative problem; either “more talking” or “more relevance” or “more obvious”.

Here endeth the rant.

Old and New Books

When I left my previous employer, I received a fairly sizeable Amazon gift-card to feed my then-imminent Kindle-habit on my train-ride to my new-job.

I have been making some steady progress through the list of classics that I had never read before. Some, little curious time capsules (“A Passage To India”), others quaint in their stilted morals (“The Age Of Innocence”). But so far most disappointing is the third of “On The Road” that I have read so far. For a book that gets praised so much it doesn’t really stand out to me. Maybe I am reading it at the wrong time though; perhaps it is just old enough not to be directly relevant, but not so old that it is a glimpse into the past. Or maybe I’m just missing the point of it completely.

As I struggle to reduce my reading list, David Mitchell (author of Cloud Atlas) has succeeded in lengthening it significantly.

I went to see him speak during the Sydney Writers Festival with my friend Ken. I wasn’t sure what to expect, because I only knew him from the one book through his writing. He walked onto the stage a little huddled in on himself, and I was fearful of disappointment.

The first question from the interviewer was a clear lead-in to his current book. It sounded like the back-cover-summary rephrased as a pointless question. He repeated what sounded like a fairly rehearsed answer, probably from months of promoting. He apologised for being seriously jet-lagged.

And then he unfurled into what I can only describe as somewhat of a modern-day philosopher, with a slight lanky Cumberbatch-alike appearance, and a British humble shy-ness, with the most thoughtful and poignant answers rolling out of his brain like he was on a script that only he was privy to.

Earlier that day I had attended a session with Alan Cummings on the subject of domestic violence growing up, to promote his new book around that subject. At the end the audience was invited to ask questions, culminating in an aspiring actress making me cringe inwards as she proceeded to solicit acting tips from Alan.

I was braced for the worst when the floor opened for questions to David Mitchell. But I was surprised and delighted by the thoughtful questions on the meaning of his works, and humanity, and the symbolism of birds. And he’d take a few moments of silence and then again produce an answer that’d fill script-writers with envy. Maybe everyone in the audience was a plant? And I feel confident that even faced with the dullest imaginable questions he’d have found a deeper or more humorous way to look at them and keep us entertained.

So, now I have The Bone Clocks to look forward to reading next.

I’m almost ready to ditch “On The Road” for it, if not for the fact that I only once before abandoned a book without finishing it. I am too stubborn to give up.

Cannibals and Pirate Lords

I feel guilty for doing nothing.

On my weekends, I spend a lot of my time in books and television. I let it wash over me, but I feel like I should be doing something more constructive with the time.

I feel like I should be working on something, a new language, a new project, a new idea. Or being out with people, somewhere, anywhere.

I guess it’s a struggle between the introvert and extrovert.

On weekends, the introvert tends to win more often than not. I save the extrovert for Monday through Friday it seems, maybe because he is so damned useful at work?

So, this weekend, right now as a matter-of-fact, I am watching some Hannibal… because I can.

And I have a box-set of Pirates of the Caribbean waiting to be studied in detail… because I need to learn to be a better pirate for work-related reasons. Also D&D, but “for work” sounds more interesting and mysterious so that’s what I’m going to label it.

I haven’t quite worked out whether this means I need to let my hair grow or if I need to buy a bandanna and a hat.

Time will tell.

Hands Passing Baton at Sporting Event

Smooth Transitions

As of Monday I am once again in charge of a team.

Exactly the same day that I had my 3-Month review in the afternoon. I felt fairly confident my review was going to be okay. I’ve definitely set myself a high bar to beat for the 6-Month review.

Today, my second day, was the day for one-on-ones with everyone. Also, interviewing a Product Manager. Also, a one-on-one with the CEO. Only lunch wasn’t technically a meeting, even though it kinda is.

It was great to talk with everybody and for them to be so positive and enthusiastic about the changing of the guard. It didn’t seem to take anyone by surprise, which is kinda surprising in its own right. If this goes pear-shaped it won’t be for lack of support from my team. I’m sure my previous two years of juggling/cat-herding/crisis-management will serve me well.

And then ending the day catching up with the CEO (a standard with all new employees, I believe)… Congratulations on getting the team lead so soon in my tenure. Emphasising how important the team’s work is to the success of the organisation (no pressure… really). And an opportunity to ask some questions.

And yet again… all ’round, so much support and enthusiasm from everyone in the company.

So…
What’s Next?

pluralsight-logo-orange-500x155-v1

We All Should Learn a Thing or Two

I have been learning like a meth-crazed hamster.

It started about a month ago when I got a Pluralsight subscription at work; I had previously only been exposed to http://www.pluralsight.com in my capacity as manager with team-members that would like a subscription. It is the cheapest yet most valuable training budget you could ever spend on yourself or any subordinates.

Sure, there are bad courses as well. But overall my impression of the 30 I have done so far is that there’s more good than bad. And for the occasional slow speaker, there is an awesome speed control under the gear-wheel of their video player so you can go up to double-speed with anti-squirrel-compensation technology.

I like learning new tech topics by getting shown through an introduction. It’s not that I don’t like reading tech manuals and API documentation, but I have found that far too often when techies start writing it sprawls too broadly and leaves me completely clueless as to what is essential and what are the optional extras of a new technology. I think the written word especially is prone to a feeling that we must be comprehensive at all cost, when most of the time a new entrant just wants a gentle and limited introduction.

As a result I have found the “??? Fundamentals” courses on Pluralsight immensely helpful to broaden my horizons. But I would even go so far as to suggest that managers, whether technical or not, could probably benefit from these fundamentals courses. For the non-technical manager you may have to gloss over some of the techier bits, but courses like Jira Fundamentals or Agile Fundamentals are a great way to follow along with what your developers are talking about.

And another set of courses I have found especially helpful are the “??? Best Practices” ones. Even in technologies I am moderately familiar with a video on best-practices can be a great way to level-up to where the industry is already at. Javascript, Python and Angular, here I come!

So, I strongly suggest you go out there now, get a free 10-day trial, and give it a shot.

You might be as pleasantly surprised as I was.

Time-frames and Velocity

Next Monday I have a meeting with my team lead at 2:30pm. It’ll be the 3-month review mark in my new job, which still feels insane to me.

I blame the velocity of the release cycle at Campaign Monitor. I came from an organisation where releases are carefully planned and executed around a 6-month release cycle to coördinate deployments with numerous external parties each with their own IT department. I came from an organisation that rightfully was cautious about the idea of Agile and where it might apply. And I’ve jumped straight into the middle of an Agile maelström.

We have a release window every fortnight (or more… sometimes weekly). Sometimes that’s just an internal deployment. Sometimes that’s a production deployment with functionality still turned off by default. But it is a deployment. An opportunity for code to be exercised, reviewed in the wild, and feedback to come back. It leads to a much more experimental approach, and a preparedness to be wrong because at worst it will get fixed in another fortnight.

Which makes this morning all the more dazzling in its sudden slow-ness.

There is an issue in some of the development environments. And I’m sure it’ll be fixed by lunch, but in the face of the otherwise blistering speed, half a day without access suddenly feels like the Biggest Tragedy in the History of the Universe.

So in my helplessness I am studying on Pluralsight.

I should post about Pluralsight, because it is more awesome than I ever suspected. In the past month I have completed 30 courses on a variety of topics. It’s the quickest way to get into a new unfamiliar technology for me, and I feel so much smarter already. Just wait until I finish the full catalogue… only 3970 more to go!

Back to Angular.js for me now.

And then lunch with some ex-colleagues. Yes, I am abandoning the chefs. “Chicken and sweetcorn soup” the internal menu proclaims. I’ll be back in time for cookies though.

Etappe Spay bis Koblenz; betrachtet und fotografiert vom Aussichtspunkt (Schutzhütte) des Rheinsteig Wanderweg zwischen Osterspai und Braubach. 

"Rhein in Flammen" (Rhine in Flames) is the name of five different firework displays along the river Rhine in Germany. The displays take place annually, at various locations along the river. (Source: Wikipedia). 
Here you can see the firework displays between the locations Spay and Koblenz (the biggest one).

Ships Through the Night

Last week I participated in a Ship-It event at work.

The concept: the engineering staff form teams around concepts and ideas. Innovations that have been on peoples’ minds. Things that they think might be useful. Wow an audience.

Then at 2pm on Thursday, coding starts, and at 2pm on Friday, pencils down.

The aim is to put together a presentation or demo to an audience of everyone in the company. After all the presentations we vote. After the vote, one team wins the esteem of having won, their names on a trophy to be put somewhere in the office, and a custom-designed-one-run-only t-shirt.

Most of us are in it for the t-shirt… we have some kick-ass designers in our company.

The team I was part of started the event with a great idea for an improvement to some internal tooling. It was never going to win because it doesn’t cater to a broad enough audience, but it will make our own lives easier.

First lesson: 24 hours is not a lot of time.

We took some time designing a solution prior to the event. We had a fairly good idea of all the moving parts. Some databases, a message queue, some background processes and a Web UI. As I type that list up, I’m already wondering what kind of crack we were smoking to think it’d fit. But it’s good to be ambitious. I love hard problems.

By 6pm though it was time for dinner. Some of the chefs had stayed behind to make us something they called “chips”, but which so far surpassed the food item I have come to associate with that label we might as well pretend it was called “caviar” instead.

It didn’t feel like we had made anywhere near enough progress, and the day was getting late.

By 9pm, the team was starting to itch to go home and get some sleep. I foolishly stayed till about 10:30pm thinking I might make some more progress through the night, but my environment was exhibiting issues I couldn’t solve with a tired brain by myself.

Second lesson: stay or stay-not.

I probably should have headed home earlier than I did. A good nights’ sleep is a great way to restore productivity and get a fresh perspective on all the problems from the previous night. I guess this is why working weeks have nights at home scattered throughout them as well.

At 10:30pm I briefly considered sleeping in the office somewhere. I had prepared for staying and showering at work the next day. But I also had a kink in my neck and as comfy as the lounges are, I wouldn’t have been able to sit-up straight in the morning. Maybe I could have won a sympathy vote or two with a Hunchback routine, but it didn’t seem worth it.

I got home at about midnight, slept 5 hours, and headed back into the office early to get a head-start on the day. I was back at my desk by 7am feeling much fresher, albeit a little worn out.

If all this sounds exhausting. It is.
But it is also so much fun that it just doesn’t matter.

Third lesson: redefine the problem.

We came to the conclusion early on Friday that although only about half the available time had been spent yet we weren’t going to have a complete working system by 2pm.

So we did the smart thing.
We pivoted.

Rather than trying to produce a full working solution, we started to work on proving the feasibility of as many of the parts of the full solution as possible. We proved a migration path. We proved throughput. We proved the result we were aiming for.

And then we presented our findings with a demo of a Web UI over some batch-processed data rather than the live feed we would have liked to have had.

Fourth lesson: 24 hours is more time than you can imagine.

And then I presented for my team. Did an accidental mike-drop at the end (that’s my story and I’m sticking to it).

And we didn’t win of course. 8 out of 11.

But, what struck me is the amazing things that the teams came up within a mere 24 hours. Some teams stayed far later than I did; perhaps because they didn’t have to travel far to find their own beds. Next time I hope to find the strength to go around the clock myself.

There is something magical about dropping all process and standards, and just racing for the best you can do in a small time with a limited amount of time. It is refreshing. And at the same time it gives a good appreciation why some level of process is necessary.

I shudder to think of the code I wrote over 16 hours actually being the final version. It is atrocious by production standards. But it also worked brilliantly to address a tangible problem.

And then we rest

From what I understand we’ll be doing these every 6 months with fresh ideas to pursue.

It is a brilliant way to blow off steam. To try stupid things in stupid ways. And to work with staff outside of my own direct team. Mix-and-match.

I just need to prepare a palatable place to sleep in the office.
Just a few hours will do.
And I already have an idea.

2015-04-24 - Fireworks