Many years ago, my journey into “Systems” began. At the time, I had no idea where my curiosity would take me and during my time as a student, my interests were so broad I found myself never focusing on any specific subdomain. I ended up taking courses in digital systems and commuication, signal processing, control systems and even remote sensing. I always felt that I wanted to explore and grow in various technologies and domains rather than focus on one specific area. Ironically, I was doing just that, but didn’t realize it. Only in recent years has the idea of a “Systems Engineer” become a specific field of study in which a degree can be obtained. Up until that point, a good portion of professionals who had focused on Control Systems were seen as those which would end up working in a ‘system’ oriented framework. The issue here being that the idea of a ‘Control System’ is limiting in itself when referenced against the backdrop of the other disciplines which are tied in with a true and complete ‘system’. Control Systems, as it turns out, are really just another part of a system.
Out of school, I was immediately hired into the Penn State Applied Research Lab (ARL) into the Modeling and Simulations Group. The concept for the work was essentially to use physics based modeling/simulation and Monte Carlo techniques to support future design and theory. It was a very complex software system and among one of the most challenging systems I have worked with. This was not just due to a very significant amount of domain knowledge in many areas such as underwater acoustics, dynamics, digital communications, but also because the work dealt with how all of these domains interacted. During those years, my mind was expanded to look beyond the components to how the parts all worked together as a whole. I also learned in that time, that computer modeling and simulation can become so detailed and accurate that the only differences become physical ones, to some degree. In other words, the level of fidelity can match that of a literal, physical system.
When I departed ARL, I went to work with the integration of sonar systems into a variety of use case scenarios. Each project had its own challenges. Some of these were so complex that out of necessity, meetings were frequently held with the customer and our team. One of the most difficult challenges in working with a system integration is the intepretation of not only the customer’s needs, but the actual constraints of their system, and many times this process can be distilled into “effective communication”.
One of my first Full Stack Development roles was essentially equivalent to working on a software ‘system’. In fact, to some degree, being a Full Stack Developer role can parallel Systems Engineering in many ways. Just like a physical system, a development stack is comprised of various technologies and computer languages which work in accord to produce the complete website. Some websites are fairly straightforward and are designed with the sole purpose of conveying information. Other sites, such as ecommerce sites, function as important mediators between the customer and the company providing a good or a service. Many companies are permuations of this concept, with varying degrees of complexity. Still, other websites are used solely for the company to digest and present their own data as a way to simplify what would otherwise be an overly complex process. The goal for the company was to bring their company’s data from a cloud based Enterprise Resource Planning (ERP) system and form in into charts and other visualizations so that the workers within the company could have, at a glance, a high level overview of relevant data. The ‘frontend’ was essentially Swift frontend code which displayed the pages as app pages on Apple TV’s in the company. My part was to understand how to retrieve the data, process it and conform it into the JSON data which was digested by the frontend.
My most recent adventure was working on a very complex suite of websites all interacting and producing various outputs depending on use-case. The company had their main website which anyone with internet access could navigate their product line and interact with the company by requesting information or contractors in their system. Aside from this, one site handled all permission and authentication, another site both served as a frontend interface for specific use-cases, but also contained the internal API which was accessible for only authenticated users. So a typical user interaction, depending on use-case could either be a simple page navigation process, down to a highly complex user authentication and permission schema which allowed various permissions/access based on custom methods. Some of the interactions were quite complex and a simple form page might consist of 12 files, spread across the 3 sites, utilizing React, JS, Rails, Pym, Iframes, JSON schemas and no model tied to the validation, making form work quite challenging. The intial development environment took on the order of over 1 week just to work through setup, seeding and navigation of the various permissions just to become functional! As my one coworker mentioned, he had never in all of his nearly two decades of web development worked on such a complex and highly architected system.
The take home point here is that, as a developer, we never know how working with a codebase will be until we have gotten the chance to “dive in”. Full Stack development roles can be considered “software systems” and as such, every system is unique and has its own challenges depending on which languages used, how these languages were used and how complex the user interaction is along with how closely the architects adhered to sound design principles for these languages. The difference between the two above systems was the one took a few weeks to be comfortable working with while the latter took a few months. In both of these projects, the use of Rails was mostly for the framework and it seems what both shared in common was that neither seemed to harness the true simplicity and utility of Rails in that neither system was designed to take full advantage of the Model-View-Controller paradigm, but rather mainly relied on the View-Controller aspects. To me this was unfortunate as the idea of Rails is expedite and streamline development and neither project made full use of this. In the end, this seemed to create the need for filling in for the lack of models. In more complex systems, the timeframe for delivering code to production seems to grow tremendously even with best guess estimates. The reason for this is that there is sometimes not only a lack of personal experience within a particular codebase but also there is often a lack of concretely documented process. Additionally, departure from sound principles governing a particular framework or language invites further confusion and unnecessary complexity. As developers, we will be called upon to tackle difficult problems and there are times when our ability to produce, let alone navigate difficult code will be tested. If working with a company’s code seems to take far too long for what should be a simple process, or, if getting the code functional takes more than a day or two, my personal insight is that this is a good indicator to how the system will be to work with and should serve as a bellwether to guide us forward.