20100419

Getting Better by Giving Less...

                One problem that many people face is giving too much to their goals and projects.  We create one small goal for our project, or our game, but then we sit down for an hour and really think it through.  Every “good” idea we run across becomes part of the final project.  And you start to realize that the first draft of the projects financial needs are in the millions. 

                Bloating is one of the most common causes of failures in a project.  Even if it had another fault.  Imagine throwing similar resources at a smaller project, or developers, architects and testers time line differences, when the project is not only smaller, but simpler as well.

                This is all “fine and dandy” but how do we actually apply it?  I’ve understood this principal for years, but haven’t been able to figure out how to apply it until recently.  Whenever I would start building a game, I would try to start small, but the architectural excitement factor draws me in.  It is exciting to keep adding more, and unheard of to remove the things you come up with along the way.

                So here is what I have started to do with my plans.  I give in to my need to design awesome architectures and super simulations, and design full blown systems that I will eventually decide are too complicated.  Then I simplify them.  I start to cut out all the crap I don’t need.  In movie editing, they have a phrase, “you start cutting with a scalpel, and finish with a sword”  I reverse this.  Start with the sword.
               
                In fact, skip the sword and start with a rescue squad.  Salvage what you can.  Pick the most important part of the application.  Then the next couple of items, and rank them.  Next, reconsider what you really need to accomplish that. 

                I have this bad habit of wanting to rent servers instead of websites, whenever I start building a site.  If I were to get a server, my options would open up more.  I would have so much more available.  But do I need it?  I’ve never run more than 4 sites at a time, and site hosting VS. a dedicated server is a whole decimal less in cost. 

                Its not cost effective, it created more work, and I ultimately got less done.  So this time, I’m considering a site again, but I’m only considering Hosting a single site.  I’m paying 1/10th the cost, and I have less of the stress.  I’m not dealing with fail over systems.  I’m not dealing with security.  I’m not dealing with Maintenance.  Huge amounts of the work are cut out, because I’ve decided on a course of action that accounts for the minimum requirements to get the same end result.

                The Same end result?  I cut my cost by 90%, my time by 50%, and my work load by even more.  I’m considering exactly what I want the consumer to see, and what EXACTLY is needed to provide it.  I’m also considering what I have tried and failed at.   What’s the last LARGE project I’ve completed?  None.  When I let my projects bloat, they fail, not from complexity, but from neglect.  The potential stress of trying to get it to work, makes me rebuild it from scratch or just move on to another project entirely. 

                One of the reasons many of us get into programming or game design, is because we see things as they are and want to add to it.  Whens the last time you’ve played a game and said, This would work better if it had this…  When is the last time you played a game and said, This would work better if we cut this feature out.  Its easy to cut out obviously annoying things, but what about things that don’t really help the end goal of the game?  What if we were playing in a game with wavy grass, where the grass images came from 256x256 motion tiles, instead of 512x512.  Would we really see the difference.  The second takes up 4 times the resources, and the end user might not even notice. 

                So, take a recount of past projects, and consider what the last project you designed was that bloated, and was it successful?  My advice is this, start small, stay simple and then scrap all the requirements that don’t help the ultimate goal of the project.

No comments: