Recently I was learning ANTLR, trying to decide whether this was a right technology to pursue a particular project which involved parsing a preexisting message format. After a week of a spike, we decided that it was worth pursuing and started on earnest on the grammar for our project. However a week into this process, I had an epiphany … I was doing some things wrong with the ANTLR grammar which were now slowing progress in adding the new characteristics it needed to be complete. Many developers know this feeling; the features of my grammar that I had built over the first week were naive and now hampering it from expanding into the new requirements. I took it on myself to kill the entire grammar and start again. It took less than a day and half to replicate that week’s worth of work (i.e. pass the test suite which had built up around it).  I’ve done this before; scrap the first attempt at building a domain and try again. Here my domain was the same (it was after all defined in both a standards specification and in the many hundreds of thousands of sample messages we captured from an existing system), but its implementation needed refinement.

So I think that the rule about throwing away spikes can in fact be made a general axiom of programming:

When you are learning a new technology, make sure you throw away the first thing you build that works – to avoid accumulating your mistakes.

Thanks to Robert for the important qualifier “that works”.

N.B. my views about system rewrites have not changed regardless.

The repetative (sic) steps that a single worker performs on an assembly line is a good example of a simple task

This is a terribly Fordist/Taylorist view to take of assembly work. That most beloved of industrial examples, Toyota, takes weeks to train its process-line workers to be able not only to do the simple repetitive steps of assembly, but also to be able to identify and rectify problems with the assembly-line. As Steven Spear, author of Chasing the Rabbit (my review here) might say, anyone who thinks that “assembly line” work is simple task probably doesn’t understand the nature of their process enough to keep up with their more innovate competitors, let alone outdistance them. Understanding your process, well more importantly, your organisational goals and how your process does or does not fulfil those goals, is critical to improving your organisation, and it leads me onto the idea of “evangelism”.

I both agree and disagree with Coder Friendly’s position:

Don’t become an evangelist yourself : look at your project and decide which methodologies is the most adapted. Sometimes, Agile is not the right one but if you see that your requirements are far from agreement or certainty, Agile approaches are probably a good choice.

I agree that “evangelism” can be politically off-putting.People don’t react well to being told their old kool-aid contains poison, and to uncritically drink this new kool-aid instead. However the main problem I have with a statement like this is that non-Agile companies use this “adaptation” argument and approach, in order to keep their poor contexts alive. This is the fallacy that’s found in ‘scrum butt’: “Oh we do Scrum, but …”. The clauses after the ‘but’ are typically critical. The organisation concerned is usually trying to keep some essential organisational dysfunction alive, because of politics, resistance to change, simple misunderstanding, lack of understanding about their own process, or maybe even simple laziness. I’ve got no problem with an organisation that is mature in its use of an agile method adapting it to their local circumstance – in fact if you are doing it properly, with its emphasis on empowering teams to own their process and carrying out regular ‘inspect and adapt’ at the end of every iteration, after six or twelve months of this the process will most certainly be adapted to the local conditions.

However, the real danger is at the start of the agile adoption process, when you have people hand-waving about “can’t do that here”, for whatever value of that there is. I’ve seen it said about: pairing; story boards; acceptance criteria; automated testing; retrospectives; daily stand-up; adaptive and emergent design; and just about every other aspect of XP or Scrum process. The reason is, I think, that these organisations rarely understand what the real organisational goals actually are, and they understand even less about their existing process, to the point they just “do” the process that “is”. “It is what it is”, is a great term, and if anyone says this to you it’s just a fatalistic attempt to accept as unchanging something you can change. Accept the bad. Don’t think it could be better.  Attempts to meddle in the process, i.e. change it, induce fear, and with fear often comes timidity.

