It seems in the last few weeks we have been struggling with the concept of change. Not with us internally but our interaction with clients. Sometimes when you are programing stuff things change and new information presents it’s self and you might want to go back and redo things. For example you might have made the decision to have some sort of javascript error checking solution to validate your forms. After a while your forms have different requirements or needs and your javascript validation is not the best way validate or becomes very complex. Maybe it is time to go back a few steps and do some sort of back-end (maybe php) validation solution. While this is a simple example there are many cases where programers just continue to build on an original design after realizing the design might be flawed. I hear over and over again “We will fix that when we have time”, or “We know we are going to have to redo the site in a few years away we will address it then”. We feel this is flawed thinking.

When issues like these arise there are always 3 major problems to look at in the course of stepping back and redoing work.

• We bill hourly and we would break our bid if we redo our work.
• We have a deadline to meet.
• We are bored of this area of the site. To stay sane we need to move on.

While the last problem is a tough one to deal with, I can address the first two problems. If you have a bad design because of scope creep, meaning your client added things which changed your preference on how something should be coded or designed. Break out the problem, put it in layman’s terms, and explain. We find 75% of the time the clients understand and are happy to pay the change order. The other 25% of time, after a while the client realizes what you said and asks you to make the changes anyway. If your redesign is well founded it will get done one way or another in many cases.

Now, if the poor design was your fault, meaning you just overlooked something and did not do your best work designing the code base. Step up to the plate. Tell your client what happened, don’t bill them the extra time in exchange for them agreeing to push your deadline out. It sucks! You have to do free work now but at least you have a product to be proud of and a product that when you add future features it is robust.

On your own internal projects this stuff happens too. So many times a new concept or feature is presented to us half way through our development cycle we want to put the feature in but it does not work with our current code base. Don’t let it go. Stop, redo and move on. Crappy code turns into even crappier code that turns into even crappier code. Think about it as a snowball!!

One resent example. We have been developing a product for a client for over a year now. We used our own custom php framework. This framework really works well for us but an outsider coming in might have a tough time understanding it. Our client wanted to bring in other sub-contractors. We knew this was going to be an issue, so we explained it to our client and after going back and forth for a bit we moved our php framework to Codeigniter, which is a framework most php programers understand and can start working with. This decision slowed down progress for about a month, costed our client more money, but now we have the flexibility to bring new people into the project and have less of a training period.