Sometimes putting into words the practices you use can expose obvious flaws where you need improvements and provide a starting point for introducing new practices in to your development. Analogies are often used to express sometimes foreign, sometimes complex ideas by bringing them in to a realm that is familiar.

Idea My development is fueled with an idea. The idea sometimes bad, sometimes good, and rarely great, but nonetheless this is where I start. The idea usually stems from a problem. I want to be able to do Foo or I’d really like if Bar was able to do this.

What ever it maybe, I think it is important to take the time to outline your idea. Give yourself some initial requirements. Give yourself some structure to build on. You need a solid foundation for a project to be seen to completion and even with that, most fail to make it.

Now don’t get me wrong, I am not saying you need a full set of business requirements with risk analysis, input from legal, hiring a marketing firm to ensure there issufficientmarket share to capture to justify the risk of development. I am just saying you need to have some kind of outline, some set of initial requirements, your motivation. They are easy to create and it only takes a minute.

Once it makes it past the idea stage, it means I’ve written down on paper. I’ve created a loose set of requirements for the project and I still think it is a decent enough idea to continue.

Design The design process is unique beast. There is plenty of reading material out there about design and about architecting software. I am by no means a great architect. I know enough UML to not be confused by it, but I couldn’t punch my way out of a wet Visio box.

My approach to design is brief at best. I hop a plane to 30,000 ft and look around. I make some notes of that obvious things I see. Oh look a Factory Pattern, oh look a white fluffy Strategy pattern, hey that skyscrapper looks a lot like a Reactor pattern and that lake looks like a Facade. I like patterns, even though some people seem to think they hinder innovation and developers coming up with new awesomeness. I make some notes and polish my lead balls to ensure my development compass points North. That is it.

As a rule of thumb, I try to spend no more than a day on this phase. Depending on the scope of the project and the requirements you may require more or less time, but that is really up to your gut. As soon as you feel comfortable laying down code, start laying down code.

Now The Analogy -GrowingSoftware. I am a giant fan boi when it comes to test driven and agile processes, I mix and match the different processes to meet my needs. My favorite anology I use to describe my process of what I like to call organic development, involves growing plants. I am sure the term organic development already exists and means something completely different, but I don’t care, I like it for this.

• Idea - Decide you want to plant something and read up on what you’re planting.
• Design - Sun? Shade? Raised bed?
• Coding - Watering,fertilizing, repotting and transplanting.

So with the idea you read about what you are planting. You look at maybe some other people who have planted the same type of plants and read on their experiences if they are available.

Now the design. You pick out your pots or bed type. Decide if you are gonna usenaturallight,artificiallight, how much water and they type of delivery mechanism? I hear they have these cool water globes now!

Now you can plant the seed. You water and weed and as your plantgrowsyou prune, stake in supports, and continue to care for it until it comes to bare.With the proper care and handling you can produce a healthy, beautiful, lowmaintenanceplant.

Keeping with this software is a plant analogy, somethings to watch out for. Water too much you run the risk of killing your plant (developer burn out). Prune too much and you can kill it (premature optimization). Basically in the early stages of a plants life mistakes can easily kill it I think this is very similar to software.

As your plant takes root it becomes easier and easier to maintain. Things like transplanting, ripping a plant out to the roots andreplantingin a new bed are risky, but if done right, can produce a larger, healthier plant. Like software, sometimes completely gutting a prototype might be the right thing to do, but you increase the risk of killing the project.

But also plants, like software, can be very forgiving as long as you catch the the fact early that you are giving your plant too much or too little of water, pruning, fertilizer, soil to grow in, etc… you should be able tosalvageit. Though it will take more work and time, with extended care an over or under watered plant can be saved from the brink of death with a little time investment and care. But sometimes there is nothing you can do, like an over pruned Bonsaitree, once the damage is done, even if you continue to grow your plant, it will never feel right for many many years.

So anyway, that is might crazy, abrupt, all over the place abstract take on software. What’s yours?

On a side note, an email commenter Linda requested I have more pictures in my posts so this one is for you Linda.