Software Design is Gene Splicing!

I came across a new article by ACM about Web Science, a new interdisciplinary approach to looking at how the web works. Its a great article about how we in software design have been thinking about the web all wrong, and need a more broad approach to solving its problems. Master Mark makes the comment that terms like "engineering" and "architecture" are completely misused when it comes to software. I never liked the terms myself... Mark suggests that instead we use the analogy of gene splicing.

That's the best idea I've heard in a long time... Maybe I should change my title to Chief Software Splicer? Maybe Chief Software Hybridizer? Chief Software Incubator? I'll noodle on it for a bit...

I have seen far too many projects go astray because people thought there was a "right" way to do software... probably because they bought into the concept of it being similar to designing a building, or slapping gears together. No No No! Software design is vastly different... we're more like mad scientists. Good software designers understand the potential for chaos, and use techniques to control it.

What we do has the vague appearance of science: we use algorithms and patterns that have worked in the past, we get to know limitations to physical hardware, we analyze common security and performance blunders, etc. However, every time we create new software, we are building a new Frankenstein's monster! It could be utterly mundane, or terrifying and ferocious. Likewise, integrating two existing systems isn't as simple as clicking together some Legos... its merging two completely different species into one single unholy unit. In other words, its creating a hybrid chimera like a eagle with a lion's head, or a fire-breathing manatee.

In short, its difficult to predict the end result of software unless you've done exactly the same thing in the past... but in practice, this almost never is the case. People rarely pay developers to do the ordinary... which is also part of the problem.

Sure, we can make reasonable guesses of what this new beast will be like... based on previous combinations, patterns that work, initial tests, and similar software development best practices. However, its still difficult to determine how it will behave in the wild until you unleash it. Perhaps software developers should take a page from the mad scientist handbook, and hone the following skills:

  • Keep close tabs on your new creations.
  • Observe closely how they interact with humans.
  • If they cause humans pain, then you must act swiftly:
    • either destroy your beautiful creation and start over, or
    • teach it to behave better.

Either way, new software will behave in erratic ways, and you always need a plan for what to do when it begins to behave badly... And many times you never know how it will behave until you unleash it upon the keep the tranquilizer darts handy.


Thanks for a great post!
I wanted to add that new systems have emergent properties that you don't realize when you're building it. Sometimes those are good, sometimes those are bad.

Recent comments