This is where you need a real agile evangelist. This is not someone who just thinks that Scrum or XP or whatever other process should be blindly substituted for the existing one, but someone who understands that process is about competitive advantage, eliminating waste, and that you have to start from a known position and continuously work towards improvement. Change is not just good, but necessary, and you need those change agents. Passion for doing things better is bad? Only in a change-averse company. So learn your existing process, thoroughly, and then learn the proposed agile process, thoroughly, and only then will you be able to ‘synthesise’ a replacement. Only I think you’ll find that replacement will look a lot more like the plain old agile process than your existing unagile process. After all, if your existing process already has adequate inspect-and-adapt cycles within it (not lip-service ones, real ones), probably you are already doing and agile or lean process even if you don’t call it that, and you’re already number one in your marketplace. If not, perhaps you require the passion of an evangelist.

Agile requires the discipline to move projects through teams. Multitasking is nuts in agile. Moving team members around to have the “best” specialist available for a particular team is nuts. Performance reviews for individuals is nuts. Managers have to change everything they do, if they want to move the organization to agile. Managers need to see the problems exposed by any given project’s transition to agile and work to remove those obstacles before transitioning to agile.

It’s too easy to think that just because you can get one of your teams to use an agile approach, that your organisation is now Agile. Too many managers “see the problems exposed by given project’s transition to agile” and decide to blame the agile process for the problems thus exposed.In far too many organisations I’ve seen have extremely capable teams delivering quality software in an agile process but remain – in some cases years later – completely unsupported by their senior management (and in some cases with very little support even from their CIO level).

That’s a very sad situation as it is and takes all your selling skills to get the management to “get with the program” so to speak. But this situation can be even more compounded when the management have been convinced that Agile is some sort of silver bullet that will cure all their issues. Whenever you are trying to sell agile to management, never waver from the fact that agile is hard (as everything worth doing is nearly always difficult anyway!). Agile takes discipline.

Johanna’s right to say you can’t adopt agile across an entire organisation in a big bang approach. But you can’t also adopt it without skill and commitment to doing so from managers and executives.

Anyone thinking about SOA really needs their solution architects to read and absorb Gregor Hohpe and Bobby Woolf’s book Enterprise Integration Patterns before they consider enterprise middleware purchases.

First, I no where made any “assertion that if you are putting ‘//TODO’ markers in your code, you’re somehow not properly following the Scrum process” – I said if you find yourself using ‘//TODO’ markers in your code you are being prevented from getting to done-done and that you should “Identify the problem, propose a counter-measure and fix the process“. I can’t emphasise that enough. “Fix the process” does not mean “follow scrum” but rather to use your team’s collective brain to work out what stops you from fixing the code then and there and propose a solution to the problem.

I think ‘//TODO’ should either be in the current story (I will concede that you might want to use a ‘//TODO’ to remind yourself about tasks in your current story, i.e. “come back here tomorrow when I add the validation”) or in the “backlog”. I put “backlog” in quotes there to point out I mean “backlog” in the broadest sense, if you using Scrum or XP that’s actually where the work-to-be-done is physically kept, but if you have some other process then your “backlog” is kept somewhere else, and what is preventing you from adding to it?

I will ask a question of the anonymous poster – at what point exactly  is a ‘//TODO’ comment left decaying in the codebase without a story for days or weeks a good idea? Or is it that you just do not want to make what it is being done in the code base transparent to those who are paying your bills?

I will contend; ‘//TODO’ never gets done because the product owners never see them. They act as an opaque barrier to open communication. If you find a ‘//TODO’, lets say a big major refactoring will be needed to support a story you already see in the backlog, what’s the problem with having an open and honest communication with the team about the story’s estimate? If it’s a future story, i.e. feature related, it should be in the “backlog”; if it is code or design related which impacts you now, either it should be done then and there (refactor mercilessly) or it’s a bug which you either fix or raise a bug report for, and if it’s just some nebulous “improvement” either do it now or YAGNI. If you’ve got great tooling like Mylyn for Eclipse you can drop a “task” at the code point and move on. The point there is the “TODO” isn’t obscured away in the code but rather visible to all because the ‘//TODO’ is now either in your Wiki, your task-tracking tooling via it’s Mylyn integration, or is included as part of a story card on the story board.

