Softwares Category: Softwares - Page 6 of 56

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.

'Coz sharing is caring

On any project that is in production (i.e. it has customers that are using it), there will come a time when a change must be made; either a bug needs fixing, or a new feature must be added. At that point there are two possible choices; you can take the time needed to “do it right”, or you can take one or more “shortcuts” and try to get the change out the door sooner.

Generally,the business people (sales/marketing and customers) will want the change made as quickly as possible while the developers and testers will be more interested in taking the time to properly design,implement, and test the change before delivering it to the customers.

As the project’s architect you’ll have to decide which makes more sense and then convince the decision makers to take your advice; and as with most architectural issues there is a trade-off involved. If you believe the system is reasonably stable then it may make sense to go the “quick and dirty” route and get the change into production quickly. That’s fine, but you need to know that in doing so your project is incurring some “technical debt” which must be repaid later. Repayment, in this case, means going back and making the change in the way you would have if you’d had the time and resources to do it right the first time.

So why the concern over making changes properly now versus later? It’s because there’s a hidden cost to making these quick and dirty fixes. For financial debts the hidden cost is called “interest” and most anyone with a credit card knows how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked in changes, the lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid.

Now that you understand a bit more about the true cost of technical debt, you might decide the price is too high and you can’t afford the cost. But when it’s a choice between having the developers get the fix out as quickly as possible or taking a severe financial hit, it generally makes sense to get the fix out quickly. So take the hit and get the change into production ASAP, but don’t stop there.

Once the fix is in production, have the developers go back and fix it properly so that it can be included in the next scheduled release. This is the equivalent of charging something on your credit card and then paying off the balance at the end of the month so you don’t get charged interest. This way you can provide the fast changes the business needs, while keeping your project out of debtor’s prison.

'Coz sharing is caring