次の方法で共有

How to use scrimages to migrate your apps!

  • [アーティクル]

No, seriously. Well, look at it from this point of view; companies go out and hire a really hot developer, they put them to work, and they are expected to perform at the highest level. Only, they never train them. And I don’t mean that once a year boondoggle, or the occasional “Effective Writing” course either. I mean training, you know, line up on that line, run back and forth over and over again…well for developers, it’s a little bit different.

So I’ve been cooking something up, and yesterday I organised with a customer to implement it, so let me step you through my thoughts.

Now, as I always do, let me draw an analogy to my time in pads. When you play football (the football I played was a little different to other footballs), one of the biggest elements that define your ability to knock someone bigger than you over is technique. Not strength, or speed, or a combination of both, but how well you execute. So after six years of training, my blocking, tackling, rushing and hitting technique was pretty honed; in fact, the blocking and hitting technique, being something that happened in generally traumatic situations, needed to be almost innate. But then the season would end, and I would stop training…I wouldn’t stop playing, that was just too hard, so me and my mates used to get down once a week to the local park, pad up, and knock the crap out of each other (I remember one year we had a spate of “hold him up” sessions, ouchies). Now, even though we were executing our skills regularly, as soon as we’d return to training the following year, we’d pick up where we left off, and suddenly you realised, jeez, I didn’t remember that bit. Why? Because learning and skill building are incremental actions; you can theoretically learn everything you need to know about blocking, but you can’t do everything there is to do with blocking, that’s a time and materials thing.

So in software development, the same principals hold true I reckon. If you hire a bunch of smart developers et al, and put them to work, and expect that because they are developing then they are honing their skills, you dead wrong. What they are doing is practising their existing skills, but all the things they know, that haven’t been practised, lay in wait. If they don’t do practise sessions, and cement their “what I know” into “how I do it”, then they will never feel confident to try the “what I know” in “what I’m doing now”.

So with my customer, who is currently on a VB6 and classic ASP platform, the plan is to institute a training regime. For the next 4–6 months, the team is going to allocate 1–hour a week to “team practise”. The schedule looks like this:

Week 1–4: ASP.NET

Week 5–8: Team System

OK, so now the team after 8 weeks, is far more comfortable and familiar with the “new” stuff, than they were before, and they have had time to think of the current day to day stuff they work on in terms of the “new” stuff; this is a great place to be, and also, it’s low impact, which makes it more achievable.

So then we move onto the meat in the sandwich, or as we used to call them at practise, the scrimmage. So after all this learning and practise, it’s time to put the rubber to the road, but again, in practise mode. So for my customer, the end goal, is to migrate their current app from VB6/ASP to ASP.NET and managed code, using Team System. So we set up a range of scrimmages:

Week 9–..: Migration Scrimmage

Now, a scrimmage is serious, but is done in a way that allows the coach and trainers to identify and isolate individual issues, and correct them in live maneuvers. So say in the first scrimmage, the team tries to migrate their ASP app to ASP.NET 1.1 (the bridge step) and encounter some major issues? No problem. During the scrimmage, the whole team chooses one issue, tracks it back to the root cause in the original application, modifies the original application, records the change steps, then reruns the scrimmage. They then do this for as long as they are scrimmaging, all the while, building up a log of change steps (that should be put into some kind of automated tool for rerun). Over a number of scrimmages, the team will rerun their change steps, rerun the migration process, encounter issues, resolve them, etc, until one day, voila, no issues.

So now they are rocking. Because they are now familiar with the tools, the languages, the framework, they have gone through the steps required to migrate their solution to the new platform, and built muscle around how to fix problems on the fly if they occur during migration, and already have a bunch of pre-migration change steps to prep the codebase pre-migration. Best of all, they’ve done all this as a team. And from a project managers point of view, this is great, as the team is now ready to migrate to a new toolset, platform and technology, with all the skills necessary, and no one had to come off the critical path, the disruptive impact to the team was low, nobody was under production pressure to get things right the first time, and as Jeff calls it, the Overall Goodness Factor is high.

Now, if this whole process takes 3–6 months, then who cares, the goal is a smooth, painless, successful migration. Better than everyone getting high on juju babes, chugging a box of cola and then running wildly into the source control system, IDE in hand. That just ends in tears (generally the business or project sponsors). So the slow, systematic approach feels best.

And most importantly, the kind of training regime should be performed 8 out of 12 months of the year; all the project team needs to do is work out what is coming up on the horizon, train around those tools and technologies, and then when it’s time to play ball, everyone is at their peak, and ready to perform.

Anyway, I have to split, nurses appointment to check up on my leg :)

Comments