from Ewan’s posterous

“I’ve worked out what I want to be.

I want to be a code hitman.

I want to contract myself out to the highest bidder and get paid large sums of money to put hits on code. So basically, I get contacted through a secure channel and made aware of what contracts are on the table, then I decide which contract I’m interested in and I let the contractor know that I’m in. I get paid half up front and half when the job is done. I only use my own equipment, my own compiler and my own component libraries and I only handle the specific problem that I’m being paid for, no favours. I go in, I take ownership of the code, I locate the target, and I debug it, or even rewrite it if required. Once the job is done I leave, no questions asked and the other 50% is transferred to an offshore account specified by me. At no point do I get asked for documentation or a helpfile and I’m known in the industry only as “The Meerkat”.”

In general, no. There are some software developments where predictability is possible. Organizations such as NASA’s space shuttle software group are a prime example of where software development can be predictable. It requires a lot of ceremony, plenty of time, a large team, and stable requirements. There are projects out there that are space shuttles. However I don’t think much business software fits into that category. For this you need a different kind of process.

One of the big dangers is to pretend that you can follow a predictable process when you can’t. People who work on methodology are not very good at identifying boundary conditions: the places where the methodology passes from appropriate in inappropriate. Most methodologists want their methodologies to be usable by everyone, so they don’t understand nor publicize their boundary conditions. This leads to people using a methodology in the wrong circumstances, such as using a predictable methodology in a unpredictable situation.

There’s a strong temptation to do that. Predictability is a very desirable property. However if you believe you can be predictable when you can’t, it leads to situations where people build a plan early on, then don’t properly handle the situation where the plan falls apart. You see the plan and reality slowly drifting apart. For a long time you can pretend that the plan is still valid. But at some point the drift becomes too much and the plan falls apart. Usually the fall is painful.

So if you are in a situation that isn’t predictable you can’t use a predictive methodology. That’s a hard blow. It means that many of the models for controlling projects, many of the models for the whole customer relationship, just aren’t true anymore. The benefits of predictability are so great, it’s difficult to let them go. Like so many problems the hardest part is simply realizing that the problem exists.

However letting go of predictability doesn’t mean you have to revert to uncontrollable chaos. Instead you need a process that can give you control over an unpredictability. That’s what adaptivity is all about.

~~ Martin Fowler, The New Methodology – http://martinfowler.com/articles/newMethodology.html

Posted via email from Ewan’s posterous

use Acme::Don't;
don't {

# code here
# Note that the code in the don't block must be syntactically
#   valid Perl.
# This is an important feature:
#   you get the accelerated performance of not actually executing
#   the code, without sacrificing the security of compile-time
#   syntax checking.

} while condition();

# And, yes, in strict analogy to the semantics of Perl's magical
#   do...while, the don't...while block is unconditionally not
#   done once before the test. ;-)