Rauschenblog

Jon Rauschenberger's blog
in

October 2005 - Posts

Dual Core Goodness
I've been working on a dual-core PC for the first time over the past week and I have to say that I really...really like it.  The user experience is much more fluid than it is on a single core machine...even with a relatively low end dual core CPU.  I can build a large VS.NET project (build takes ~2 minutes) and the machine is totally responsive while the build is taking place.  In genreal, the windows shell is never unresponsive on the machine which is a very nice change of pace.
 
Memory helps also...the machine has 2 gigs of RAM which is the sweet spot for a development machine at this point.
 
So, especially for developers, I would strongly reccomend a dual-core CPU even at the expense of less overall processing power (e.g. get a $300 dual-core CPU over a $300 single-core even if the single-core has higher benchmark scores).  Trust me - you will be happier.
 
Oh yea, go for AMD CPUs whenver you get the change.  Not only do you get more processing power for your dollar, you are also supporting a company that supports one of my passions.
 
 
These guys rock...

...pretty hard:
http://www.blackrebelmotorcycleclub.com/

They have that cool country/rock mix that usually sucks, but when it works it really works.

They may it work.

What is the Right Metaphor?

I like metaphors.  They help me understand things that complex or that I am not very familiar with.  They also help define how to think about and solve a problem domain.  One of the all-time great books on software development – Code Complete – even dedicates an entire chapter to the application of metaphors to software development.

 

Trying to pick a metaphor that best describes software development is difficult.  There certainly are plenty to choose from; over the years I've heard people apply construction, farming, raising children, and countless other metaphors to software development.  

 

Recently I was at a conference where someone used airplane construction as a metaphor for software development and it struck me as the best one I’ve heard to date.

  • Design:  To build a plane that will fly and fly safely you need a good design before you start building. 
  • Design Patterns:  Think about the planes you see flying around – most of them look pretty similar and all of them build on designs of planes that came before them.  I doubt if anyone sits down to design a plane today starting with a blank piece of paper…my guess is they leverage what others designers have done in the past and add a few new elements to the design of their plane.
  • Unit Testing:  Each piece/component of the plane needs to be thoroughly tested before the plane is assembled and flown.
  • Flight Testing:  Once the plane is done, it goes through extensive system testing before it goes into service.  This testing includes things like stress testing to see where the plane will fail.
  • Maintenance:  Roughly 50% of all plane crashes are a result of improper maintenance.  To continue flying safely planes require regular maintenance.

 

All of this sounds very familiar to me when I think of the process of designing, building, and deploying a piece of software.  The steps vary from app to app, but the basic concepts apply to all software development projects.  You can even extend the metaphor to describe how different scales of projects are built – Boeing goes through a very different process with the 777 than a home builder does when assembling a kit plane.  Same is true for software – the steps that Microsoft goes through to build something like SQL Server 2005 are very different than the steps a 3 person shop goes through when building a ‘forms over data’ type app for 10 users.

 

So now what?  What use is this metaphor?  For me, it helps change they way I think about software development.   Aircraft design and construction is a very exacting engineering process.  As a result, planes crash a lot less frequently than software does.  The software development industry can learn a lot from the aircraft construction world.

 

It’s time for software development to transition into an engineering discipline.  This will remove some of the ‘art’ and ‘fun’ from designing and building software, but it is a necessary step for our industry to take.