Anti-Marketing Product After the Fact

Management decided (as best any collective could decide anything) to rebrand software and make new stuff just slightly ahead of handing “free reign” to me and my crew.  AUTOMATE was a banner under which a few scrummy web solutions were cobbled together using “modern” collectivistic software development rituals.  Since the effort had gone into publicly promoting this banner, it was forced onto the new-platform team by the zeitgeist, at least in the context of the rest of the company.

We (or I and the crew) sort of ignored it as well as the questions about “what our product did”? We weren’t making a product, we were making a technical framework for solutions, that required an organizational structure that would conform to the efficiencies the framework allowed.  If I could get organizational members to understand that, fantastic.  Most of them probably thought I was being difficult, rather than examining their preconceptions and trying to spur them to reflect on what they were asking, so we could have a real conversation instead of me being the software genie.

I can only imagine what it must have felt like to ask the product architect about the product and get back “what product?” as a response.  Or “can AUTOMATE do X or Y?” being answered with “what is AUTOMATE?”  A few people realized it was as way to enter conversation and sometimes they became better informed by it; sadly, not often enough.

NETCORE 3.1

The first iteration of the software was bannered internally as “NETCORE3.1” after the .NET CORE framework it was built and intended to run on.  Only one customer ever ran on the platform before we moved onto the eponymous “HyperCore” platform, after which this blog is named.

Since this was the pilot framework, it’s changes from legacy FastTrak were the most pronounced and required the most time and settling-in period.  The biggest change for most people was moving from an equipment-centric focus to operational and subject-centric modeling, in which inventory flow was more important than equipment monitoring, as this was what the customer was usually more concerned about.

Technically, the heavy lifting was now in .NET/C# rather than in SQL Server.  This required multiple concurrency management strategies (that improved in future platform iterations).  The mobile front-end was now Xamarin based Android.  The desktop front-end was still WPF, but was connecting to Web Api endpoints and using more MVVM and dependency injection patterns.  Background services were a first-order participant in the framework, operating in-line with user operations in the same hosting space and subject to the same security, ledgering and concurrency measures.  Web interfaces also funneled through the Web Api service endpoints, so there was in a sense one shiny host.

Design Goals

As stated above, modeling intralogistics concepts was a major design goal so that the systems feel similar where they should to the internal staff who had to build on and support systems using this framework.  Improving, encouraging and enforcing code commonality between projects by having a common intralogistic “generic” model was a major goal to avoid divergence project by project.  Dependency injection and generic parametric polymorphism would help with most of the hard physicality of differences in things like item masters and container data, but other strategies would eventually be employed.

Ensuring we could automatically make deployable systems was also a high priority.  We switched to Git for TFS and began creating build pipelines to fit configurations and docker containers to specific environment requirements.  I was involved in kicking some of that off, but the overall push and drive was handled by others who were in the crew.  Also, we were able to replace the shard folders with NuGet package management for both common framework code and for customer specific common libraries.

We also wanted to reuse as much of the “legacy” hardware integration components from FastTrak as possible, so consequently the conveyor and print/apply systems only had to change their piping from SQL Server to the Web Api (which had to model the SQL SPROC calls to some degree of another).  They otherwise continued as “FastTrak” branded components and had the same operational characteristics.

We didn’t want to rewrite everything, and we didn’t have to.

Developer Skillset Profiles

Since we had modernized our development platform and solutioning framework, we could move away from the rarified expert in SQL, WPF, C#, and begin to focus on different skills in different parts of the solutions.  We also worked on separating the “deep” intralogistic logic from the user interfacing, and sometimes from the machine controls.  Consequently we could tap into more commoditized and specialized developer pools.

Since we also had some web front-ends (monitoring and management), we could get real web developers, for where we needed them.

HyperCore

After the first customer implementation on NETCORE 3.1, there was a brief period to assess and plan for the next iteration.  This next iteration would be called HyperCore and would run on .NET 5 (the current .NET at the time).

Several customers were developed on this platform.  During this time, a flexible order processing system was built to handled WES-like requests for package production with inherent knowledge of how the operations should be carried out, complete with status tracking.  Also, an in-store robotic fulfillment system for a major home-goods retailer was built using a customized demand-driven fulfillment system, followed on closely by a generalized demand-supply fulfillment system used in a major on-line e-commerce fulfillment center.

The logging/ledgering system got a very significant overhaul so that inspecting records in the database became easier for support personnel, and the rudiments for semi-pre-aggregated temporal-spatial counters were put in to support near-real time rate checking without having to traverse log data.

More hardware integrations and new robot orchestrations were put in place first as customer one-offs, and later as generalized and configurable “product” options.

Software Development and Design Model

New solutions were still a challenge, as sales and design were thinly interacting at best.

Getting solutions plans to be written against the common model design was a novelty to management and solution designers still.  Often after a project was sold and then implementation started via that scrummy collectivist ritualistic stuff I wrote about above before anyone who knew what should be done got involved.  We were still a schismatic non-organization at that time, and never fused before the company folded.

So to fix the key projects (the ones that could make or break the company), we had a small team go through the projects and “design” them for HyperCore after they have started generating noise, heat and meetings.  This team consisted of myself, one product owner, and one company owner.

Ultimately, however, medical things, misdirected multi-management, irate customers doing occult things with databases they didn’t understand, and lawsuits shuttered the company before we could fix the organization.

That wasn’t the end of the code, however, since some interest in “the product” lingered, and became something to sell to salvage something of value from the company, but that’s part of another page of history.