Forgive them, for they know not what they are doing..

I am currently working with a great customer, and the people around me are reasonably sharp and have done a pretty good job of the development given the organisational constraints they faced. I’m trying to “fly the agile flag” around the group, and haven’t really had much success at present. It’s not because they’re bad, or stupid, if anything it’s the opposite, they just can’t see how a Domain Model (in particular) and software can grow as new requirements are bought into play. They can’t see how doing the simplest thing leads to more flexible designs that allow the software to be come malleable and more easily changed. They can’t see how a system can be built without a large up front planning and design exercise so you can “work out all the problems”.
But I persist, and I do really like asking questions about their designs, especially when they are puzzling over how to change things. I had a couple of pretty good conversation the other day and it went along these lines.

me:
So, why is this allocation scheme built this way ? Surely it would have been easier to just store each allocated number in a separate row, rather than this bitmap
co-worker:
That’s so we didn’t have any performance problems later on
me:
Oh, but this only works if your allocation is contiguous, is that what really happens ?
co-worker:
No. It would have been much easier to build it the other way, and easier to debug

and then later on:

me:
Why do you persist all your objects this way ?
co-worker:
That’s because we thought we’d need this additional functionality
me:
Did you ?
co-worker:
No. It would have been much, much simpler and easier to build it the other way.

So, after spending a significant time up front doing design and analysis activities. They were still wrong. How often do you make the same mistakes on your projects ? All I ask is, give it a go. Try to get away by only designing and building what you know is needed, and build your software so that it is malleable enough to accomodate the features should they become required. This isn’t an appeal to do no design, or architecture, or more importantly thinking. Edmund Blackadder had it right, “I think thinking is very important Baldric”.

Advertisements

7 thoughts on “Forgive them, for they know not what they are doing..

  1. Agile processes are counter-intuitive

    Jon Eaves writes about the difficulty of convincing people that software can be more flexible if you do the simplest thing that works. I think there are two basic thought barriers that prevent people from buying in to XP.
    First, a lot of the practic…

  2. Hear! Hear! I find myself often trying to convince even folks who consider themselves agile professionals that putting in an API that will survive future requirements, while implementing only what is required for today is a good thing to do. I often find I get push back from XP developers when they consider they’re doing “the simplest thing that could possibly work” and I want them to do that while creating “crumple zones” around their code so that when change happens, the impact is minimised. To me, remaining agile over time requires investing in your design every day, not ignoring it in the desire to go fast. Not doing so will end in tears, so as usual we have to package our (agile) rights with our (agile) responsibilities

  3. This is basically a cry for YAGNI 😉
    The only problem I see is that some people will take this as an excuse to write crappy code. The truth is somewhere in between. Do only what you need now, but think about change (not prepare, only think).
    I believe this should be bolded in your post:
    “build your software so that it is malleable enough to accomodate the features should they become required” .
    As with everything, a time will come when some will say – “I did YAGNI, and when a new feature came, I had to scrap all my code”.
    I’m definitely tired of preparing for the nevercoming changes, but thinking about them doesn’t hurt.
    I usually hear this question: “But what if the user will want to change that?” I have managed this far to keep close to YAGNI by appealing to the inner-lazy self of each person. Quite risky, though…

  4. “the simplest thing that could possibly work” is only a part of XP’s “simple design” — another part of Simple Design is “expresses intention”, which encompasses ideas of low coupling, high cohesion, and other aspects of what we know of as “good design”.

  5. > I find myself often trying to convince even folks who consider themselves agile professionals that
    > putting in an API that will survive future requirements, while implementing only what is
    > required for today is a good thing to do.
    Isn’t “guessing about the API” pretty much the same as “guessing about the needed functionality”?
    I acknowledge the fact that it doesn’t take as much time to sketch the API than it would to sketch the API *and* implement it, but there’s still a piece of YAGNI in there. Of course, whether it’s worth it or not is a choice that you need to make based on what (you think) you know.

  6. However the alternate can happen on projects which use the agile approach.
    me: Why dont you bundle all those fields together into one class. It doesnt make sense to have separate fields for what to me should all belong in a class.
    agile-co-worker: When we started it made sense to do it that way, its the agile approach. But now in our mob refactoring session we will fix that because we have tests.
    The problem I have with that statement is had I not asked I very much doubt it would have been done; or done near the very end IF time could be afforded.
    Obviously there is *some* design but agile projects can easily fall into this sink of lets start and fail to find the happy medium.

  7. Hi Al,
    Thanks for the comment. While your concerns are valid, we are talking about 2 different things. The situation I’m describing is where a valid design decision was made, but it the circumstances where it would be used didn’t eventuate. Basically it was an incorrect guess.
    The situation you’re describing is working with complete morons. I’d like to sugar coat it, but I can’t, sorry. Get out now while you can.
    And, I must point out, it’s not the agile approach to be moronic. That’s just being a moron. And the same goes for any approach. Being agile, or predictive, or RUP or waterfall, or anything, doesn’t mean *don’t think*, which is clearly what is happening in your situation.

Comments are closed.