Some years ago, Harlan Mills proposed that any software system should be grown by incremental development. That is, the system first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below.
…
Nothing in the past decade has so radically changed my own practice, and its
effectiveness.
…
One always has, at every stage, in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
-- From "No Silver Bullet" [Brooks 1995]
Tuesday, August 21, 2007
Wednesday, January 03, 2007
The Consistent Gardener
How is it that some gardens flourish year after year, full of lush vegetation and bursting with colorful flowers, while others seemingly strain to make it through a single season?
I've always found it interesting that those strangled, dying bunches of vegetable matter can also be some of the most-tended to plots of land around. How is it that someone can pour SO much energy into something that clearly is just not going to make it?
One word: consistency
People typically say the root of the problem is inexperience, or lack of foresight, or possibly even flat-out stupidty. However, when you really drill down to the true reason for a broken green thumb, it's a lack of consistency. A bug popped up because you took a shortcut in that presentation template. You're seeing odd behavior because you didn't perform an assertion on the response data from a remote invocation. Someone on your team caused a Cartesian product to be calculated because they tried a new type of join syntax. And so on...
Consistency means applying the same amount of energy to the care of each individual plant. It means pouring the same amount of water, pulling the same amount of weeds per square foot, and harvesting your crops at the same level of ripeness. Consistency means having a disciplined mind.
Failed gardens aren't the result of a lack of intelligence, or a lack of a growth plan, or a lack of care. They are the result of an imbalance in the amount of energy expended on any one component of the system. They are the result of a lack of consistency, which is itself a result of a lack of discipline.
An undisciplined gardener will never succeed because their inconsistent behavior creates an environment that is rife with uncertainty and stress, and plants can't stand stress.
So how are your plants looking right now?
I've always found it interesting that those strangled, dying bunches of vegetable matter can also be some of the most-tended to plots of land around. How is it that someone can pour SO much energy into something that clearly is just not going to make it?
One word: consistency
People typically say the root of the problem is inexperience, or lack of foresight, or possibly even flat-out stupidty. However, when you really drill down to the true reason for a broken green thumb, it's a lack of consistency. A bug popped up because you took a shortcut in that presentation template. You're seeing odd behavior because you didn't perform an assertion on the response data from a remote invocation. Someone on your team caused a Cartesian product to be calculated because they tried a new type of join syntax. And so on...
Consistency means applying the same amount of energy to the care of each individual plant. It means pouring the same amount of water, pulling the same amount of weeds per square foot, and harvesting your crops at the same level of ripeness. Consistency means having a disciplined mind.
Failed gardens aren't the result of a lack of intelligence, or a lack of a growth plan, or a lack of care. They are the result of an imbalance in the amount of energy expended on any one component of the system. They are the result of a lack of consistency, which is itself a result of a lack of discipline.
An undisciplined gardener will never succeed because their inconsistent behavior creates an environment that is rife with uncertainty and stress, and plants can't stand stress.
So how are your plants looking right now?
Monday, January 01, 2007
All good things come to those who wait, Grasshoppah...
Organic Lesson #1:
Have patience.
Taking the Organic approach to building applications for an enterprise means slowing down, breathing in and out, and looking at the big picture. This isn't to say that Organic application development can't happen quickly -- it just means that one thinks before one does.
What exactly does that mean? It means that an Organic developer doesn't comment her code -- she codes her comments. An Organic developer doesn't build an application -- he applies a solution. Organic developers don't *tell* objects to do anything -- they *ask*.
There's a difference.
Organic application development is an attitude. It's an approach. It's a way of looking at problems without frustration, or rush, or trial and error, or blindfolds, or dartboards, or anything that drives people positively nutty when it comes to software development. And it's most definitely NOT new.
Organic is smooth and efficient. It's elegant and effective. It's that patient, relaxed feeling you get when you're the only one in the garden in the middle of the day, watering the plants, tending to the weeds, turning the soil over in your hands, knowing that you've got a great bed of soil, the sun is high in the sky, and the only bugs you've got are the good ones you've put in place to keep the bad ones out.
Organic is ahhhh, plain and simple.
Until next time, Grasshoppah...
Have patience.
Taking the Organic approach to building applications for an enterprise means slowing down, breathing in and out, and looking at the big picture. This isn't to say that Organic application development can't happen quickly -- it just means that one thinks before one does.
What exactly does that mean? It means that an Organic developer doesn't comment her code -- she codes her comments. An Organic developer doesn't build an application -- he applies a solution. Organic developers don't *tell* objects to do anything -- they *ask*.
There's a difference.
Organic application development is an attitude. It's an approach. It's a way of looking at problems without frustration, or rush, or trial and error, or blindfolds, or dartboards, or anything that drives people positively nutty when it comes to software development. And it's most definitely NOT new.
Organic is smooth and efficient. It's elegant and effective. It's that patient, relaxed feeling you get when you're the only one in the garden in the middle of the day, watering the plants, tending to the weeds, turning the soil over in your hands, knowing that you've got a great bed of soil, the sun is high in the sky, and the only bugs you've got are the good ones you've put in place to keep the bad ones out.
Organic is ahhhh, plain and simple.
Until next time, Grasshoppah...
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...
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
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...
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.
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!
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!
Subscribe to:
Posts (Atom)
