I wasn’t hired into Invata to change everything.  I was hired in as a software developer.  There’s a lot of story behind all that, and I’ve been recording that elsewhere.

However, I am subversive enough (for the greater good), and accordingly convinced enough staff and executives (directly or indirectly) to accept what they already knew about their situation, and follow through on a path to change the technologies and software processes with the alternatives I had been pushing.

So, first (dear reader) we take a quick look at the loose conglomeration of branded software shells and patterns called “FastTrak” which was the legacy software library used to make warehouse integration solutions (no matter the scale).

Since Invata had started out integrating material-handling equipment other integrators struggled to fit into “unorthodox” customer needs, it’s platform code was hardware management-centric (and Windows service bound).

It’s long data history started and stayed within the confines of SQL Server stored procedures for most of the heavy lifting.  There were some incredibly beastly routines (customized by customer and project), with often multiple levels of nested call operations, with ON ERROR GOTO and @@ERROR code instead of SQL TRY…CATCH blocks.

It’s concurrency and conflict management was minimalistic and crude, employing “lock” statements in C# and (NOLOCK) in SQL.  Most of the time the systems stayed stable by crossing one’s fingers and hoping that any problem would sort itself out by trying again (usually with operator involvement).

The standard mobile footprint was Windows CE (as late as 2016, well past support date), it’s user interfaces were designed by software developers, so tended to look a lot like tabular worksheets (modeling the way the developer saw the data).

To succeed as a developer one needed to be a highly-competent SQL coder, and not just for queries, but for multi-level flow and control.  A strong mastery of C# and .NET was also required, and also have an understanding of Windows CE and WPF (not MVVM).  Given the non-commonalities of the libraries (FastTrak was largely a set of “shells” and data-pipe fittings) the practice was building inside the shell, hooking up the pipes for each custom(er) project, requiring one to also rely on one’s own wits to manage anything outside the custom code (i.e., anything specific to that customer).

For source control, we relied on TFS-VC, which was a bit cumbersome.  Shared libraries were kept on a file share.  Every project was effectively a silo in itself.   Deployments were hand-cranked per project.

Specifications varied by project, and even within a customer project, specifications were written and doled out in such a way that two or more developers (or even the same one at a different time) might be following a specification, and failed to see how these pieces connected and make critical design/modeling incompatibilities when they had to work together.  Multi-level architectural design processes weren’t being handled organizationally; they was evolving per project due to evolutionary pressures.

My goal was to change pretty much all of that, and after a few years of attempting to deny I might have a viable alternate path to take (during which I was working on projects with the legacy stuff, thereby giving myself “creds”).  They finally relented and helped clear the path so that I could build that path, as the architect of the future “product”.