REST is the best, SOA can go away!


I don’t think that I’ve ever witnessed a worse ‘process’. Even waterfall is preferable to what scrum has become. It’s a total mess, allowing anybody to do anything they want and say that it’s agile. I propose that engineers stop calling scrum agile, because it isn’t. The whole thing is nonsense and it is mostly promoted by people who have no idea what software development is. When it is successful it is in spite of the process, not because of it. It is because of heroes, not because of a solid process that facilitates success. I’m shocked by how gullible the industry is (though I shouldn’t be) — scrum is snake-oil.

Agile: The Truth

I once had a lovely conversation with a very bright senior engineer in New Zealand, John Watson – a guy I like and respect a lot. This was in the early days of agile and he had asked about it, so I spent an evening explaining Extreme Programming to him. He sat and listened carefully, questioning only for clarification, and it was clear that he understood — he got it. After thinking about it for a while he said, “it doesn’t work”.

I had worked on XP projects and they were successful — very successful. I thought about what he said and I assumed that I simply hadn’t explained it properly — the fault was with me, not with him. We talked some more and after a while he said, “it doesn’t work”, but this time, rather than rail against his assertion I asked why?

He said that to follow a process like XP one needs a team of bright, disciplined engineers who communicate effectively and continually. Engineers who will listen to each other with respect and who will give each other the chance to speak and be heard. He said that you need engineers who understand the benefits of process, and who understand the process being used. He then said that these people are elite and that they will probably succeed no matter what process you use — that of course XP is successful, because the people we’re talking about are exceptional — and that if we use XP with normal developers it’ll fail just like all other processes.

What he said we really need is a process that works with normal developers, and XP isn’t it.

I don’t know if he’s right, but I suspect that he is.





The Future


Continual Release

Beck defined stories as the smallest possible unit of value to a business. He showed that continuously delivering incremental enhancements to a product massively reduced risk, and as a side effect enhanced team productivity and product quality and reduced time to market.

Before this we only had ‘requirements’, and the concept wasn’t well understood. We had a product specification, without having identified the concept of a product. We ‘gathered’ these requirements from users, without having identified the concept of  a product owner. We would write these requirements and treat them as if they were correct, despite mountains of evidence to the contrary — human fallibility and the effects of time were completely ignored.

Beck taught us that requirements are rarely correct, complete, or static, and therefore we shouldn’t spend a lot of effort on specifying them.

A product specification is less like an architect’s model of a building, and more like Hollywood’s movie making process. The movie you end up with is rarely anything like the one that was started.

Now that we have reached the level where we have grasped what it is that we are actually doing — we are developing products. And, we know how to do this — reduce risk, increase quality, maintain a business approach to spending decisions, hire the best people available.

But, we still find that despite the revolution Beck inspired, we are still screwed, because the ops department can’t get their head out of their collective rectums long enough to realise that we are no longer developing megalithic stovepipe architectures. We are trying to deliver tiny fragments of software — continually.

What’s the point in having a story that provides business benefit that I can implement in 10 minutes if the bastards who control the metal won’t let me deploy except in 3 month windows?

Either we have over optimised the development process, or the buggers in ops are retarded and need to be fired. Continual Release.

Of course, there are plenty of places where continual release isn’t a possibility — air traffic control, nuclear reactors, pacemakers, but most software isn’t written for these environments. Most software is written in java. Most non-embedded software runs in some variety of corporate IT environment where continuous release isn’t just possible, it’s highly desirable.


Jutifying Metrics

I prefer facts over opinions, so I measure things and use the resulting numbers as evidence. If I tell a team that a new IDE will increase productivity through an increase in quality, then I’m prepared to measure current quality levels and show after the change that an improvement has been achieved without negatively impacting any other significant metrics. I do this because I’m at the level where businesses ask me to provide a cost/benefit analysis of my investment recommendations (and improvement almost always requires an investment of some sort, even if it’s only in the time required to explain things to the team).

I like to measure everything, so that when we make changes we can see the impact. I like to measure each engineer’s commit frequency, their contribution to the codebase in terms of LOC, the number of defects they fixed and how long each one took, the amount of time spent interacting with the IDE, browser, and other programs, the number of story points completed per iteration, the number of defects found per iteration, word-count of the each story, points per story, defects per story, and many, many, others. I collect all this data with the aim of using it to assess the impact of changes to the team. If a developer joins the team (or leaves) then I have metrics to report the impact to the product owner. If we change IDE then I can see the impact on the numbers. I can assess the impact of changes. It is always important to correlate the numbers with the opinions of team.

Metrics have gotten themselves a bad name because of a couple of horror stories from the distant past. However, they remain the only way I can justify calling myself an engineer, and the only way I know that I can improve.

Software Engineer’s Manifesto

A manifesto for software engineers…

I am an engineer

But I am also an agent of an organisation that exists first and foremost for the sustained benefit of its stakeholders.

Whilst I value the opinion of other engineers, I value facts more.

I respect more senior engineers and I guide and inform more junior engineers.

I continually improve my practice.

I continually provide feedback to my peers, seniors, and juniors.