Bridges and Gardens, Part 1

I think Andy Hunt and Dave Thomas (The Pragmatic Programmer, Addison-Wesley, 1999) put it best in their interview with Bill Venners -- one's approach to software development should be less about building bridges and more about cultivating gardens.

Think about that for a minute. Gardens -- not bridges. What exactly does that mean? Bridges are stone, or concrete, or ahhh, metal. Gardens are well, plants and dirt...right?

I'll admit it, at first I wasn't sold. I absolutely love bridges. Ask anyone who knows me. I love their structure, their efficient design, and especially their strength. I love that there is so much creative variation on what is essentially a simple concept.

To further strengthen my bridge passion, I've always described my technical solutions along the lines of bridges: "I'm joining together two disparate systems using a common conduit.", or "I'm pulling the data for two different business units into the same application which will allow them to easily share information." Sound familiar? Plus, there's no way an application could be a garden -- time moves too slowly in a garden! In addition, gardens are a lot of work -- weeding, watering, it's constant maintenance. Not to mention the fact that they're full of bugs...a programmer's worst nightmare, right?

Well, this concept of programming as gardening has really stuck with me. I've tried to shake it, really I have. I attempted to discount the notion (the token fight response), and I even tried to altogether ignore it (there's the flight). However, the more I resisted, the more I found myself questioning WHY I like bridges so much. Here's some of what I found out:

1. I like bridges because they're graceful.

2. I like bridges because they're clean and efficient looking.

3. I like bridges because they bring concepts together in a harmonious manner.

I also thought more about the garden metaphor, in order to prove to myself how different the ideas were. And I did exactly that -- the concepts are indeed different. So, game, set, match, yes? Not exactly.

More on that next time...

Rapid Growth in the OAD Garden

Your application garden is thriving. You've laid a nice bed of soil, the sun is shining bright, and you have crystal clear water flowing freely down the rows. It's nothing short of idyllic!

However, this is the most important time to be careful -- things will only stay perfect for a short amount of time before the more active programs overgrow, drain the nutrients from the soil, and block the sun. You must be a diligent gardener!

Remember, an application garden will be happy to grow beyond its capacity, and it will not stop when it reaches the boundaries. Certain applications will overtake others, competing for vital resources, and it's hard work to keep everything in balance.

What's this all about, anyway?

So, first blog entry on the subject of Organic Application Development. Took long enough to get off the ground, but the 2006 CFUNITED conference helped to solidfy some of the more "floaty" concepts that I've been batting around.

Let me first be sure to state that I don't have a background in computer science or engineering. I'm an environmental scientist by training, and a computer geek by passion. I'm also extremely interested in the study of complex systems. I find that the EnvSci training helps immensely when considering the enterprise in terms of software development -- but more on that to come later.

Anyway, this concept of Organic Application Development has been brewing for several years, and I think I've finally got it to the point where I can start describing the details in a simple, straightforward manner.

So, more to come as time, structure and reason allow -- stay tuned!