I’ve been working with a team who will take over system support for a system my team has been building.  My team worried that we didn’t “deliver to the audience” while we delivered what we believe the customer wanted.

“Delivering to the audience” means, did we build something that developers (seasoned or not) could learn to understand, pick-up, and eventually own.  The big brass ring is always, can folks learn how to be more efficient or learn what not to do, with what we created – either case is still a valuable lesson.

This week we had three sessions.  Covered most everything we needed that exposed the patterns we used, and the ones we chose not to use.  Most of the dialog that came across the table led me to believe that they were going to get it, and it was going to sink in.  Our team who uses an unused executives office as a work room literally has an open door policy.  We stay available in IM and email contexts as well since most folks, developers in general, would rather communicate electronically.  The folks I met with this week seem to be more face-to-face and ready to get this stuff on them.  All good indicators that I can move off of this system with little or no ties to this system post-go-live.

So the goal here is to move back into what my team initially did, which I’m being told may change a bit in the future.  It sounds exciting and a bit spooky as well.  However, we enjoy being part of a larger strategy team that  helps folks learn how to be more efficient or learn what not to do, with what other folks (large and small software shops outside of our own shop) created by kicking tires and test-driving software in a real(our)world context.

I’ve always hated moving, but now I realize that not all moving is bad.  Sometime we have to move on, other times we’re asked or forced to move on; at least this time there are no boxes to unpack.