I believe that constraints are usually a blessing, not a curse. Not a new idea, but certainly one that gets reinforced every time I see a project with a vague concept or definition meandering through the early phases. Some sort of limitation, whether it’s resources, time, or something else almost has to be in place in order to keep things moving. Otherwise a project runs a real danger of becoming a Christmas Tree Bill
, as various parties attach new features or requirements to it. Or the project is prone to picking up a lot of features that are further and further away from the core idea.
Apparently, certain Military contracts are subject to this too. [via Greenspun] Here we have a helicopter that only generally gets used for 15 minutes at a time, but now it’s a flying, super-advanced telecommunication system, with state of the art defense systems, extended range, etc.. I think it’s a victim of constraint-less project specification.
Everyone involved wants to do everything they can to protect the president, which means spare no expense. Hence you’re going to end up literally, with a result that can’t get off the ground because it’s too weighed down by features. It takes constant vigilance to edit non-essential features out of existence before they complicate your product and your code base, and as BA’s we’re the first line of defense.
