Anybody else out there that's doing reverse geocoding with the Virtual Earth 6.1 API notice any wierdness last week with the VEMap::FindLocations method?  In short, we have several sites that grab address information based on a point from a map click, user coordinate entry, GPS location, etc.  Well, we were actively doing some reverse geocoding development for a client site last week when suddenly, all of our calls to the FindLocations method wound up returning null despite apparently well formatted requests with valid data points.  A quick check of our other currently running implementations revealed the same issue.  This appeared to be related to an automatic 6.0 to 6.1 upgrade that we received.  The quick solution was to switch certain portions of our code that called the offending method over to use the MapPoint web service so that we could at least continue development.  Meanwhile a quick call to Microsoft and the support folks confirmed our suspicions.  FWIW, Microsoft was very speedy in responding to the issue and all the folks we dealt with were very helpful.  We came in this morning to find renewed joy and love when calling VEMap::FindDirections...the issue appears to be fixed as we can get valid addresses in our result sets no problem.  Flipped the code switch off of MapPoint and back to VE API calls and all is well in the universe.  Still need to follow up with the MS folks as I'd really like to hear about the issue and resolution just for curiousity's sake.

Recently, we've seen an uptick in demand in a couple of our corporate office sites with clients looking for MOSS/ArcGIS or MOSS/VE integration to provide spatial context for their corporate portal content for a variety of markets.  Some time ago the company rolled up a product called Constellation that integrated ArcGIS Server with MOSS and now our Houston office has taken up the standard and gone to the next level with what I consider to be a great Web 2.0 implementation of the product. 

Read the rest of this post »

As Silverlight begins to take hold and I've actually visited and interacted with a few sites that leverage the technology, I've been sort of interested in the fancy charting and analysis packages that I've seen.  You know the deal...bouncing bar graphs, flying pie charts, etc.  Dealing with custom reporting and charting requirements has always been a challenge for me no matter what organization I've been with or have been consulting for.  So today a colleague pointed me to a cool product called Visifire.  It's a very nice graphing and charting package powered by Silverlight and even has a dual open source and commercial license arrangement.  Hey, if it's free it's me.  Just downloaded it and I'll have a whack at fancy jello bar charts and flying pies this weekend.

So Jeff Langr has a good starting list on how to spot an Agile team on the right track over here. Clearly a team being "on the right track" needs to go beyond the mechanics and get into the behaviors of Agile. My picks focus less on delivery than Jeff's but here are some things I'd add to the list:

• There are pigs and chickens, but never goats...the attitude is genuinely one of sink/swim as a team.
• The team actively adds/modifies the backlog as issues or opportunities arise throughout a sprint.  I like to see my team actively adding user stories ("Improve exception handling", "Increase query performance", etc.) as sprints move on; that's how I know they've really gelled.
• The team actively mentors one another and calls out estimation problems or boat anchors to burndown progress, dealing with them non-judgementally.  If John Smith said 8 hrs and its been 24, let's help him out.
• Estimations begin to be all inclusive.  An agile team early in the adoption process will estimate time to actually do the work while leaving out any minor discovery or issues redress; things that can add up over time.  A mature agile team rolls this all in to produce a comprehensive estimate that makes burndown and velocity look reasonable. 
• Members "jump into the breach" to help another team member if one's own backlog is finished early...or take more backlog proactively
• Solve problems in the hallway or at the white board without needing to "schedule" an issues meeting...maybe even over coffee in the morning or lunch.

In short, a maturing agile team will stop clinging to process and develop a cohesion that just looks natural.  Nothing get's forced into 15 minutes because 15 minutes is more than enough time.  The backlog is always well groomed because that's the natural thing to do.  Delivery follows on from this..and that's how you get consistent delivery on committments and predictable story completion.

So I'll actually be avoiding the commute next week for a day or two and hanging out with some of my team members at GIS in the Rockies at the Budweiser Events Center in Loveland, CO. We've got some interesting presentations lined up by some of my development staff. September 10th, 4:30pm Overhead of Spatial Databases, Kevin Larson September 11th, 3:30pm Neogeography for Corporate and Government Portals, Rob Blakemore September 11th, time TBD RTD in the GITA ROI Track, Dan Jackson September 11th, 1:30 pm Colorado Statewide Snow Avalanche Path GIS Database Project, Doug Scott We'll have a booth up this year and I'll be hanging around there on the 10th and dropping in on a few presentations as time allows. Stop in and say 'HI'...I'm always happy to chat and meet new folks. We'll be having some cool giveaways, raffling off some gift cards for Golfsmiths for those of you who enjoy "a fine walk ruined", and we also have some free consulting promos for new clients in the VE and AGS realms. Hope to see you there.

I got together for breakfast awhile back with a colleague of mine in the industry who has been instrumental in getting me to drink the Agile/Scrum kool-aid and we got to talking about some of the more challenging fallacies we've both run into surrounding Agile.  The one topic of our discussions that really stands out for me dealt with the idea of having your team work at a Sustainable Pace.  First off, what is sustainable pace? Well, Ron Jeffries has described it thusly in the context of Extreme Programming teams (my paraphrase in brackets):

[Agile] Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. [Agile] teams are in it to win, not to die.

Read the rest of this post »