Many of us know the value of deferring commitment until the last
responsible moment (in the past, I've always said "possible," but "responsible" conveys the meaning much clearer, I think). In fact, it is the underlying principle of
YAGNI, something more of us are familiar with.
The argument goes something like: If you do not wait to make decisions until they need to be made, you are making them without all of the information that will be available to you at the time it does need to be made. Now, you may get lucky and be right, but why not just wait until the decision has to be made so you can be sure you have all the information you can get?
I find it to be very sound advice.
I missed this the other day on InfoQ, but they have an article by Chris Matts and Olav Maassen entitled "
'Real Options' Underlie Agile Practices" that explains the thinking behind this in detail, relating it to Financial Option Theory and some psychology. It's a good article explaining how "Real Options" forms the basis of A/agile thinking, and had some ideas I hadn't heard before about keeping your best developers free as they represent more "options" and you shouldn't commit them too early. Also, they can create options by mentoring less experienced developers (through pairing perhaps). There's a lot more than this simple summary, and I consider it worth a read.
Any thoughts?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Sami
This is something I struggle with a lot when looking at the designs of systems or even the code of other systems. I keep having conversations along the lines of "oh we put that in there in case they want to do x, or we put this in there because one day me want to do z" and I can't tell you how many times X, Z was actually needed or actually needed how the programmers envisaged (and its even something I've been guilty of myself). This is also where a good business analyst and domain expert is worth their weight in gold as they can use their experience, judgement and knowledege of the business/business domain to identify the most likely future changes.
The idea of having your best developers available is interesting thanks for the link
Posted by
kola
on Jun 13, 2007 at 04:41 AM UTC - 5 hrs
Its certainly something I've been guilty of, and probably something I'll continue to be guilty of in the future.
I find it hard to fight the urge to add functionality before its needed (specifically talking about code here), but I try to keep it in my mind and instead make a note about "I wanted to add X here" and if it becomes needed I can easily go back and put it in (or I can even talk to whoever makes the decision about functionality and tell them I thought X may be needed, if that becomes the case).
Posted by
Sam
on Jun 14, 2007 at 11:14 AM UTC - 5 hrs
