Tim Murphy's .NET Software Architecture Blog

August 2006 Entries

Project Triage

Have you ever been on a project when the patient goes “Code Blue”?  It is crashing.  No pulse.  No breath.  No blood pressure.

So what do you do?  My first piece of advice is that you don't try to fix everything at once.  On the battle field or in an emergency room they have the concept of triage.  This means that you start with the most critical, life threating issue.  In order to do that you must evaluate the patient.

List what the projects are for the project.  Is there a lack of performance?  Are there mysterious bugs that are driving the users insane?  Possibly it is that the understanding of the requirements were wrong.

Like medicine, the most critical wound is if the heart stops.  To an IT project the heart is the business need.  If you can check of the requirements then move to the next step.  This is usually bugs that are stopping the users from working.

Another key point is don't guess at solutions.  Create your theories and test them out.  Quick fixes often don't address the real problem and only prolong the bleeding.

Of course this doesn't cover everything, but it gives you an idea of an approach to triaging your project.  Good luck.

Queue Hell

I have come across a situation at a client where they believe that queues are the answer for everything.  It is how they abstract their database from the applications.  The battle cry seems to be “If we go through a queue it is more flexible and ensures that messages between apps will get to their destination.

While I do believe that queues such as MSMQ and MQ Series have their place, they are not the answer to all the worlds woes.  Of course the same goes for any technology.  I have heard of companies that do the same thing with web services.

As the saying goes, “everything in moderation”.  Technology should be used where it is best suited.  Queues are great for processes that you don't need an immediate response and have high volumes.  The wrong place for a queue is where it holds a synchronous reply to a UI.

The last thing I want to address is the use of queues for database abstraction.  This is why we build configurable data layers in our applications.  Using a queue has not done any better job and slows down responses.

The main point here is not to get stuck on one technology or pattern.  One final cliché.  Just because you have a hammer doesn't make everything a nail.

Simplicity for Simplicity Sake

As architects we try to look for the simplest solution to a business problem.  This is not just because we are lazy, but because simple solutions are easy to maintain and tend to be less tightly coupled.  This does not mean that the simplest solution is always the right solution.  If one aspect of a business requirement can be addressed by a pattern but it invalidates three related business requirements then it is the wrong answer no matter how simple it may be.

In the end it boils down to coming up with a design that takes into account the correct amount of scope and fits the users needs.  After all, it may build our egos to say that we can make a program in one line of code, but if it leave the business stake holders with a view of only half of their process then it is doing more damage than good.  Verifying your business requirements and putting them at the center of your design process is key to success in your project.

Catching up ... 3.0?

My latest project has been all consuming to the point where I am starting to feel like the world is passing me by.  The other day I was listening to a podcast while commuting and heard WinFx referred to as .NET 3.0.  When did this happen?  Somehow I missed that announcement.  For those who are behind the times like me you might check out this site

The most disturbing part is that anyone who has been in this business for a while knows that if you don't keep up someone else will soon be doing your job.  These are not the good olé days of COBOL where you could have the same skill set for a decade and still have a job.  Wake up call!  It is time to catch up!  I'll be back as soon as I read a few more articles.

Too Many Chefs in the Project Kitchen

This is really an observation about large enterprises.  The larger they get, the more people are required to make a single decision. 

I am currently working for a client that has an entire floor of a building with nothing but architects residing there.  In the process of this project we came across a technical issue relating to the database.  We presented alternatives to the lead architects and thought that we had an approval for a solution.  Surprise!  It turns out the data architects were still discussing alternatives.  We were then informed that the enterprise architects would have the final say.

Now I have no problem with getting knowledgeable people involved.  What I do have problems with is not knowing who the right people are.  Large enterprises need to make sure that there is a clearly defined and published procedure for getting the right people involved.  When projects are under are fighting to stay on time and under budget the last thing they need are false starts due to undocumented procedures.

So what can you do to help the situation?  The best thing I can suggest is asking frequently if anyone else is required to approve a decision.  Some times a reminder to the people you are working with is all that is needed.