by John Browne, on Jul 21, 2021 5:01:22 PM
This is a tale of two projects: one which never was, and one which never should have been.
One of the great pleasures of life is meeting interesting people, and happily my job lets me do that--not as often as I'd like, but still from time to time I get the chance to spend time with customers and I always appreciate hearing their experiences and thoughts.
One of these customers who has been a real delight to know is Steven Heard, the CTO of King County (WA). We've done several projects for King County IT over the past few years, and had some great conversations with Steve--usually accompanied by a cold IPA or two.
Most recently, Steve gracefully agreed to participate as guest speaker in a webinar we put on in conjunction with Microsoft for state and local government IT folks. Microsoft has been interested in our automated code migration tools and wanted to showcase them for some of their customers who had older client-server applications that were blocked from running on Azure as true first-class applications (i.e. web native, not virtualized).
We recorded the webinar, which you can watch here. I think the highlight was a case study that Steve recounted, the gist of which I want to share. If you want to jump right to the discussion in the video, it starts about 37 minutes in.
The King County Vanpool Information System
King County, Washington, is the 12th largest county (by population) in the United States and includes the cities of Seattle, Bellevue, and Redmond among others. Amazon, Starbucks, Microsoft, Costco are all here as is Boeing, although the latter moved their HQ to Chicago in a moment of municipal treachery some years ago. Traffic is a perennial problem and to help King County has one of the largest transit systems in the country including the largest vanpool system. The county "gives" you a van to use as long as you carpool people in it to your place of work. They have about 1800 vans in use and roughly 10k participants. One of my neighbors has one (a van) for her long commute from the foothills to Fred Hutchinson on South Lake Union.
The original application to manage the vanpool system was written in VB6 and used an Access database back end (sound familiar?). That was then and this is now and who wants to work on VB6? So this app--which provides critical business value keeping the system running--was marked for modernization.
Modernizing the Vanpool Information System (VIS)
The team that owned the app elected to rewrite it to move the technology stack to a modern platform and language, keeping the existing system functionality in order to control the scope of the project. The alternative (the project that never was) would have been to have us (Mobilize.Net) migrate the app to ASP.NET Core using Angular as the web client framework with WebMAP. We had done these projects before for KCIT so they knew we could deliver on time; we also had agreed to a fixed fee for the migration so the budget was also locked down. Steve recommended that the VIS system project get assigned to us rather than being rewritten.
But in this particular case the application owners felt they could do better rewriting internally. To clarify, the IT side of King County is de-centralized, so individual business areas own their own IT. The CTO's role (Steve's that is) is strategic, guidance, best practices, and so forth. My understanding is he can encourage but he can't really force people to do things a certain way. (I might have that wrong however.)
How it started, how it went
So what happened? Before we get into the results, let's be clear there's no intent to criticize or blame anyone for what happened. This isn't a case of "mistakes were made." This is instead a case of "this is how software development (usually) works and so it should be avoided if possible."
Let me repeat that: you should avoid writing new software.
Most software projects fail in some regard: they miss the schedule, overrun the budget, fail to satisfy the users, or some combination of the above. Five minutes on Google will provide endless horror stories of software projects gone horribly wrong, occasionally taking the organization down with them.
Ok, to get back to our story, the original estimate for rewriting VIS was about 18 months and $325k. This was 40k lines of VB6 code (the DB had previously been moved to SQL Server) and the plan was to recreate it as a web native application.
Shortly after project start, it was obvious the estimates were wildly optimistic, so it was re-estimated at 30 months and $550k. The second estimate was so far off the original that the project was paused for about six months while the team reviewed status and tried to build a correct and trustworthy estimate. Final experience documented was 42 months from inception and almost $750k in direct costs (total costs estimated to be closer to $800k).
So to reiterate, it took 3.5 years and over $750,000 to deliver the same basic functionality as the original VB6 application. That 3.5 years the development team spent on this project was 3.5 years that they were not adding value to more important applications.
The alternate scenario
The alternative approach (that CTO Steve had recommended) was to use automated migration software to reduce the time and cost of the project. Based on prior successful project experiences with Mobilize.Net, Steve estimated that the migration could have cost just under $250k and been completed in 18 months (the original time estimate for the custom rewrite).
Why? Why did one approach take so long, cost so much and the other wouldn't/doesn't?
The reasons are many, but two rise to the forefront:
- Estimating custom software development is really really hard. In spite of years--decades really--of improvement and innovation in software engineering process and practices, statistically as an industry we remain pathetically bad at hitting schedules and dates. And one of the root causes is scope creep.
- Automated migration eliminates scope creep. The very process is designed to produce a like-for-like translation of a legacy application into a new one that is functionally and visually equivalent if not identical to the source application. Want new features? Make changes after the migration is finished and the new application is in production. That right there locks down schedules and budgets 90+ percent of the time. By the way, that doesn't mean the source application can't evolve during the migration project; there are methods to merge changes into the migrated code base. But it does mean you're not inventing new things while trying to update the old stuff at the same time.
