authored by Wayne Witzel III

My Software Analogy

On April 29, 2009 In how I develop, design Permalink
unrelated-picture Sometimes putting into words the practices you use can expose obvious flaws where you needimprovementsand 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. plants-tell-me-fings 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. EDIT: Fixed the strong tags. WP decided to do something weird with the formatting. Also fixed some typo's.
Read and Post Comments

Fat models, skinny controllers

On October 05, 2008 In python, design, pylons Permalink
In the world of MVC and RESTful services, the old addage fat models, skinny controllers is something I'm sure you've constantly seen and read about. So what does it really mean? How do you benefit? Is it the silver bullet for MVC development? What are the draw backs? Using the latest versions of Pylons and SQLalchemy (0.9.7rc2 and 0.5.0rc1 respectivly) we can implement this methodology pretty easily. We'll use formencode schemas to handle the basic input validation and then keep our business logic in the controller itself. Here is what a controller method using this concept might look like. [sourcecode language='python'] class MemberController(BaseController): def __before__(self): if session.has_key('memberid'): c.memberid = session['memberid'] @validate(schema=model.forms.schema.SubscriptionSchema(), form='new') def create(self): subscription = model.Subscription(c.memberid, **self.form_result) meta.Session.commit() return redirect_to(controller='member', action='account') [/sourcecode] The schema validation affords us the luxury of being able to just pass our data directly to the model. The __before__ method checks the session for the memberid assigned at login and gives us access to it, further keeping our method nice and clean. The model would implement the business logic, in this case since this is creating a new subscription, it would just sum now() and deltatime(days=days) to determine the expired. This model could later be expanded upon, say for example you added an upgrade methods to your controller. Now, the same subscription model could be used with some added logic. The model could now have a static prorate method to expire the existing account and make room for creating the new subscription. I've pushed the example source to my github, hopefully this will get your brain juices flowing. If I get bored, I'll toss together a complete working example and check it in. Source for this post can be found at
Read and Post Comments