Contribution 0

From WikiContent

Revision as of 04:04, 10 May 2008 by Rmonson (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Today's solution is tomorrows problem

No one can predict the future. If you accept this as a universal truth, than the question becomes how far ahead is the future? One decade? Two years? Twenty minutes? If you can’t predict the future than you can’t predict anything beyond right now. This very moment and the ones that preceded it are all you are know until the next moment occurs. This is the reason we have car accidents – if you knew you were going to have an accident on Thursday you would probably stay home.

Yet we see software architects try to design systems that will be, for lack of a better term, "future proof" all the time. It’s simply not possible to future proof an architecture. No matter what architectural decision you make now, that choice will become obsolete eventually. The cool programming language you used will eventually become the COBOL of tomorrow. Today’s distributed framework will become tomorrows DCOM. In short, today’s solution will always be tomorrow’s problem.

If you accept this fact, that the choices you make today will most certainly be wrong in the future, than it relieves you of the burden of trying to future proof your architectures. If any choice you make today will be a bad choice in the future than don’t worry about what the future will hold, choose the best solution that meets your needs today.

One of the problems architects have today is analysis paralysis and a big contribution to that problem is trying to guess the best technology for the future. Choosing a good technology for right now is hard enough, choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now because anything else will not only be wrong choice tomorrow, but the wrong choice today.


By Richard Monson-Haefel

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools