Being a Software Engineer (Technical Architect as my business card states) isn’t always easy. [Most would probably try to fool you in to believing it is never easy - not me.] Sometimes it is impossible to make the right decision immediately. Agility (Agile Methods) helps to reduce the stress/burden of the problem domain’s unknowns, as well as the solution’s mysteries. I won’t bother rehashing the many problems that exist within the Software Development Life-Cycle - but will just say that requirement ambiguity is a nightmare.

So, how can you possibly deal with it? Assuming there is no avoiding it.

There are a couple of keys: the Agility to respond to and overcome changes, and more importantly an infrastructure that supports evolution, natural or otherwise.

Having worked for the past few years evangelizing Open Source within the DoD landscape has made me overly sensitive to the distinction between consuming and producing “openly” licensed software. But, it has become clear to me - that just consuming Open Source Software make does nothing for agility beyond the more frequent improvement cycle. That’s it.

The real power is in producing Open Source software. However, as I started off saying it’s not always easy to be a software engineer. And, being on the front-end of an Open Source project makes it even more difficult. Fear of exposing skill (or lack thereof), establishing the integration scheme, managing influences, and trying to meet the customers needs all contribute to the complexity. But, by being Open it is much easier to shift, based on the natural learning process a team makes when evaluating technologies, skills, etcetera.

The mantra here is that it is much more difficult to not make progress in an Open environment…where you are exposed. There just is no excuse.

Plugs:
Karl Fogel’s Producing Open Source Software,
Bruce Peren’s The Emerging Economic Paradigm of Open Source,
Paul Graham’s What Business Can Learn from Open Source