Geeks With Blogs
Joe Eames Arbitrary Randomness

I was recently discussing some common flaws in application architecture with David Adsit ( about wisdom in development.

Have you ever looked at a system and seen somethings done that were either technically or procedurally difficult, and thought, "wow, it must have taken a lot of work and a lot of proficiency to get that done" but then said to yourself, "but doing it was a bad idea".

One of the things that experience teaches that you don't get to pick up from simply gaining technical know-how, is what most people would call wisdom.  But that word has a lot of interpretations.  So I am proposing a a formal definition:

Technical wisdom: Knowing why a particular solution is a bad idea even if you are technically capable of implementing the solution.

And this is a concept that is very closely related to technical debt.  When someone takes on debt in the real world, they hopefully are applying wisdom in that situation.  Just because you have a good credit rating and can make the payment, doesn't mean you should buy something.  That principle applies to technical debt as well.

Yet it also transcends technical debt. Sometimes we are tempted to implement a technically difficult solution that is in the long run a bad idea.  It will cost us too much in complexity, maintenance, risk, brittleness, etc.  DB languages are a great example of that.  T-SQL and PL/SQL.  Those are languages that not everyone knows well.  Coding up a super fast stored proc that solves a problem quickly in the db can seem tempting.  It localizes the solution, keeps it where it's fastest, and can be quick to code up.  And this doesn't even mean it's technical debt, i.e. you didn't choose a PL/SQL implementation because it was the easiest solution now, but something you knew you had to repay later.  It may be what you thought was the most difficult solution but you chose it for some other reason:  performance, security, or anthing else.  Technologically it seems like a good idea.  But in the long run, db language solutions are almost always a bad idea.

How many great db language debuggers are there?  How easy is it to TDD a stored proc?  How about maintaining an automated test suite?  What about Mocking?  How many people will know the language well enough to maintain it?  What does it do to your scalability?

It can be so tempting to implement a solution that is technically challenging either because it's fun, or because it's the fastest solution now, or it's the most performant solution.  But the wisdom of knowing that you should choose a different solution, (in our example a straightforward middle tier solution in Java or .NET etc) is what constitutes technical wisdom.


Posted on Wednesday, September 14, 2011 1:29 AM | Back to top

Comments on this post: Technical Wisdom

# re: Technical Wisdom
Requesting Gravatar...
great post, thanks!
Left by Les on May 28, 2015 10:32 AM

Your comment:
 (will show your gravatar)

Copyright © joeeames | Powered by: