In a nutshell, I "did it all" at VCI. All the standard buzzwords applied: MVC, n-tier, high-availability, responsive UI,
mobile, customer-facing, employee-facing, incremental delivery, etc., etc. From creating a dealer-facing website
using ASP.NET MVC CTP (this was back when we had to roll our own mechanism for form data persistence and validation
metadata), to architecting the backend infrastructure that would support a next-generation credit and funding workflow
system, and back again to creating a web core that would support both a responsive desktop as well as mobile
experience - I ran the gamut there. By far the most fun I had was in teaching others agile practices and
methodologies: TDD, BDD, point-based estimation, iteration management, developer empowerment, EIEIOs, and so on.
<steps up onto his soapbox>
One of my special (or annoying, depending on who you ask) talents is the ability to carve out spaces in which
"things" can happen. What kind of "things"? Well, fun things. Different things. Exciting things. As developers,
we read about, and become interested in, new technologies and design patterns. At home, it's easy enough to tinker
with these. At work, though, it's often difficult to take these new things and convince others to try them out.
Our managers (and their managers, and the Big Bosses), and sometimes even other developers, may balk at the idea of introducing
something new. There are the usual grumblings of, "It'll cost too much to do that," or, "I don't know how
to estimate against a technology I've never used," or my personal favorite, "We'll add that to our backlog of technical debt."
I find that, "No," as an answer given simply out of fear of the unknown is severely limiting and ultimately self-defeating.
You can't grow personally without trying new things, evaluating how they're going, and adjusting accordingly. Similarly,
organizations following the mantra of Change Is Scary will eventually find themselves having to perform company-wide overhauls,
involving expensive reverse-engineering of existing systems, user retraining, figuring out how to transitition from old to new, etc.
Do not go where the path may lead; go instead where there is no path and leave a trail.
Walking trails blazed by others can take you to some really neat places where you can see and learn lots of
fantastic things. For me, though, there is no greater thrill than veering off in my own direction and leaving
a trail behind for those who are adventurous enough to follow.
So what's with all the soapboxing? I promise there was a point! I was very fortunate to have been able to enjoy a
great deal of freedom to trailblaze at VCI, generally with good results. There is a space that exists between corporate
paralysis and developer anarchy that is small, tumultuous, and very rewarding. I was at VCI for a long time, and I made
it my mission there to occupy that space as much as possible.
We started with an organization that was completely waterfall, thoroughly siloed, and reluctant to adopt new
technologies and practices. We transformed it into a place where agility is valued, cross-functionality is promoted,
and new technologies are embraced. Despite the fantastic technical achievements I've had the pleasure of being a part
of here, I'm most proud of those instances where we were able to convince the Powers That Be to take a chance and try