Digital Detox

I read Documentally’s news blog post with a twinge of jealousy today: Rebalancing my relationship with technology. I’d read about the Punkt phone in his newsletter (which you should subscribe to, it’s very good) and my mouse pointer hovered over the buy button the Punkt website…

I would love to do this, but some things stop me. £230 is a lot for a ‘dumb’ phone, when the OnePlus 3 (which I own) is £329 and the OnePlus 2 is £239, sure I could use an old Nokia like Christian suggests, but where’s the fun in that? New tech drives me to try new things. But this is new tech driving me to do … nothing. Well, it’s not really “nothing” it’s just something else. Look at trees, skies, plants, be engaged in the moment. Be engaged in the people around me. Be engaged.

Mostly all of my communications during the day are text based. The only people I actually speak to on my phone are my mum and, occasionally, my wife (I don’t mean I only occasionally speak to my wife, just that we WhatsApp mostly and the odd call for clarity or high bandwidth). Most communication is fairly brief “Check this out: [youtubeurl]”, “See you later”, “Can you forward me the thing we spoke about?”.

Some of it is international – I work with a team in India, there’s a lot of text-based comms (email, slack) but also a daily chat.

So, without buying a Punkt (or resorting to an old Nokia) can I digital detox? Can I commit to only using the data functions of my phone when on the wifi?

Would it really hurt to call people more? Maybe I’ll enjoy it.


Sunday Link Dump!

Sunday Link Dump!

First up, is this most excellent post from Joshua Arnold over at Black Swan Farming. Called “Standing Up Doesn’t Scale” it’s a comment on “false friends and local maxima”, that is having standups and kanban boards, without actually knowing why you’re doing it and what problem you’re trying to solve. Too many organisations are like this and it’s frustrating for everyone involved -especially those hired to help with the transition in the first place.

#noEstimates is a torrid love affair of biblical proportions and, by biblical, I mean magic pregnancies! Anyway, I liked this post from Glen B. Alleman over at Herding Cats because he’s, again, poking a stick at fanatic dogmatism. I don’t agree with everything he says, but it’s a good speech from the prosecution. The Problem With #Noestimates

One for the people people here. Hiring is one of the most important things you have to do in a business – no, seriously, it is. Hiring the wrong people (or, the right people for the wrong role) is hugely damaging to your company. This post talks about what it takes to hire hire an engineering manager. From Calille Fournier at Elided Branches, Hiring Engineering Managers: Screening for Potential

In response to Forget Productivity by Jim Highsmith

In response to Forget Productivity by Jim Highsmith

(In response to Forget Productivity by Jim Highsmith and first posted as a comment to that article. I thought it worth repeating on my own blog.)

More of this “programmers are artists/crafters/code artisans — they should be treated like special snowflakes!” rhetoric — it drives me nuts!

I agree that writing code is an art and a craft. It is not like building a wall or working on a production line — it doesn’t have defined processes and actions like those.

However, posts like this ignore that simple fact that most business are in business to make money, in order to do that, businesses need to have *some* idea of when things will be delivered, or how much of a thing will be delivered by a certain date. This could be to support a marketing initiative, or because they need to order some hardware or other with a lead time that cannot be changed (and, having this hardware in inventory and not in use is waste), or simply because that’s the date that it needs to go to market.

So, let’s take the two metrics suggested as superior to “productivity” (whatever productivity is — is it story points?).

Value: Yes, let’s do the highest value items first. Let’s generate as much value as possible. “Which items are most valuable?” “How they hell should I know, we haven’t made or deployed it yet — we’ve done some focus groups and monitored our competitors, but we don’t really have a clear idea of which is the most valuable, so we’re guessing”. You’re just passing the whole “productivity” issue up the line, let someone else decide what we should build based on their own set of made up metrics and measurements.

Cycle time: Yes, this would be absolutely wonderful if we could measure everything by cycle time, but when you’re elbows deep in making a product, do you stop to care about how “big” (or whatever sized you use for a story) is to be able to compare it to other size stories to understand cycle time? (The premise being that, to gauge cycle time accurately, your work-items should be similarly sized) then you’re just back to estimating productivity again, surely? “Well, this is a small/8/dog sized story and we have usually done those end-to-end in a week/month/quarter, so expect this delivered around …”

There is no good answer to any of this. Forever more, we’re going to be working with unknown unknowns, sketchy, made up requirements and changing technical and business landscapes. I agree that wasting too much effort on measuring productivity is waste, but claiming you should measure in value or cycle time because it’s a better measure is misleading.

If I told you that a wall I have built previously was 14 bananas high and 82 bananas wide, you could probably build me a similar size wall. Whether it’s bananas, penguins, story points or inches, we’re only every using them relatively to gauge what might be based on what was — which is all estimating really is, no matter what method you use.

