Unfortunately lot of business people do not understand this, nor do they believe this when others tell them so. Changes are inevitable and important for growth, but even the smallest change has the potential to cause the biggest havoc in your system. Why? The software engineering principles advise us to reuse the code we write. This helps us avoid duplicate code allowing us to code less and maintain it better. But this also means that we build a chain of dependencies which link different pieces of the software together. This means that if I change the code, its effect can reach out to multiple parts of the software. And if that happens unintentionally be sure that some change has introduced a lot of bugs in the code.
Does that mean that we should not change code at all? No, it means that we have to realize that change is expensive. Lines of code is the wrong measure for changing code. Look at and try to anticipate the impact that the change can make in your system. The tests are then not dependent on the change itself, but on this impact. Wider the impact, more the number of tests that you should run to make sure your change is not causing unintentional behavior. When you do that, the change is expensive. It is expensive in terms of time, effort, money and sometimes friction with the users.
That is the reason changes should not be based on one’s whims and fancies. They should rather be backed by reason and facts. They should be planned for and given enough time. Otherwise they can be more expensive, in terms of business and reputation. One of my friends experienced this when his manager changed some code minutes before a live demo. Needless to say that the demo failed and the cause zeroed down to the fatal change. A demo, which they had done a test run with innumerable number of times, just failed.
Sometimes there is also a misunderstanding. With coding philosophies getting a lot of attention even in the management circles, they think that simpler code is easier to change. No. Simpler code makes it easier to find out where the change should happen and what its impact would be. Simper code can also help us write better tests, the changes will always be expensive, because they are not just about the code.
A lot of software companies have realized this, and they provide a test suite along with the code that they handover to their customers. But tests do not get equal respect, they get ignored, and changes are taken through. The only way to check that there are no unexpected effects of the changes is through tests. Tests will not tell us whether our code is right or not, but they will help us gain sufficient confidence and experience that a user might have after the changes.
Never consider a change as a line of code. It is a change in the software behavior, which carries a lot of importance in your clienr’s everyday life. Changes are expensive, and damn expensive if you do not respect them.
December 10th, 2007 at 6:31 am
[...] Changes Are Expensive, Damn Expensive [...]
December 11th, 2007 at 11:40 pm
Have you given any thought to documenting (in a parseable manner) this chain and determining when it is broken? I understand that tests can effectively do this, but I like the straight-up approach more. The result is that instead of getting a generic error about a column in a database table not existing, you get a schema validation failure that tells you exactly what was expected that was not found.
A major advantage I can see is that you can have your dependency chain depend on other dependency chains. Let’s say your application depends on SQL Server’s Fulltext indexing, which allow for “AND” and “OR” in text searching. Instead of just a generic “fulltext” error, would it not be much better to see something that says “Component X depends on MS SQL Server’s full-text capabilities, which are failing due to a permissions problem of XYZ, which is usually resolved by QRS.” This, of course, assumes that other people make dependency chains as well, but one has to start somewhere.
December 13th, 2007 at 2:24 pm
[...] Saw another interesting post over on DZone aptly titled Changes Are Expensive, Damn Expensive. [...]
December 14th, 2007 at 10:36 am
Luke, I agree with you that we can do our utmost to make sure that dependencies are loosely coupled and are documented well. Or, like you said, making them validate. The program to an interface paradigm or best practices like MVC are all about that as well. Still, that does not reduce cost of the changes. It can help you identify where to change, and make the actual change quicker. But impact of the change is still going to be there. If we change something in the core, or if the interface changes we still have to carry enough tests to make sure that all the impacted pieces are still working, or working right.
In my opinion, whatever we do to make the changes easier, it is going to be for us to actually make the change. The cost of a change though is more because of its impact on the system. Changes are still going to be expensive.
December 14th, 2007 at 3:16 pm
[...] of the reactions to my post on changes being expensive hinted and some explicitly said that Agile Development and Test Driven Development can make changes [...]
December 19th, 2007 at 5:09 pm
[...] more, problems change, there are requests and suggestions, and the code evolves. These changes are expensive, but good code can help in making these changes easier. It can help the application evolve [...]