More Evidence that constraints drive solutions

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.

Do we want scientists or engineers? Neither.

Alex Hung asks Do we want scientists or engineers? for developers. If you’re talking about the current output of computer science vs. software engineering curriculums, I don’t think it matters much. Neither has the skill set straight out of college to be effective, and if the person has the potential, both are equally as likely to grow into good developers.

The activity of software development (in a business context that I’m used to dealing with) is not computer science or software engineering although it contains shades of both. It also contains a lot of written and oral communication, a little bit of aesthetics, some history, and a lot of information about whatever domain the software lives in. The most valuable people in a business software development environment consistently seem to be those that bring those extra skills to the table.

I rarely find it to be the case that the smartest developer, or the best coder, or the most educated is looked upon as the best developer on the team. How to identify and teach the extra skills that make up the discipline is still I think and open question.