Uncategorized

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.

“OH HAI, THE 1950s CALLED, THEY WANT THEIR IDEAS ABOUT HOW TO WORK BACK”

(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:

Niecee
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.