Sunday, December 31, 2006

Okay, so how do I get started?

Taking the first step is really what Organic is all about -- most people are wary of jumping on board with a new framework, or a specific style of coding, or even a new language at this point if what they are using truly meets their needs. It seems like every time we turn around a new framework is gaining popularity, threatening to unseat the current king of the mountain due to a faster or more efficient way of getting the job done.

However, talk to some programmers who have been around for twenty or thirty years, who have been through the evolutions, and who have been through the revolutions, and who understand that while design patterns and object oriented programming are the buzzwords of today, they are rooted in best practices that were established decades ago by people who had virtual toolboxes a tenth of the size of what the average programmer has at their disposal in this day and age.

And that's part of the problem. The programmer of today has too many options, too many tools, and while having options isn't necessarily the problem, having a lack of wisdom in choosing the correct hammer for the job when presented with five is usually the issue.

If I were a gardener, it would be like going into my shed to get a trowel, and instead of reaching for that old rusty trowel that I know gets the job done, I would have eight trowels, some new, shiny, and never used, to choose from. Which one is the best to use for this particular job? And what if it was a special sort of tool that INCLUDED a trowel? A sort of "integrated gardening environment", or IGE (tm) that attempted to not only solve my trowel-ing problem, but also my raking, and my pruning ones like some sort of huge Swiss Army knife? At most I'd probably end up with a tool that is able to handle these responsibilities in a mediocre manner. At worst, well, how many utilities have YOU tried playing around with for a couple days only to come to the determination that it's a worthless piece of junk? But, I digress...

Back to taking the first step: It's important to understand that Organic application development isn't a framework, and it's not a language. It's a methodical approach to writing software for your organization which is three things: straightforward, future-conscientious, and quick to release.

Taking the first step toward growing an Organic model really means that you have to do nothing more than accept the fact that you don't need frameworks, you don't need crazy utilities, you don't need special languages, you don't need any of it to create something amazing for your organization What you need is your brain -- a whole lot of your brain -- so dump the useless programming junk that is slowing you down and make some room for a new way of thinking that will turn you into a programming warrior...er, gardener...

Saturday, December 30, 2006

This garden is growing...slowly

Haven't been posting as much as I want to -- spent a lot of time this year thinking about Organic, though, and how it really seems like the M-Theory of programming to me. It's such a cool concept, and it just amazes me that everyone I talk to seems to be SO close to making the jump, yet there's always something that people just can't seem to grasp. If I could just figure out the missing link, I could explain it all so easily. I guess it will come out as I post more of my thoughts.

Speaking of thoughts, here's a good one: What gets me about Organic is that it's based so much on actual organizational structure, which is why the term "software modeling" makes so much sense in this regard. I think about concepts like SOA, BPM, and structural cybernetics (see NDMA, Inc. for more info on that), and how Organic ties these ideas and more together in a meaningful amalgamation of thoughts, rules, and information.

It amazes me...

Technorati Profile

Thursday, July 06, 2006

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...

Monday, July 03, 2006

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!