Welcome to Particletree!

The other day Chris brought up the sunken cost theory, and how you should not be attached to the past regardless of how much time was put in. If a new solution is available for the future that will make things more manageable and efficient, then you should consider reworking your code to accommodate the better approach. Now, the tricky part is in evaluating the proposed change, and determining if it actually is worth altering your existing code in favor of better methodologies. Why is it that we decided to start implementing Smarty and a reworked URL structure in our project, but aren’t in favor of a new language or a new JavaScript library? Here are the factors we take into consideration:

When implemented, will the new change …

• ease development? We look at the amount of bugs reduced or created along with how easy the code can be updated/expanded upon after the change. Also, a big factor is whether or not this feature separates the code out more, so that it becomes easier for multiple people (designer, coder, etc) to modify their appropriate sections.

• increase scalability? Certain changes can make page loads faster, decrease database hits, or eliminate redundancy. Anything in this department is always a plus, but it is usually not needed urgently. If the program is fine how it is, changes of this nature can wait until about a month or so before the anticipated scaling problem happens.

• be noticeable to customers? Will customers notice a change? Sometimes, as with a new JavaScript library, customers won’t notice anything happened. Months could be spent implementing a feature and customers will perceive nothing improved on the product during that time. One of the many reasons we decided to use Smarty and a new URL structure is because they benefit our customers immediately. Smarty offers caching, which leads to a more responsive interface. URL’s allow for predictable destinations and file locations.

Likewise, is the change driven by …

• personal attachment? Personal attachment can be good because it means you are passionate about an idea, and are likely to see it through properly. But when determining new features or code, you have to be cautious here. I may personally love one JavaScript library over another, but that doesn’t mean I should eliminate all of the hard work put in with the first library. Personal attachment is a big red flag to watch out for — be cautious when deciding to implement something if this is the driving factor.

• an existing flaw in the program? If something is broken in the program, and a change is proposed because of that, then we are likely to implement the change. The old code was obviously bad, so nothing is lost replacing it in favor of a new method.

• a desire to do better? Most of our proposed changes are just a desire to have modern, fun, efficient technology in place. Implementation of these features is usually 50/50. If the process being replaced is critical and heavy on the logic, then we probably won’t introduce the change because of the amount of bugs that could surface. In other situations, these changes are usually fun and not too hard to implement.

And lastly …

• how is the change implemented? Does it take 1 person, or the entire team to implement? Will new skills need to be learned in order to implement the change? And most importantly, can the change be implemented incrementally, so that one portion of the program can be changed without affecting all of the others. That way, a gradual, conservative approach can be taken.

Examples

The following are just a few of the changes in Wufoo that we have evaluated:

• Form Builder - This bad boy has been rewritten 5 times, and is about to go for numero 6. Not only is this the core of our program, but the when evaluating this change you will find that it satisfies all of the requirements listed above. Actually, the only downside to continued improvement in this area is that it takes 2 of us about 3 weeks to polish up.

• Payment System - Chris has a personal attachment to the payment system. He should considering he spent a 60 hours/week for an entire month working on it. To the eye, and to an developer besides Chris, the code may look a bit ugly, confusing, and hard to maintain. But it works, and it is a core piece. Even though Chris would like to see it rewritten, it is not worth the time and potential bugs introduced to such a critical part, especially when the customer would never notice.

• Smarty - One day I was feeling ambitious with the desire to do better, so I looked up Smarty. At first, it was fun because it was something new to play with. Upon further testing, we found that the separation of layers and the caching both eased development and would speed things up for our customers. Also, it was something that could be implemented on a page by page basis, so no hard timeframe had to be spent, so we decide to start using it.

• Server Side Graphs - Right now we generate graphs with Flash software. We’ve thrown around the idea of switching this to server side graphs because Flash graphs do not print well. This is both a desire to do better and a noticeable improvements for customers. The problem is that what we have works nicely. For now, the decision to switch this is in limbo because we feel there are more important things to work on. This is a good example of a change that is tough to decide on.