Sorry, It’s Company Policy.

Possibly the most frustrating, emotionally bankrupt and redundant four words you’ll ever hear in the workplace.

I recently had the displeasure of hearing these words. Not, thankfully, said to me however. What made the whole situation worse was the person who uttered this charming sentence had allowed the policy to be bent only the day before.

“Policy” as described by the OED is:

a course or principle of action adopted or proposed by an organization or individual

“Policy” as described by most companies is:

a rule which we can use to bash you over the head in order that you do our bidding.

Policies are usually created as a sledge-hammer answer to a walnut sized problem. In the past, someone (or many someones) have done something which was bad for the company (or, another company) and this has resulted in their being a policy.

As a general rule, humans work for, or with you. As we all know, each human is a unique a beautiful snow flake. Trying to apply a “policy” to govern the actions of behaviours of your workforce as a whole is pointless and demeaning. Take the time to understand the people who work with you instead of putting your fingers in your ears and going “lalalalcompanypolicylalala”.

The only policy you should have is one of common sense and decency. Treat your staff like the people that they are, not the resources that Taylorism would have them be.


(Also, beginning the statement with “sorry” is also disingenuous – if you really were sorry, you wouldn’t have to say it in the first place…)

Does It Need to Be Said? Don’t Lie.

I recently watched Liz Keoghs “Let’s be honest…” YouTube that she did at the goto; conference. It was a fun and engaging talk, but I was frustrated and, frankly, surprised that there are companies or individuals that need to be told don’t lie. She used examples from previous positions to illustrate her many points, but there were two that stuck out for me (well, most of the points were salient, but these were the two that had the most impact on me).

The first was her statement that we’re no longer finding better ways to build software, we already know how to build software, we’re finding better ways to discover. Liz had the sentence from the agile manifesto on screen when she said this. Now, while I’m still not entirely convinced that a nearly 12 year old document is as valid now as it was when it was written, I believe that, if any of it is true, then that be is – we’re still finding ways to build better software. The constant evolution of our industry is testament to that. Don’t get me wrong, we’re much better at it now than we’ve ever been, but it would be arrogant to announce that we’ve reached the pinnacle of software development. Even if you’re a super-duper, high perfoming, cross-functional team, if you stop trying to improve, you’ll rot from the inside out.

This doesn’t mean that the rest of Liz’s statement is wrong, we’re also finding better ways to discover what our software should do, the fact that BDD is now more popular than ever means we’re trying harder to find out more about our products, not just how we build them.

The other thing Liz said in her talk was about user stories and how, we’re lying if they’re not actual stories for the user. Gojko said the same thing in his angry Monday blog post and it got me to thinking. Gojkos was a better example in that “As a user, I want to register, so I can use the site.” is probably a lie – no user ever wants to registers, it’s a necessary evil we perpetrate over and over again in order to provide some persistence for the users’ experience – however, we have the story because we think we should. It might be better phrased as “As marketing, I want the user to register, so I can send them email” or similar (Gokjo has other examples).

But, for me this misses the point. The stories are a catalyst for conversation, what they actually say should really be irrelevant. They could say “Login” and just a a placeholder. This will force the people involved to talk about what that means and how they should build it. It’s this conversation that needs the to be focussed and honest, not the story card. It also needs people to think differently about how they go about the discovery process and this, for me at least, is key to what both Liz and Gojko are saying.

I believe that, for the most part, we lie without knowing we’re lying (is that even lying?). We make verbal assertions about thing X to move us passed that to get to thing Y. The danger then, is that you don’t revisit thing X to work out whether or not your assumption was correct. Do the quickest, most expeditious thing to move you from nothing to something in order to find out if you were right, if you spend too long worrying about whether your story card says the right thing you’re going to miss out. After all, it’s all about the users, get it in front of them and let them tell if you’re lying.

Finally, I believe in starting from a position of trust, this means that I cannot entertain the idea that people are lying until it’s proven they are. The people around me (and, hopefully, you) don’t lie. They’re professionals and adults and shouldn’t lie. If we ever find ourselves in a position where we have to point this fact out at a conference, we’ve got much bigger, darker problems than what we write on story cards.

Is Legacy Code Actually Technical Debt?

Technical debt can come in many forms, but is your legacy codebase really technical debt? If you make decisions based on the knowledge you have at the time, can the problems these decisions cause later (either weeks, months or years later) be called technical debt? I don’t believe so. If we’re going to use the analogy of taking on a financial burden, then you wouldn’t be able to take on a financial debt without knowing about it and, if you somehow did manage to do that – would you even be responsible for the debt (if we think about how those who took on a credit card with PPI are now claiming all that money back)?

There is plenty of discussion about what technical debt it on the internet. For example,Wikipedia sez:

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Martin Fowler describes it as:

 In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.

