Log In
E-mail or User ID
  Keep me signed in
Recover Password
Create an Account

How Much Perfection is Enough?

When it comes to engineering design and architecture, how perfect is "perfect enough"?


I was recently asked to adapt a software product I designed in one architecture to another, different architecture.  The tool itself is designed to extract data from an application database, transform it, store it in its own database and then manipulate/save it.  These key functions have to remain in place.  But instead of working in a single application database, it has to integrate with a multi-tenant databae and application.


It's a big change.


This caused me to stop and think about how to go about it.


My first thought was to leave the existing application alone and just re-code the extract portion to plug into the multi-tenant architecture.  This has the advantage of not needing to recode the entire application.  I think there is a virtue of having the same application work in both settings.  It minimizes the split code base and keeps the user interface the same all the way through (and I happen to be proud of the user interface). 


But this leaves me perpetuating the "old" architecture.  I'm sure if I were to go talk to the engineers and developers, they would be offended that I would leave the old in place.  It's not tecnically elegant - althought it is financially elegant.  I would say that this is very efficient, but technically very imperfect.


On the other hand, a complete rewite would be nice in that all the lessons I learnded the first time could be resolved in a much more elegant fashion.  I know of some database design items that I would do differently based on the new understanding of how the total application has to function.  It would also mean that the new application would fit in much more nicely in the user experience of all the other applications that would use that architecture.  


This is the classic connundrum of trading off purity for dollars (or pick your local currency).  The more I do from a development perspective, the more the application costs yet the more I can sork through all the issues and come up with a uniifed solution (so the user doesn't have to).  


This made me wonder what kinds of things the community would say.  I know someone will pipe up to ask about the requirements determining what is needed and sufficient.  That's true.  But I could meet the requirements with either configuration.  At least all the functional requirements.  The deeper question is how much I want to pay for the requirement "All systems shall conform to a standard reference architecture."?


Have you run into a similar problem before?  What did you do?

Read 2 comments



Definitely a classic quandary. In the end there is one over-riding rule: if it's not bust don't fix it.

Reason: if, in engineering terms, the result is exactly what is intended, and the app behaves itself every time, then, irrespective of the engineering details used to achieve the app, as far as the user is concerned, that is all that matters. It does what it says on the tin.

Furthermore, quite often, a later opportunity arises which enables the incorporation of the current thinking and techniques. So, there's no need for self-criticism when such situations occur.

This is a tough one but I would go with the safer option. If the "old" does the job well, functionality and performance-wise, and you don't anticipate a requirement to change/upgrade it in the near future, then keep it.

A complete rewrite would be nice but scope creep is not.. and that's a definite risk.

If it isn't broke, don't fix, mess with, or go near it!

Leave a Comment

Connect to this blog to be notified of new entries.
You are not logged in.
Sign In to post unmoderated comments.
Join the community to create your free profile today.
Archive Category: blog
Keyword Tags:  Software Architecture

Exploring life as a Digital Citizen
Receive the latest blog posts:
Share Your Perspective
Things To Do
Subscribe in a reader
You Might Also Like
SDN: There's An App For That
MIT highlighted Software Defined Networking... read more