code development

Dear customers, and users,

happy sliced bread

We’re sorry.

Software development is hard. You don’t see everything behind the scenes, so let me give you a few guidelines that I hope we can agree on.

Estimates are called that for a reason. We do our best to figure out how long things will take, we will break tasks into something small enough that we can have some confidence in the number, but we’ve not built this feature in this software before. The only way to know how long something will take is to do it. And then compare the new features we’re working on to that. Given that estimates take effort, and need a lot of detail, estimating an entire system based on an elevator pitch will be about as accurate as guessing the weight of all the grey animals you can see on the horizon. At the moment, I can give you a lower bound if they’re mice, and there’s none hidden, and an upper bound if they’re elephants. If you want more accurate estimates, be prepared to give us more time and detail.

Users don’t understand requirements. You may understand what you do now, and you might have an idea about what you’d like to do, and you will understand whether completed software fits what you need, but written descriptions, visual walkthroughs, and any other design artefacts can only go so far in helping you understand how the software will actually work when you get it. You have ideas about what you want, some more concrete than others, and only some of them actually make sense to build. We’ll help you through the process, but if you can’t answer a question about how something works, it might be because what you’re asking for isn’t clear.

Developers don’t understand requirements either. We need to understand why you’re doing something before we can understand what you want. Your high level requirements that tell us to delete everything on Tuesdays when it’s raining, or that Pogmotians must be able to Fidoodle the Strittles don’t tell us why that’s important, so we will ask questions that you may have to think about hard. We want to build the software that helps you achieve your goals, so help us to understand those, not just the process of what you do.

Sometimes what looks easy is actually hard. But sometimes what looks hard is actually easy. I know it looks like “just” a change to add Google-style “did you mean” to our searches. But Google spent a lot of time and resources to figure out what you mean, and then a lot of effort to make it look easy. Making things look easy can be one of the hardest problems we have to solve.

You are the experts in what you do. If you want software that understands what you do, you need developers you understand what you do. We will work hard to build a relationship, so that we understand your business, because that’s how we write the right software for you. But like any relationship, it will take time. And sometimes we’ll fight, and sometimes we’ll be in sync.

We understand that sometimes you don’t understand. If you can be patient with us with the above, we can be patient with you when you want more detail on what we’re doing and why.

Respect us, we’ll respect you.


Agile papercuts

Nine of diamonds in the rough

I’ve worked on a few projects and I’ve tried many ways to run them. The agile manifesto is a great starting point, and should be in your bookmarks for quick reference. But when you put it into practice, your first thought is the mistakes you made last time, the lessons you learned, so you can do better this time.

So you look at where things failed, and you add a process around it, maybe one of your own, making taking inspiration from others.

For example, you had a big problem with release management in your last project, and git flow is a process for release management, so you try it on for size.

But the planning decisions about when to deliver features, and how the support and feature releases work together are not changed, because it was a release management problem, not a planning problem. So you add more process.


Let’s assume you don’t have time for root cause analysis of everything that caused you pain last time. Just assume everything is causing some pain, but for some things the benefit outweighs the cost.

How do you spot what causes more pain than benefit?

Does your process support the people, or sideline them? Is the documentation useful or mothballed as soon as it is delivered? In other words, are you valuing the things on the right more than the things on the left?

As developers, it is a long battle to get over your ego, and the sunk code fallacy, and learn not to be precious about the code you’ve written because the product you’re delivering can always be improved, and if your code is no longer fit for that product, it should be removed. Celebrate the code you no longer have to maintain.

As tech leads, we can be just as precious of our procedures and our practices, but they can be even more painful that the code. They’re harder to refactor, to measure, to test, because people are less predictable than code, but we need to be willing to identify waste, and identify the pain points so that we can address them, and remove practices if necessary. Measure where you can, but don’t be afraid to be as ruthless with your process as you are with your code. Anything that didn’t add value is weighing you down, and even those small papercuts that sung every time are worth removing.

Whatever you think Agile Is, even if you think Agile Is Dead, don’t forget your process is as much a part of the delivery as the code you produce. Own it. Trim it.

development programming

2011 in review

The stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

A New York City subway train holds 1,200 people. This blog was viewed about 3,700 times in 2011. If it were a NYC subway train, it would take about 3 trips to carry that many people.

Click here to see the complete report.

My most popular post was “Agile Is Dead“, 6 months after it was posted, when I got a big boost from Scandinavia. I don’t know if it was a conference, but I appreciate all the support. I’ve got a few ideas for tech and political blogs in 2012. The tech stuff will stay here, but you’ll be able to follow both on my twitter account ( @craignicol ).

All the best for 2012.

code development lifehacks programming

Agile Is Dead