My question is then, if you write code, or architect an app to the best of your ability, with the best code you can – no cutting corners, or missing tests – is it technical debt when you come back to the code months (or years) later, and it requires huge refactoring because it’s out of date?

I would suggest that no, it isn’t.

If it’s part of your system that hasn’t required work since you wrote it, then it’s simply legacy code. Technical debt is smelly code that you create deliberately. That is, you need to cut corners, or hack stuff, to get your code out of the door quickly. If you know you’re not writing the best code or architecting your application correctly, but you do it anyway, that is technical debt.

Accruing Interest

The thing about technical debt, like real debt, is that over time, intrest accrues. Let’s say that on day one, you deliberately create some smelly code in order to get something deployed quickly. You decide to fix it the following week. A week later, it takes you two days to write the code correctly.

Let’s say, however, that you couldn’t fix it a week later – something more important came up – instead, you could only fix it a month later. Now, because the codebase has moved on – other devs have committed code, you’ve committed code etc etc – what would have taken you two days to fix a week after you wrote it, might now take you five days to fix (assuming that for every week, the code gets complex enough to add another day to fix it). This means, your interest on this technical debt is roughly one day a week. So, if you leave technical debt for months, it’ll take much, much longer to fix and, depending on your position, every new dev you add to your team will compound that interest, until it spirals out of control and you end up declaring bankruptcy and re-writing the codebase from scratch.

Sound familiar? Might as well do it properly the first time round…

The Foundations of a High Performing Software Development Team

Get Busy by Dusk Photography
Ants are high performing. Yes they are. Can you lift 100 times your own body weight? No. Get Busy by Dusk Photography

(Article first published as The Foundations of a High Performing Software Development Team on Technorati.)

Building high-performing teams requires a foundation of core values in order to channel the traits and skills needed to be successful. Sounds like marketing blurb right?

Let’s break it down into manageable chunks.

What is a high performing team? The answer, I suspect, will differ depending on who you ask, but when asked of a team of software engineers or developers, they’ll tell you it’s a team that can do anything, do it quickly and do it right, while maintaining rhythm and a steady growth of both the team and it’s individuals. The question is, how do you build this team? Firstly, you need the right people. Hand-pick your teams, or don’t – it’s up to you. Great success can be head with constructing teams of star players as well as having teams of volunteers. After that, it’s about coaching the team to performance and that needs to start with core values.

These values should contain the following at least; respect, trust, openness, focus and commitment. If you get your team to help craft these values, they may come up with a few more. Make sure the team understands, or comes to an agreement on what each of these mean (focus is a good one, what does that mean? Can you have focus if you’re having fun?).

With the foundation in place, the skills and traits build on top of that. Depending on your team these will differ also, but some traits will always be there; the team will be able to self-organize, they’ll be totally committed, an unshakable belief in themselves and what they can do, they’ll be responsible and own their own problems, they’ll be motivated and engaged.

With the foundations in place and the traits emerging, a high performing team will emerge, they’ll get stuff done, the right stuff and they’ll do it with pride, skill and a devotion to quality.

‘Get Busy’ Photo by dusk-photography

The 8.9 earthquake in Japan sucks

My thoughts are with the people of Japan who, right now, are under an onslaught of enormous proportions from mother nature. First an earthquake to fuck shit up, then, if that’s not enough, a tsunami to mop up anyone lucky enough to have survived the initial catastrophe.

Nice one mother nature, sometimes you can be a bitch.

I saw a tweet today that said:

Hellicopter flying over me on Ocean Blvd urging people to move away from the water but herds of people still coming hoping to see a #tsunami
11/03/2011 16:52

And it reminded me of the sci-fi book, The Moon is a Harsh Mistress. Where a penal colony on the moon starts a revolution and demands independence from earth. The only weapon they have is a giant catapult used for firing barges of grain at the earth. They repurpose it to throw rocks. These impacts are worked out by a computer, so they know where they’re going to hit. They inform the people of earth when and where these rocks will hit (mostly government buildings and military installations) instead of people moving AWAY from the impact zones, they move toward them instead, to get a better view of the show … and end up dead.

Don’t be stupid people, stay away from the danger.

Goodbye Servelocity…

I used to have an account with Servelocity. They were fairly cheap, but their implementation of Plesk was shockingly buggy and their customer service was non-existent, even if you used the premium support line. I did kind of feel sorry for the staff working there as they even seemed to give up using the forum after a while as they would just get trolled.

Today, I received this email and it’s testament to everything that is wrong with a webhost that has this on their support page: As the majority of our customer base are highly technically able and in order to provide the most competitive product possible our private servers do not come with support as standard.

Dear Subscriber,

We advise that Servelocity Ltd.  will not be able to offer services to you after the end of March 2011.

We thank you for your support in the past.

Yours Faithfully,
Servelocity Ltd.

So long Servelocity.