Programming

Although I agree with the intent, I do not agree completely with this statement. The intent is that a programmer should not waste his/her time putting stuff in that is not going to get used. This is really important because time is money. Often there are penalties based on late delivery. Also, there is the matter of wasted employee wages. On the programming side of things, there is the potential extra risk. In some cases this part can easily be the project killer. The fact is, the more code you put in, the more risk there is of it not working.

I do believe that this is a good philosophy, but often it is misused. Just like everything, you must use it where it makes sense. Programming MUST NOT be a rigid process. A programmer should never step outside of the design. This means that if you want more than what you need right now, then you must include it in the design. Now the big question … why would you want to put more in than you need? Let us say that the customer has requested a feature that you do not have. Let us also say that while in discussions, it was apparent that the customer wanted to take this feature down a specific path in the future, but was not willing to wait until then for the feature. When designing the feature you discover that to do only what is needed right now would take you down a different path than where the customer would like to take it. Unless the original feature is VERY small, it might be wiser to design for the future. This does not mean that you have to add all the additional stuff, but just that you make the original feature able to accommodate for the future.

It can be argued that, well the customer is going to pay for the updates in the future anyway, we can just make sure that our estimate for the future additions accounts for the rewrite required. I guess if you want to be a corporate scheister, then go ahead and treat your customer that way. My way of thinking is that that sort of behaviour has a way of biting you in the ass.