If you can’t refactor mercilessly – what the post is really about – all the usual excuses apply, i.e. “we’re not confident about the code base not breaking in unknown ways” (i.e. no tests), “it has to be done by tomorrow,” et cetera, and all of these are symptoms of dysfunction in your organisation.

People love their little comfort zones and they don’t like being pushed out of them, that’s for sure, programmers included (yeah, and that’s a me too). Habit is not an excuse for avoiding improvement.

Here’s a great imaginary conversation from the C2 wiki entry about YAGNI that I think applies here:

“But Ron, I know how to do it right now, and later I might not.”

“So, Sam, you’re telling me that this class you’re writing is so complex that even you won’t be able to maintain it?”

Today I just want to meditate on a code artifact that often manifests itself in such environments. I speak of the comment //TODO seen frequently in such code. The idea that future “refactoring” goes on the “todo” list in such an environment is completely broken. An environment that allows that to happen means it will never get done. Do it now, or don’t do it. TODO is considered harmful.

I have come around to the view that ‘//TODO’ comments should make a build fail. Either:

1. It is a future story yet to be implemented and placed into the backlog,
2. It is work in progress (and by definition doesn’t need a TODO because everything still needs to be ‘done’), or,
3. It is done, as in DONE-done, and therefore the story is complete and there’s nothing left “TO DO”.

In other words, “//TODO” is a indicator of a process that’s not letting developers get to “done”. Identify the problem, propose a counter-measure and fix the process that stopping you from getting to completion.

Firstly, I found the second day much better than the first. I did see Michael Nygard’s two talks on Monday morning and got a lot a lot of useful information from those. Titled ‘Failure comes in flavours’ the first was a great overview of the types of failure that applications running in production encounter, the second ways to avoid those failure modes. Basically it’s how many of the non-functional requirements can eat your app (and even the entire integration if you let the failure propagate easily) if you don’t give careful consideration to them. He’s got a book so I’m going to check that out next.

The first day for me was severely spoilt by a poor vendor presentation (hint: one that is not Oracle, not that they would have necessarily done any better), which I should have known better to avoid. I already swim in the BPEL/BPM/SOA soup, I fully understand just how broken it is as an actual development concept (e.g. anti-test-first to name just one). I was fooled by the title to thinking maybe it had some insights to avoid the worst of these busted concepts, but no, the vendor’s tooling is all the rage if you drink the poor-tasting conceptual kool-aid. This stuff is marketed at managers and non-coding architects who choose to buy this stuff then dump it from a very great height into the laps of the poor developers who have to mangle it into a deliverable system (half the time with a development budget just a tenth the cost of the licence). Anyway back to the good stuff.

Mike Cannon-Brookes from Atlassian (which makes great development tools, highly recommended) gave a mostly great closing speech on the first day which made me think about a couple of things. It wasn’t until the next morning however that it crystallised in my mind. It’s a bit of a minor criticism.

Mike threw out a minor line, an aside really, talking about Atlassian’s agile development methodology, and basically that said, people who say ‘you must do this’ are wrong, because they miss your context. Here ‘this’ is some type of agile process artefact like maybe, pairing, or estimating in story points, or whatever. Well, it’s wrong and on two counts. The first count I realised just after the talk but couldn’t articulate it correctly in semi-drunken conversation. That first count is very simple. Mike’s timeline on his Atlassian experience has him, if I recall correctly, starting his company and creating the great tool Jira, in his early twenties. Now as he dissed “old people” in his talk I’m going to give some back. In your twenties you’ve got no idea what works, in a general sense. You might know (or think you know) what works for you, but that’s a completely different kettle of fish to what works generally. Why not? The word is experience. Its not until you reach … oh … I’ll say around 35 (and so maybe lose the capacity to build technical innovation, perhaps, as Mike asserted) that you can have real insights into process and people. It’s just because at this point, you just have not got enough practice at it (see Malcolm Gladwell’s recent book for some basic data about the power of practice).

