I am working on a new user interface for my web-based IDE, called Global System Builder.  It will use a 3D map-based user interface.  So how does a 3D map-based user interface work with an Integrated Development Environment?  You will see in the following posts.  First step is the evaluation.

 

I lived in Calgary, Alberta, Canada for quite a few years and know the downtown area quite well.  One of its famous landmarks is the Calgary Tower. So I wanted to see how the two major (free) players compared to the real thing (above).

Check this out, on the left and Virtual Earth 3D on the right.  Hmmm… interesting.  Google Earth’s picture is a drawing.  Now I have played with SketchUp and it is incredibly powerful to model 3D – including the interior of a building.  However, not the case with the Calgary Tower here.  You may want to look at the as they have a nice inventory of 3D objects.

Now Virtual Earth’s image on the right is interesting as the software used by MS to gather and make the 3D images got messed up a bit on the Calgary Tower.  However, if you look past that and compare the background buildings in the images, Microsoft’s sure looks more realistic.

Microsoft has also acquired a 3D modeling tool like Google’s SketchUp called 3DVIA.  It appears to have most of the same capabilities as SketchUp, but I need to spend more time with it.  And similarly to Google’s warehouse, Microsoft has a way to place your models on Virtual Earth.

So how do the technologies compare?  Well, Microsoft has opted for a web-based approach using a JavaScript control that you can play with live and see the source.  Google Earth is a thick-client exe and its SDK is actually a with a C# .NET wrapper that you can get, which you will need a Subversion client like TortoiseSVN in order to get the source.

Having developed both, I must say that the Google thick client is much smoother and quicker than the Windows web-based client.  Meaning that when you zoom in, rotate, pan, etc., and play around with the 3D features, Google Earth’s movements are much smoother and seem to download and render much quicker than Virtual Earth.  Now this could be my internet connection speed to the data centers, the number of hops or … a whole bunch of things, but, it still leaves me with this impression.

Other than that, there a very specific feature in one product that is not in the other which will make the decision for me.  Wonder what it is?

Finally, a company called 3Dconnexion has developed a 3D mouse called SpaceNavigator that can fly around and through these 3D worlds and models.  I have one on order and can’t wait to try it out!  If you want to see what it can do, have a look at this interesting “fly by:”  

 

I did  look at NASA’s World Wind and it is really impressive, but I have not had enough time to evaluate whether it meets my needs or not.  One immediate short coming is the inability to draw and import a 3D model, or so it seems…

Still trying to figure out how a 3D map-based user interface will work with a programmers IDE?  Stay tuned.

In Part 1, I briefly introduced the guide to the Software Engineering Book of Knowledge (SWEBOK) that was published in 2004.  “The IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering…”  We will come back to the SWEBOK in a future post as this post is about how to qualify for “professional” league play.

 

In Part 1, I discussed software engineering as being a team sport.  This is nothing new as far as I am concerned, but I am still amazed when a multi-million dollar software development project is assigned to, and executed by, a newly assembled team.  This team has never played together, and quite likely consists of shinny players to NHL stars and everything in-between.  Now imagine that this team is somehow “classified” as an amateur Junior “B” league hockey team and their very first game was to play a real NHL professional hockey team.  What is the likelihood of the B hockey team winning?  Don’t forget, the B team has not played together as a team yet.  Their first game is to play together and play against an NHL pro hockey team.  Did I mention that just before actual game play the team figures out that they are missing their Center, who also happens to be the Captain of the team.  Again, what is the likelihood of success?

 

Of course, this hockey scenario would never happen in real life, but it is certainly happens in our software development world.  Where teams (assembled or not) get assigned software development projects that are way beyond their software engineering capabilities to even have a chance at successful delivery.  I see it everyday.  And to varying degrees, I have seen it over the past 16 years of being in the software development business.  I have been fortunate as some of the dev teams I have worked on are at “professional” league play, where all team members have +10 years of software development engineering experience.  Aside from work being fun on theses teams, our success rate for the design and delivery of software on time and on budget was very high. Our motto was give us your biggest, baddest, dev project you got – c’mon, bring it on!

 

However, most teams I have worked on have been a mix of shinny players t