If you are old enough to remember the old Tandy computer and Apple IIe, then you know the computers that I used to learn BASIC during a summer program in my youth. This set off a great curiosity for programming which I eventually used to modify the Money application that came with DOS 6 for my dad to maintain 99 accounts instead of the handful that was allowed out of the box. We could laugh at how basic that is (pardon the pun) but keep in mind that I was still just a child playing around with BASIC.
Unfortunately, someone had told this impressionable youth that work is called work for a reason, and you should never do what you truly love as your work or you will learn to hate it. While an uncle of mine helped me find an alternative that I would enjoy, this one piece of bad advice helped push me away from programming and into Engineering Technology for my college degree with a major in Electronics. In the course of those studies, we had 2 semesters learning about microprocessors, and I learned to program with Macro Assembler (MASM). This was an eye opening experience writing such low level code, but I learned how to write key loggers and hook into the old built-in speaker to play Mary Had a Little Lamb controlled by the real time clock. I also learned about TTL logic where we used TTL chips to hard-code logic and made a circuit board and power supply using supplies from Radio Shack.
My First Programming Job
Having spent a number of years on the PC and Unix support side for my career, a company nearby needed a programmer and was willing to train. I was fortunate to land that job where I learned to customize Symix written in PROGRESS. That job allowed me to explore my long suppressed developer side and started a 20 year journey into career development. My first month was spent reading the programming guides and studying code before I was allowed to touch any code, but soon I was fixing transaction scope problems in our code and exchanging help on the Progress Email Group (PEG). That constant problem solving forum enabled me to grow as a programmer, both in PROGRESS skills and general logic mentality.
After about a year and a half, I was presented with the opportunity to help start a users group for PROGRESS in somewhat nearby Nashville. When my boss found out, he told me that he could not support that, even on my own time. Needless to say, I was crushed and shocked. He reasoned that it would only help me to make other contacts that would lure me away. Ironically, given what he had just told me and after some discussion, he gave me the push I needed to start my next great adventure… something like, “You are welcome to stay here as long as you want, and we would hate to lose you. But with your age and ambition, if I were you, I would look for a job that is more cutting edge and can challenge you more.” With that, a month later I moved just outside of Nashville, Tennessee, to a company that used almost the exact version of our same software. With their support and investment in me, I am still there 19 years later with a wealth of other experience under my belt including programming, unix adminstration, training, quality, implementation, operations, and project management… and of course, Acumatica.
The Move to Acumatica and C#
Our legacy system was solid and supported our business, but the technology behind it was aging. The effect was that it would be harder to integrate with future customers if we didn’t make a change. We struggled and failed to implement Oracle and SAP effectively, and our legacy systems had been enhanced with the changing demands of the business to the point that developers on these other software platforms simply could not match our pace. I was actually told by the CIO that we needed to stop enhancing the system (even though it was to support the needs of operations) because we kept raising the bar on the new project. That was a good signal that we had the wrong product in development. It was also a sign that we had the wrong CIO, which was corrected in time.
My employer made the decision to move to Acumatica in 2018. Having sent me through various roles in just about every area except accounting, I was asked to return to my IT roots as the main developer for Acumatica. My counterpart handling the application and administration side was once the other half of the development team that kept our legacy system evolving, and eventually he had become my boss. When I had been presented with the opportunity to move into the operations side of the business, it was a dream come true and also a rather terrifying endeavor to embark upon. However, it ultimately would prepare me to look at the software not as a programmer, but as an operations manager and end user. While I never completely left my IT roots, I did get a new boss and different responsibilities. However, our friendship and mutual respect and support over the years would make us the ideal team to pair up again for Acumatica.
Looking at Acumatica from the perspective of “how do we run our business on this” rather than “what can I do to this” has led to some very productive discussions and development. As a two man team, we set out to fill in the gaps that standard Acumatica left for our niche in the market. Our business, after all, is about managing the MRO Spare Parts needed by maintenance to keep a plant running. ERP packages fail to support that area to the extent that our business focuses, and our place in the market is to bring availability and reliability to the spare parts needed by maintenance organizations. This would create a target rich environment to fuel my learning and creativity.
Some of our enhancements include creating modules for managing repair of spare parts used in the plant’s equipment, calibration of tools used on the production line, a robust capability for consigned inventory and multiple ownerships for the same items, and an enhanced requisition module for maintenance to request parts in the system as well as those not in the system. These enhancements were created to help us provide our services to a client, and not something we sell as a VAR currently. Of course, if these are things you need, I’d love to hear from you.
I decided to write this blog in hopes that the next generation of Acumatica developers might find something useful. Active development changes your perspective over time, and things you thought were great sometimes turn out have a better way of doing it. The way I see it, if I can’t explain it then I don’t know it well enough, so the research to explain it helps me tremendously. Please contact me with any feedback you may have. If you see something posted here that might be handled better, have general questions about what you find here, or have some tips you’d like to share, I’d love to hear from you.