I’ve been working on a series of POC projects that all went live with little time to pay off the technical debts incurred when converting a demo app to a production app.  The time is finally come to start paying off the debts.  This week, I’ve been refactoring an app to be DI.  Last month, I had to rewrite an app basically from scratch.

We have 4 projects in flight as of this morning.  I think it is 2 web apps, a WPF dashboard, and a VSTO add-in for Excel.  We released another VSTO add-in a few weeks ago.  So I think we are sitting at 4 apps.  It might be five, if something spun up while I wasn’t looking.  I am now managing code quality for all of the developers.  With the expansion of our team to 11 + 1/2, my time has gone from 80% research, 10% support, and 10% teaching to something more like 50% code reviews/teaching, 20% support, 30% research thru refactoring.  <ugh/>

The single most important topic is supportability.  If you are writing code that doesn’t conform the general shape and style of our other pre-existing apps, I will make you redo it.  The problem is where someone one on the team has to (re)learn an app when we get a support call.  I’m trying to reduce friction.  There are moments, when we have to crank out a bug fix in under an hour.  No, I’m not joking.  When you are working on finance apps time is money and a multi-billion dollar commitment is normal.  Think building a new fab.  $5B minimum.  Or scaling product availability within 30 days to catch a holiday sale for the latest hot product.   Million in lost opportunity costs can fly out the door if we (royal we) miss a forecast window.  We can get into the code, figure out the gory details without delay, make our fix, compile, test, and publish as soon as possible.  To that end, I can’t let anyone slide on code quality.  I have to be a dictator about it.  “You will do it my way…”  I hate managing people like this, but it has to be done.  The alternative is very unpleasant.  I have tried it.  Some people, especially opinionated contractors, don’t always follow gentle nudging.  (I know, I used to be one!)

Keep in mind, we have something like 17 apps already in production.  Some of that code is crap.  But…  There are a lot of good ideas in there too.  My role is now to keep all of that previously acquired knowledge in my brain and pull it out to the betterment of the team.  I do this during design meetings (a pre-coding code review), during the weekly team technical meetings, and during code reviews.   Doing code reviews was not exactly what I signed up for but I’m the one who cares the most out of the 3 permanent staff on my team.

<shrug />

Hopefully, I’ll hit a good groove and find the time to write more about what I have learned in the last couple months.

Enjoy!