As a follow up to DDD Scotland 2011, I want to thank everyone who joined in. It’s time to reveal my ulterior motive : I did it all so I could get a blog post 🙂 So thanks to everyone who helped write the Agile Is Dead Mind Map – please feel free to join in the discussion below.

Agile’s been bouncing around in my head for a while given that it’s reached its tenth birthday, and a lot of people are talking Agile, but its not the agile I see in The Agile Manifesto. It’s a silver-bullet snake-oil leech that throws out agile words and terminology but without the guts to actually make agile work. It’s an agile that doesn’t challenge managers or clients, that sticks to deadlines and a list of features, but promises faster, cheaper development.

It doesn’t work.

And don’t call it agile.

Agile works when the customer understands that it’s an interactive process, when there is a functional feedback loop and when the plan is flexible enough to adapt to changes by dropping features or extending deadlines. If you’re not doing that, you’re not agile.

But, you can be successful without being agile, you can do functional testing, you can have a CI server, you can do team priorities, and stand-up meetings. But until you have feedback loops, for each developer, for each feature, and for the project, you’re still playing the old game. It’s an easier route. It’s more comfortable for everyone to have a defined role, for everyone to work from a fixed position. And that’s fine. Just don’t call it agile.

Procedures and tools provide comfort, I know that, you know that. Budgets drive your business, procedures help you budget, and procedures mitigate risk. If it’s signed off, it’s not your fault. But then, someone must have signed off the Ariane 5 too. Would you rather deliver software or paperwork? Is paperwork your protective shield?

If you’re a manager, do you trust your developers? Do you trust them to take decisions, to talk to the client, to deliver professional quality? As a professional developer, that’s the teams I want to work in, and I feel privileged when I get that chance, because those projects always work out smoothest in the end, although they can be the hardest to set up.

If you’ve tried agile and failed, did you really try it? Did you trust the developers to deliver, did you trust your manager to keep things running, did you trust the client to give you the feedback you needed? Did you trust yourself and your team to be honest?

Agile, the word, has been hijacked. It’s dead but still walking. What matters is the philosophy behind it. And it’s not easy. No profession is. Are you a professional or an unskilled cog in an assembly line?

I don’t give easy answers. I wanted to become a developer because the thing that drives me is solving problems. And these aren’t problems that stay solved. HTML 1.0 didn’t solve everything, that’s why we have HTML5. Project management is a problem you need to solve on every project. Every project you’ll learn something new, and you’ll face new challenges. I cannot prescribe a solution, because I don’t know your project, and that’s how agile works. You have to adapt to your surroundings. After all, you’re only human.

If you want to be agile, talk to your team, and don’t let your ego stifle peer reviews, paired programming or feedback sessions. And if anyone does let things get in the way, staple a copy of the Agile Manifesto to their head and blow raspberries at them. Or go and find out about Programmer Anarchy and ask if you or your team could cope with self-directed project management, just like anyone volunteering for open source. If not, why not?

code development programming

DDD Scotland 2011 Open Discussion Sessions

There were 2 great discussions on the alternative track at DDD Scotland this morning, so many thanks to everyone who came.

Below, I’ve posted the two mindmaps we generated. They are in .mm format. I used FreeMind (open source) to generate them.

Professional Development

An open discussion about how developers can be professional inside the constraints of management or environment. Examples of questions for this discussion could be

  • What obstacles do developers feel they face in regards to adoption of technologies and techniques?
  • How have these been overcome?
  • How can productivity and morale be improved or maintained?

Professional Development Mind Map
Professional Development Mind Map (.mm format)”
View “Professional Development” Mind Map online with Mind42

Tidied version

Professional Development - Tidy Mind Map
Professional Development – Tidy Mind Map (.mm format)

Agile Is Dead

Based on a discussion at QCon around the 10th anniversary of Agile and whether or not “Agile” actually means anything anymore. This discussion opens the floor to delegates to chat about the current state of Agile in software development.

Agile is Dead Mind Map

Agile Is Dead Mind Map (.mm format)

View “Agile Is Dead” Mind Map online with

Tidied version

Agile is Dead - Tidy Mind Map

Agile Is Dead – Tidy Mind Map (.mm format)

[EDIT : 10/05/2011]

I’ve created tidier versions of the above mindmaps to try and capture the groupings discussed on the day, as well as the abstract for each session. I’ve also highlighted the starting point of each discussion to make it easier to see what was added over the course of the session. I will leave the raw mind maps too.

[EDIT : 11/05/2011]

I’ve found an online Mind Map viewer to help you explore. Added links to the unedited mind maps above and here:
View “Professional Development” Mind Map online with Mind42
View “Agile Is Dead” Mind Map online with