Impersonators: Using them in showcases
Towards the end of my colleague Julio Maia's blog post about the impersonator pattern he suggests that the standalone environment that we can create through the use of impersonators can be quite useful for showcases and we actually had a recent occasion where we had to switch mid-showcase from using the integration environment to make use of an impersonator.
In this case part of the environment went down in the middle of the showcase so if we wanted to keep on going then that was our only option but in general the expectation of the business is that our showcases show them the functionality of the application end to end.
We need to be careful when using a standalone environment that the business are aware of this because it's quite likely that the application is going to respond much more quickly than it would if it was fully integrated.
If people aren't aware of this then they will be very surprised when the application isn't quite as performant when we put it into a real environment and it has to retrieve and store real data instead of just getting pre-stored values from an in memory impersonator.
Another disadvantage of using a standalone environment is that we must ensure that we only enter data which we have previously entered otherwise we'll either go against the real environment if we're using a self initializing fake or (I think) just get no response if we're using a record/replay type impersonator.
If we're letting a business user drive the application during a showcase then we'll need to ensure that they know which data they can enter.
As long as we're careful in those regards I think it can be quite a useful approach since we can make our showcase independent of factors that our outside of our control – for example in our most recent showcase we had to reschedule the time because one part of the server was going to be restarted at our initial showcase time.
I definitely like the idea of using the impersonator for the safety it brings although my thinking at the moment is that maybe it's best to use it as a backup option if the real environments aren't working.
I'd be interested to hear if others have experiences around this area.
Impersonators, while a useful architectural pattern to aid in making early build pipeline feedback faster, are more suitably dubbed an anti-pattern from the viewpoint of showing and delivering working software.
If the backends are slow or flaky, an impersonator may help some aspects of immediate feedback to the developers – but the underlying problem must be addressed! More effort is expended working around crappy backend services than what it takes to fix them.
Using an impersonator during a showcase feels like duping the sponsor. You are not showing working software. You are showing the working facade over some smoke and mirrors.
BESIDES, if the development team has to deal with the crappy backends, then it should be HIGHLY VISIBLE to the sponsor. When the showcase is a shambles and maybe the sponsor will have enough impetus to do something about it for the good of all.
In terms of feedback, the danger is the impersonator is not doing a good job and the feedback contains false positives. Martin relayed the technique Josh Price mentioned about to have the SelfInitializingFake check against thru to the real service within selected contexts.
Mocks, stubs and fakes are useful at progressive points in the build pipeline to substitute for the real things they are masquerading. But, just like you wouldn't use a mock in a showcase environment (let along production), nor should you use a fake for showcases, nor rely on them as proofs in integration or functional tests.
Remember, the automated build, test and deploy facilities are there for us to show why the candidate build should NOT be released to production. Tests passing in a non-representative context do not reach that goal.
Likewise, showcases are there for us to give the customer a view of the software that they can release to production NOW. Demonstrations in a non-representative context do not reach that goal.
As with any "pattern", use with caution, and appropriately.
JoshG
10 Sep 09 at 2:05 am