But the bigger point I think is the word context. The phrase ‘my context is different’, is this classic phrase which really means ‘that won’t work here’ and that really means, I don’t want to change. As a consultant , you hear this stuff all the time: … “We’re unique, our company is not like those other companies. We can’t do that here. Detailed estimates are really the most important part of the development process. The budget and the features must be fixed. We have a reporting process that allows the budget and features to be fixed. Pair programming doubles the time it takes to deliver the features. Quality doesn’t matter. Technical quality is a business decision. The business are too busy to talk to you.” … And a whole other other bunch of epic agile fail. Someone’s context is exactly why they aren’t as agile as their competitors and are looking at using ‘agile development’ to help save them … but as long as they insist on my context trumps all, they will only get a fractional improvement and not an order-of-magnitude one. But Atlassian make great products, so it doesn’t mean you have to have ‘scrum’, or ‘XP’ to do that, the greatness I guess, is orthogonal. However if you are looking to ‘do agile’, then do agile. Pick a method like Scrum or XP then do it all. How do you know pair programming will fail in your organisation if you don’t try it first? You don’t. Do it like it says to do it (e.g. the Kent Beck books) and after a few months experience for your team, use the lessons from the retrospectives that the team has discovered to improve the process. Do not cripple the process with your ‘context’ before you even try.

And right on cue, on the second day along comes Steve Hayes with a great presentation on exactly this topic: “How your choices affect your agility”. Steve is a fantastic speaker, entertaining and pretty insightful too I thought. I rated his talk the best talk of the conference. He said he got lots of red cards (participants could rate each talk as green==good, yellow==ok, red==bad) in his Sydney session – what is the matter with your people? It was a great talk. I loved the part about naivety. To propose a solution from the most naive perspective possible, and what an epic win it is when a customer says “ok”! It means I understand the problem! I even tried this today with my client, I didn’t get the instant “OK” but working from the basis of that incredibly naive solution we did manage to eventually envisage the simplest thing that could possibly work. And I love that. So thanks tons for that insight, Steve!

Another great talk on the second day was Linda Rising’s ‘Deception and Estimation’ talk. Turns out (via psychology and evolutionary biology) we engage not in rational decision making but in emotional choices all the time. All choice is emotional. So we engage ourselves in self-deception all the time. And none of this is bad … it’s good. People who don’t engage in this constant self-deception are generally clinically insane. So get over it, and yourself, and when you’re estimating (and from the sounds of it, doing any sort of major-impact decision making) and get as many perspectives as you can from the most diverse range of people you can manage (to avoid groupthink, which is I guess, the situation where everyone’s self-deceptions all align). Joshua Bloch’s second-day keynote was also highly worthy of praise. Good insight and excellent effective code examples (yes, in a keynote). Also worth the greatly discounted entry ticket price was the many interesting conversations I had with past colleagues and new friends on many different development issues.

In short, JAOO was generally of very high quality and I hope is keeps coming to Brisbane! Will definitely be going next year. Many thanks to all the organisers, presenters and sponsors.

My two cents on this issue is simply that yes, fixed price, fixed scope contracts are “evil”, in the sense they are harmful for the project being delivered. Alef and Seth have some excellent points why client organisations,  especially when initially dealing with a consulting organisation for the first time, want to manage their risk by choosing fixed price and fixed scope, and why it’s harmful to project success.

I’ve had some clients exactly like that – the company is negotiating with one now. The real concern of theirs – and ours – is that they can build a trust relationship between the two organisations. I think, like Seth, once that trust relationship is built, managing the scope of the delivery is much easier. Seth recommends using target cost contracts (PDF). I know that agile contracts were one of the areas the Brisbane Scrum User Group were hoping to do a session on.

In my view, the real danger isn’t from the fixed price. After all if you quote me a dollar figure I can tell you how many days of involvement that buys from my consulting firm. Exactly what that builds is completely  dependent on what is being asked. The problem comes of course with fixing the scope. There are a number of issues around fixing the scope, which together present a huge huge of project failure:

