Architecture v/s Performance

"Ladies and Gentlemen!  In this corner we have Architecture, heavy weight champion!  Look at his size and strength!  Massive! His swing may be a little slow, but he rarely misses his target.  And in the other corner we have Performance.  Don’t let his slender size fool you, he is very very fast!  He may not land every punch but he’ll punch faster.  Come together you two, let’s settle this and have a fair fight!".

Some days just seem to play out like the story above.  We’re so mired in one or the other than we forsake one for the benefit of the other.  Let’s consider that these are attributes of a system.  So primarily who benefits from these attributes?  The customer or the developer?  Just pick one please.  Oh, you can’t?  Let’s take a look at that.  First, Performance: who gets the primary benefit from Performance?  That’s easy, the customer.  If it’s slow they will hate it, if it’s fast they will at least use it.  No matter if it’s exactly what they want or need, if it’s fast enough they will usually try to make it work.   If they can’t get their modifications turned around quickly enough, they seem to tolerate it better if the current system is fast and what they’re getting will be fast.

Now, let’s talk about Architecture.  Who gets the biggest benefit from this attribute?  The developers of course.  They can refactor, rework, enhance, fix, debug and maintain better so the customer will only benefit in the future

So, how do you have your cake and eat it too (not to mention not gain any weight either).  Well, you can’t have  it all, but like everything in life, it takes planning and trade-offs.  When you’re laying out your architecture (seeing where it fulfills requirements of course), you have to step back and look for possible performance pain points.  Just like you have to code smart, you have to architect smart too.   Like I said, you can’t have it all, so when you find these performance pain points, you agree on which ones are acceptable levels of risk and which ones aren’t.   That way everyone is agreement and there will be no surprises when you move into real usage.

So make sure as you’re laying your architecture out that you really think it through from one side to the other.  Think about the technologies involved.  Think about the risks.  Think about options you may have to take.  Envision, investigate, confirm.  And where you can’t, make sure it’s flexable enough to handle plug-ins or replacements.  You’ll be very glad you did.


About JohnHowell

I am a professional software developer with over 20 years of experience. I currently specialize in Microsoft technologies such as VS, TFS, C#, VB.Net, WCF, WPF, WW, etc.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s