On a random, early Saturday morning, I was listening to a story featured on WAMU 88.5 (American University Radio) related to a recent advance reported in Nature (Dymond, J. S. et al. Nature 2011). Essentially, scientists are working on manipulating yeast to behave like a little factory for humans, producing fuels and specialty chemicals.
While the radio piece articulated at the consumer level the story of synthetic biology in about 30 seconds (which alone is cool for this layperson), highlighting the story of aspirin from Hippocrates’ initial suggestion that pain could be treated with willow bark to our ability to extract and then make the ingredients required. Jef Boeke at John Hopkins discussed some of the potential future uses for developing yeast optimized for specific purposes, such as production of biofuels, vaccines or drugs. Super cool. But so what?
Peter Enyeart, a Texas at Austin graduate student who reviewed the Nature paper, articulated something transcendent between the worlds of experimentation and discovery and software development--"Evolution remains our best option for designing code, which makes sense because that's how nature does it." While he was speaking to the "scramble technology" approach being used by the Boeke's lab--which creates a massive set of synthetic mutations which can be iteratively gone through to choose which ones work best for a given purpose--I'd propose that his other comment, "if you just try to intelligently design it - if it works at all, it probably won't work well" speaks right to the heart of quality software engineering.
We have learned in the vastly immature art of software engineering (as compared to the long practiced art of medicine), that in projects large or small, trying to elicit all the requirements, come up with a grand "intelligent" design, and then code and test it out probably won't work and surely won't work well - because "change" happens. "Needs" evolve. What is originally envisioned can change frequently during the development process for a multitude of reasons. I don't mean to suggest that performing comprehensive design exercises is futile. What I am inspired by, and continue to see in our results, is that getting at the basis for what software needs to accomplish, coming up with the best design possible, trying it out and doing so in short intervals that balance pressures of budget, time, and quality is the best way we know to deliver value. We represent that belief in our Glassbox Development Process - itself an evolving methodology, and it is comforting to know that in our target markets of health and life science, a similar belief is held.
-Brent Gendleman, 5AM Solutions
Photo Credit: Wikimedia Commons