Bhabishya Kumar

What if a column name in a core database table gets changed in the future? What if the name of our core business entity gets changed in the future? What if the labels in the jsps get changed in the future?

I keep hearing questions like these, mostly in design meetings. It seems people are more worried about an improbable effortless future change than current functionality. And I think this leads to over-designing of bad software.

Another example of this over-designing is multiple layers of unnecessary abstraction. People take the idea of least coupling to such an extreme that it seems like one component has to take a trip around the world to talk to another component in the same software! I think their formula for good software is “Limit n tends to infinity” where n is the number of layers in the architecture.

I am not advocating design for present without any concern for the future. I think there should be a balance between Convention and Configuration. Rails ideology of Convention over Configuration was one of the first things that got me interested in it.

And why be so scared of change? If we were capable of visualizing and handling all the future changes then Martin Fowler would have never written the Refactoring book and IntelliJ Idea would have never added Refactor menu item.

People try to do too much with their software. It seems they are trying to achieve “World Peace” and solve “Global Warming” through their software. Lets leave that to Miss Universe and Al Gore.

What if all the code that people add to their software to prepare it for the future makes it so complex that no body uses it in the present.