• It assumes you have perfect information at the start of the project, before anything is even attempted. Most developers can easily tell you that you don’t even know 20% of what you’re getting yourself in for – even if you just finished completing something very similar just the day before.
• Problems, being unforeseen, can’t be accomodated in “buffers”, because we don’t know actually know what is unforeseen.
• It closes off all prospect of innovation with the project as the project progresses. Discovered insight (the most valuable kind) is simply excluded, or it is buried alive in a negotiation or a change control process.
• It might not match with the price even if everything goes to expectation (i.e. it is simply an unrealistic scope for the money). This is related to but not quite the same as the “9 women pregnant 1 month each” problem, which is to say, it’s just not possible to do it.

The real problem is, that I see, is that clients tend to close off the scope before they close of the price. You can see this in the standard “tender” procedure so loved of big companies and governments. But I’ve had that experience too inside an enterprise dealing with internal clients. Most developers will be familiar with that sort of conversation – “All the scope is non-negotiable up-front and please tell me it will cost 4 weeks? What do you mean ‘at least’ 4 months?” In a previous life I used to have exactly this conversation about every month. On the other hand, if you tell me your budget first, I can tell you the approximate sort of system you’ll get from that.

Consider the following scenario.

1. You’ve got two parts of the code base. One part is beautiful code, written TDD, used continuous integration, pair programming, well written stories were used to produce it, clear acceptance tests, all the good stuff. The other part is horrific, hardly any tests, when the build failed, you disabled the tests that failed, the stories were written as technical tasks, acceptance tests vague, etc.
2. You are asked to deliver two medium-value stories in the next iteration. One story is most done in the good part of the code base. The other story in the bad part.
3. Correspondingly, your estimates will vary according to the complexity of the code base – the story in the “good” code might be 5 points, the story in the “bad” code is 15. But the value to the business delivered is the same!

The point is, the amount of effort that you do (20 points) to deliver 2 medium value units, is actually not a measure of your progress. It’s a measure of your waste. The next iteration you might be able to deliver 4 medium value points, if they are all in the “good code” base! Same effort, twice the return on value. Software developers know this about well designed code bases combined with good engineering practice, of course. The point is about directly exposing the effects of bad engineering as it manifests itself as a barrier to progress.

What if you told the business instead, you’ll deliver x business value points instead? That is, your burn down and burn up charts don’t show story points of effort expended, but directly indicated value delivered. What impetus does this lead us to? Well, now we’ve got a direct measurement of story points over business value, which is the proportion of waste to value. The ultimate story is infinite in value and takes zero points to deliver!

I think this is not all; because it directly establishes the ratio of waste to value, it gives you an impetus to eliminate waste, that is, to practice good, professional, software craftsmanship of the type that Robert C. Martin talks about in the video I linked to earlier tonight. Software that allows you to change efficiently to meet new needs now becomes not an abstract principle that you must kick back at your managers every time the demand to see “more features” and less engineering, but becomes a direcly correlated measurement of productive output.

It’s not all plain sailing, for the really hard nut has to be cracked. How the hell do you measure business value in units like “points”? I don’t have a cheap and easy answer right for it right now. But I don’t think this very hard question should go unanswered. For me, it’s the missing piece of the agile software delivery puzzle. I’ve been asked countless times, to estimate effort on whole swathes of stories where I think it’s obvious that the business value is actually highly dubious – or at least cannot be quantified by the product owner. On one level, that’s fine, they pay the bills and get to set the priorities, but on another level, I think that having to produce a quantifier for the value will help the product owner focus their minds onto the outcome in a much better way.

And it enables them to directly see the correlation between bad engineering practices and the inefficiencies they engender. Those bad practices are certainly our fault for putting them in place, don’t get me wrong, I’m not shirking our personal and professional responsibilities in that regard. However reducing outside pressures will certainly also help by giving us a little breathing space to demonstrate with hard numbers the value of taking care with our craftsmanship. And it reports the thing the business are most interested in – the value you deliver.

If my post is a little unclear, forgive me it’s late at night as I write this. Better blog entry than code in the tired state I’m in!

Link: http://www.viddler.com/explore/sergiopereira/videos/7/.