Skip to content

To do redux

I just want to answer the anonymous “process nazis” trackback on yesterday’s ‘//TODO’ Considered Harmful post, because that blog desn’t allow comments without a login. Quite apart from issues with Godwin’s Law (and that the writer has enumerated a bunch of rules that get “violated” then accuses other people of being process nazis), the post severely misattributes both my post, and also, I think, misunderstands what agile methodologies are all about.

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?”

4 Comments

  1. Robert wrote:

    Yes – it’s about project management. Make the TODOs visible, and a large part of the problem goes away. Make them visible in a way that ensures they get acted on, and even more goes away.

    Here’s another (related) sign of an unhealthy process – if creating an issue in the issue tracker is not something that every person on the team – esp. the devs – isn’t comfortable doing, you have problems. I know the devs on my team got shocked recently when I raised a dozen or so bugs as a result of a code review I did – “Devs don’t raise bugs!”

    Sunday, June 7, 2009 at 09:17 | Permalink
  2. First, that was my site.

    You can register at the register link, or by going here: http://chaosinmotion.com/blog/wp-login.php?action=register

    Second, your original article came at the same time I was told by our scrum master not to go through and clear bugs from the back log–I spent two hours scrubbing out a dozen bugs which took me literally minutes per bug. I was told instead that I was supposed to wait until the next scrum planning cycle and put in reasonable estimates for each of the defects–a process which would have taken substantially longer than just fixing the bugs.

    In other words, you played a minor guest role in my overall rant, not a staring role.

    Third: “I will contend; ‘//TODO’ never gets done because the product owners never see them. They act as an opaque barrier to open communication.” Naturally. I don’t disagree. In fact, the principle point of my post is that any process–formal or informal–can be abused to the point of absurdity. ‘//TODO’ markers are a form of informal process–and failing to track them at a level where there is visibility is obviously an abuse of that process–and violates good inter-team communications. (By “team” it should be clear I’m talking about the entire group of folks from PM to PGMs to QA to Dev who are working on a product.)

    However, I will also contend that removing ‘//TODO’ goes too far in the other direction.

    And forth: it’s obvious you only skimmed what I wrote, which is fine: it was a bit massive. However, my six “rules” are observations–one of which is supported by a half-century of psychological research. (That the human mind is capable of only tracking 7 +/- 2 items in short term memory.) When you write “…and that the writer has enumerated a bunch of rules that get “violated” then accuses other people of being process nazis” are you saying that good inter-team communications is not necessary for good team cohesion? Or that corporate memory (collective team memory) is not a necessary element to a development team?

    Or are you trying to construct a strawman argument that since observations about human behavior are similar to a software development process, that I’m being hypocritical when I assert that when a process violates these observations about human nature, the process is going to get in the way?

    “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?”

    Since the question is based on the assumption that I asserted leaving a “//TODO” comment decaying in the code base was a good idea, clearly a false dilemma (http://www.onegoodmove.org/fallacy/fd.htm), it seems pointless to answer the question. However, if you are asserting I’m arguing against transparency when I clearly stated inter-team communications is vital, then please re-read what I wrote before blasting me.

    Sunday, June 7, 2009 at 09:19 | Permalink
  3. Scot Mcphee wrote:

    Hi William, it is good to put a name to a post ;-). I shouldn’t have included the comment about the rules being “violated”, it was a snark and I guess out of order on my part.

    You will have to excuse my polemical style, I think. You should hear what I have to say about the ‘extends’ keyword and much else besides, like Java’s generics implementation for instance, even though I have found myself slightly missing them of late (current product must be delivered on 1.4).

    I can concede that sometimes a ‘todo’ is a useful marker in the code; but I see them also being severely abused, mostly in environments where programmers are prevented from providing professional-standard code by a process that insists that craftsmanship has no value. So the programmers put the ‘todo’ in the code almost as a piece of willful “f**k you” to the process that stopped them from just fixing the problem (I’ve certainly been guilty of that). I certainly don’t mean to blame the programmers who do that, it’s the process that is to blame and is what requires rectification.

    As I like simple, polemical, solutions to these problems, I proposed banning ‘todo’ comments as a way to force the problem to appear further up in the process chain, to make it visible to those who create it. In terms of general workflow management, I also think there are several great tools now available which make the ‘todo’ comment otherwise redundant in the milder, gentler, cases of usage.

    I just want to comment further on one thing you said in your comment: “I was told by our scrum master not to go through and clear bugs from the back log–I spent two hours scrubbing out a dozen bugs which took me literally minutes per bug. I was told instead that I was supposed to wait until the next scrum planning cycle and put in reasonable estimates for each of the defects–a process which would have taken substantially longer than just fixing the bugs”.

    Well, that process is so many ways to wrong it beggars belief (which you’re aware of, of course). For a start, there’s actually no way to make a “reasonable estimate” of a defect repair. It could be a simple one line fix of a dumb typo or a compulsory redesign of half the code base because you’ve got some central concept all modelled wrong! And even in the first instance, it could still take you two days to find that’s the case; I’ve lost count of the times I sat for two hours with increasing frustration looking at the very block of five lines of code that emanates some NullPointerException and trying all sorts of increasingly desperate fixes to clear the bug until I get some head-slapping moment of ‘duh’ because I loaded the wrong properties file, or read from the wrong variable, or some other simple mistake that I just didn’t see straight away. And how do you estimate for that? As you pointed out, it’s just a waste to try to put that into the planning cycle. Generally bugs should not be estimated – the time to fix them just comes off the velocity of story points the team gets through. The less defects the team produces, the better its velocity gets. If the defects are estimated and included in the velocity – the velocity can go UP yet the delivered functionality DOWN!

    Lastly, the bug belongs to the story that generated it, not to some extra piece of process. Consider my head-slapping moment of ‘duh’ above. If I found that bug while coding the story, well the story just got two hours longer to complete than otherwise. But if the story got through the process to ‘done’ and comes back later as a bug – it’s not just part of the story’s velocity? So there’s an arbitrary nature to the process you’ve been subjected to.

    Therefore, I’d say there’s a whole conversation you’ve got to have with your scrum master about how bugs are handled in your team.

    Sunday, June 7, 2009 at 10:05 | Permalink
  4. No problem; I guess we could say my apologia collided with your polemic. :-)

    “I can concede that sometimes a ‘todo’ is a useful marker in the code; but I see them also being severely abused, mostly in environments where programmers are prevented from providing professional-standard code by a process that insists that craftsmanship has no value. So the programmers put the ‘todo’ in the code almost as a piece of willful “f**k you” to the process that stopped them from just fixing the problem (I’ve certainly been guilty of that). I certainly don’t mean to blame the programmers who do that, it’s the process that is to blame and is what requires rectification.”

    On this we completely agree. The ultimate problem I’ve seen at the various places I’ve worked is that programmers are seen as interchangeable (and overly costly–can we keep that cost down?) cogs in a machinery crafted by managers who sometimes take pride in their inability to turn on their own computer. (Yes, I had that manager. At Symantec. And again at Yahoo.)

    Craftsmanship? Developers as skilled artisans? Specialists with specialized training? Why, we can’t have any of that–it gets in the way of management who believes software is assembled like cars (with the same corresponding quality as GM) and it gets in the way of the support staff who have convinced themselves that marketing software is as complex as developing it.

    It’s why I tend to bristle at suggestions that we must do a thing to serve a process–because more often than not, in my experience, a strict polemic interpretation of a process is more often than not used as a tool to disempower developers.

    “Therefore, I’d say there’s a whole conversation you’ve got to have with your scrum master about how bugs are handled in your team.”

    In fact, I have had that conservation a few times–sometimes at a less than civil volume (my bad).

    The good news is that our CTO has just suggested in the past day or two that I should have cart-blanche to go ahead and start hiring mobile developers for our company, and eventually start running my own shop within the company. (Part of the reason for my post was to get my thoughts in order about software development processes.)

    The bad news is that now I got to put my money where my mouth is. (!!!)

    Sunday, June 7, 2009 at 10:30 | Permalink