Imagine – you are the CIO involved in a merger.  Your company has applications, and the company you are merging with has a similar set of applications.  And the due diligence team from Big 4 Corp that the Big Investment Banking Sachs hired to decide which IT functions are going to survive is showing up in 3 weeks.  What is more important?

a.) The internals of the application is perfect, the UI is so-so (and who cares right, the UI is just a css file), and the data model is something oriented towards your object model (i.e. something that db4o generated, or something that is oriented towards use with NHibernate).  Or better yet, you use some fancy OODBMS that, while nobody has really heard of it, is clearly technically superior (har, har, har)

b.) The internals of the application consist of typed data sets being managed by a static class with accessors (ugly, hackish, but servicable) – but the UI is fabulously designed and intuitive… almost sexy.  And while the “procedures“ in the one static class have bad structure, they do, I don’t know, some calculation or other really useful trick that is very meaningful from a business perspective.  The DB schema is easy to generate reports from (i.e. you don’t have to write something in SQL reporting services that links with objects and custom assemblies – not that doing something like that is hard, but for non-programmers.. might be too much to ask).

I would guess “B“.  “A” might matter if we thought Big 4 IT due diligence teams were really good at knowing modular programs from hackish ones.  But for the most part, and I may be going out on a limb here, but the IT due diligence teams that investment banks who do M&A work hire tend to be people like the “contract IT auditor“ for a Big 4 company – being nice – not the kind of people that would know a well designed object model from their elbow.  Often – the biggest hurdle will be that you pass some checklist, which will usually say “uses big database“, and in the best case, will say “no SQL injection vulnerabilities“.  Having worked for that kind of company in the past, I can say that detailed code review is not their strong suit.  And even if it were, the window of time required for due diligence in most big M&A transactions is way too short for that kind of review to take place.

What I am not doing is advocating the idea that quality does not matter.  It does.  A well designed set of application internals will allow you to make quick changes once you consummate the transaction.  But – if you have chosen well designed internals over polished UI and distinguishing features that set you apart, you lose, since you will be discarded before your “great modular opus“ gets to see the light of day.

So – to the thesis – if forced to choose between the sexy UI and the well designed internals (i.e. well designed, as in elegantly designed object model that, while taking longer to write, pays off in the long term maintenance) … choose the sexy UI.  By taking out the technical mortgage, you gain leverage needed to make sure you can outlast your competitor in the initial decision phase, after which, you will have more than enough time to pay off the mortgage afterward.