Sub-Part 1: Company Background
The last DBA I hired into my previous employer had landed a consulting gig at what would become my next employer. He was there to look over their database practices — and probably some specific customer projects — when he realized they needed my broader perspective on software. Most of their heavy-lifting was in SQL server (lot’s of stored-procedures — aka, SPROCs), but their front-end, external-system integration and device communication work was in C# (often using SQL SPROCs to make decisions).
So a little background on the company — as far as I understand it.
Invata Intralogistics (now a defunct company), was an amalgamation of several other companies that came together to build intralogistics solutions. That is, they built warehouse operations software for people and equipment – acting as an integrator and reseller of hardware when necessary.
Integration meant software, and they had started in the 1990s building out versions of their software library. By 2016, they had been through several iterations of the libraries, in the process porting from VB6 into C#. The desktop front-ends went from VB6 through WinForms and into WPF — though with a decidedly WinForms/VB6 stylistic flavor. The mobile front-end was stalled in Windows CE. Both types of user interfaces and the services all directly talked to SQL stored procedures (as previously mentioned), but the table schemas were not standardized, only the call parameters and response result sets were mostly standardized. Mostly, because they might be altered and tweaked for each customer solution; something more likely to happen in the UI.
As a project-based integrator, the organization was pretty flat. Pushing solutions onto client sites was the most important thing. It also had some management maturity issues — and they knew it. At the best, any person managing client implementations might be able to handle 2 to 3 simultaneuously, scaling out with more client managers leads to expectation conflicts with the layer being managed as well as a whole host of other problems related to being unable the share workers effectively when each manager has different priorities and schedules.
As an amalgamation, they also had multiple executives who had all previously been in charge of their constituent domains, and with different ideas about what to try to sell for solutions, what technologies to use, and even how to direct people.
They engaged a management consulting company to help (nominally) sort themselves out.
They also hired a bunch of people at various levels, and some development management that looked like “best-practices” according to some collectively designated criteria of best, dabbled in "A"gile things including daily meetings in which they talked about things moving across Kanban-like swim-lane boards, slapped the suffix “core” on anything that looked like maybe it could be a part of a product – which is software could be just about any piece of code if you’re not too careful.
I use “they” here deliberately as distancing language, I was there at the time but managed to keep myself at arms length, and worked on projects that hadn’t yet been taken over by that level of daily non-introspective shuffling of cards.
I went a little past the pre-history background and into what happened while I was there, but the seeds of that particular epic of software splatting were sown before I started, so while the temporal effects happened while I was there, the background that led into it was from the before times — as background.
Other things that happened after I was there for a bit was adding more executives to balance out the decision making maturity — in theory — but it never quite led to that (just more competing voices with divergent ideas), or to its secondary goal of bringing in a slew of other business opportunities in the wake of the new executives’ contacts.
New sales people were brought on in a similar (yet non-executive manner) to help bolster the sales capacity without necessarily being in line with what we had or could reasonably build and deliver (software and hardware). New solutions people were brought in with industry experience, but no basic understanding of what we actually had, nor could create.
There ended up begin more than a few specifications in which the solution concepts were using things we had never done before and algorithmic approaches that were not in-line with the realities of what our software libraries could handle, had ever handled, nor could be made to handle in any reasonable time, nor in a manner conducive to the coding tools and languages we had experience in. Some of them were also not “complete” in that the exception cases or variants in processing paths were just not considered; or defined in words that were incomprehensible or incomplete to code against.
Towards the end of the company, basic “fixed-location” automation equipment for moving goods and containers around — ie, conveyors, sorters, diverts, carousels, shuttling systems — was being eclipsed in focus and “market demand” for more robotic movements. We had little direct experience in that at the time, but that didn’t stop us from pursuing and winning those projects.
I hope I painted a broad enough picture with enough parts to next explain my entrance into, changing strategies against, and impact on the company’s approach and direction for software product management and solution design and implementations.
Pursuit of Value 