Arbinon.com is a complex group of software servers, database servers with programming, the web front-end, and several internal use tools and applications that have been built from scratch. Collectively, they form the technical platform that the arbinon.com ERP runs on.
As you can imagine, with such a large technical footprint, and ever changing technologies behind the scenes plus changes that Amazon introduces to their MWS and SP-API that we use to sync your Amazon account, we are constantly making changes and improvements.
So that we stay somewhat organized and don't get too lost on details, we track a lot of stuff in order to get the job done.
At the lowest level, we have an Action Item tracking tool (built into arbinon.com in a secret administration screen). Each Action Item gets a unique ID (hence, AID).
- every single bug
- every small added or changed feature (called a "Todo" item)
- every "Story" of something medium sized we would like to add -- such as a new screen or functionality -- which we have spent time thinking about and designing a bit, which turns into a small group of Todo action items.
- every "Epic" which are typically larger scale features -- like an entirely new module -- that is nothing more than a rough concept or idea but we want to track it... these usually get broken down into several Stories and Todos once we start planning it.
As of this writing, there are 729 total action items in our tracking. We have closed off 518 items.
From a planning perspective, we take a look at the various items, and prioritize them. We then Bucket Them into "Waves" so we can focus on chunk of related items at a time. Using those as a suggestion, we then pull out items we want to code now, and group those and focus on putting those into a new Feature Release (FR). So, typically a Feature Release includes a central focus and has at least one new main feature, but may not always, because we could be splitting the development of an "Epic" item over several Feature Releases... in fact we are doing that now... check out our "lessons learnt" below.
When we put out a small change, we may include 1 or more bug fixes and call these Cumulative Updates (CU). No matter how much we test, there are always going to be bugs and issues. Our imperative is more about developing processes that prevent bugs from getting into the code in the first place, but we also are human and make mistakes. The quality processes we undertake today are 5x what they were even at the start of 2021. Lots of automated and manual testing. We've even created a new internal "Sandbox" environment we are starting to do more Q.A. with prior to launching directly to production. Even when we release a new version we do some spot testing before making an announcement because sometimes things that work on our development servers don't work the exact same way on the production servers.
Lessons Learnt:
The lesson learnt was that we needed to change our development scheduling to have circuit breakers that prevents long durations of new development activity blocking maintenance and support development. We need to be moving things forward at all times.
What that long duration for getting FR06 did was that we didn't do any new onboarding. We often find that during a round of onboarding, Amazon throws some curveballs at us and we typically need to make some code changes to work around their limitations and gaps in the data flow.
The way we were scheduling our development and producing releases made it technically challenging to "pause" active development on large features to fix bugs "in the moment". We've re-thought our approach and now split those bigger builds over several feature releases so that we don't get in a bind, and we can continually push out new features with every release, while at the same time building towards the large "story arc" and also have the flexibility of handling bugs and customer support issues as they come up.