John Howell

"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.

Most of you who have been reading this blog knows that I’m obsessed with the advancement of technology and it’s application.  So naturally, I’m completely over the top about Silverlight.  And Microsoft is in complete agreement and is generating documentation and tutorials, well, at the speed of silverlight.  Check out the latest on MSDN!

Recently there has been some discussion among some of my peers about the software design process.  Particularly in and around Agile and if/where Architecture fits in.  One argument is that with Agile, the Architecture is dictated by the Stories as they play out, other’s say that you can’t have both.

There are many ways to create software.  They each have their intended ‘audience’. I use the term ‘audience’ because each software development technique was developed with a particular target developer type in mind. Now mind you, I’m used to being flamed in both email and face to face. I just tell it like it is.

So back to the discussions. Architecture happens. (Sounds like a good bumper sticker or tee-shirt). Whether you intend it or not. So really the question is what comes first? If your code comes first and your Architecture ‘evolves’, then you have no real control over it. If your Architecture comes first, your code will fit the architecture. That’s the rub. Agile methods say that the code drives the development, not the other way around.

People often compare developing systems to building houses. If so, then the Agile technique would have the builders framing out the bathroom before the slab was poured. Sounds crazy doesn’t it?

So let’s get to the truth. All software must spring from a need or a purpose. That purpose should then help you to envision a solution. You can then break that vision down into requirements or goals. Those requirements form the boundaries for your system. Next comes the Architecture. This Architecture ensures that the requirements and goals are met. Then the Architecture breaks down into Design and the Designs break down into code. Contrary to the Agile folks, there is no waste here.

So many of my peers were wrong. Code doesn’t come first. Architecture doesn’t come first. Even the Vision doesn’t come first. The need comes first. Our purpose is all about meeting a need or fulfilling a purpose. Architecture is the technique that we used to ensure that we meet that need or fulfill that purpose.

Case closed.  Or is it…

Next time: we talk about where performance considerations should come in.  Stay tuned!

OK, I know the flames will come, but let me preface this with the words "this is my experience and opinion".  The debate that has raged between the camps of C# and VB.Net has been at times vicious and spirited.  But let me share some of my experiences.  I’ve written millions of lines of VB6, VB.Net (all versions) and C# (all versions).  Recently I had to do some maintenance on an old system I had written back in my VB6 days.  I thought back then I was a pretty good developer, but upgrading to VB.Net 2005 exposed all the flaws: non-declared variables, used but not initialized members, functions with no return values, variables declared without type, and on and on.  Just little things that VB6 handled for me but should have been addressed.  So for my opinion, VB let me get away with things that I should not have.  VB has come along way and VB.Net 2005 points out most of those flaws.  C# is a lot less forgiving and declarative than VB and as such prevent more of these sloppy mistakes.  For me, I’ll do everything I can in C#.  The only thing I miss from VB is late binding to the Office products.  C# gives me the advantage of being much easier to read (less verbose) and the upgrades are much cleaner.  C# also ‘seems’ to promote better reuse practices and OO techniques.  As I said in the beginning, this is just my opinion….

I know many of you, like I did, used the Google Groups search to search then MSN forums and postings.  The old MSN forums UI and search was slow and clunky at best.  Well, MS listened and has updated the UI.  The search works well and the UI is now very responsive.  Google Groups search is still out there.  In fact it went from Beta to Production just today.  When you’re stuck on a bug, try the MSN forums search next time.  You might like what you see.

We’ve been waiting quite a while for this version.  But some of the features we had been wanted have been moved to a later version.  Still, .Net 3.0, powershell, AD enhancements and more make this release one to watch.

Finally the wait is almost over!  XAML for the web!  We finally have something that can unseat HTML and give us a real way to delivery great user experiences across the web!  Check it out!

Microsoft has given a go-to-market name for its cross-platform, cross-browser plug-in for delivering the next generation of user experiences and rich Internet applications for the Web. The technology formerly known as WPF/E is now known as Silverlight. Finally we’ll have a web development tool with some teeth in it.

This means it getting closer.   Here’s a quick news flash and here are some tidbits of what’s changed.  Not to mention C# 3.0!