There's a Cost to Performance
Published: Wed, Jan 24, 2024
During one of my engagements, I spent a lot of time taking in the language and tooling which our clients were using. I was left to wonder about the decisions that had been made about their software over their product's lifespan. Most of their code was written as a monolith in a compiled language - C# and .NET. Rather than RESTFUL APIs or another industry convention, they developed custom communication protocols for each leg so that each of their sub-systems could exchange information. Any change in one system's data needs would necessitate a ripple changes at pass-through points causing feature or bug patch deployment timelines to be glacial.
Practically everything that their platform did could have been built with javascript, ruby, or python - the languages that I prefer. There are of course exceptions - specialized telephony + IVR mechanisms are some examples. However, I could find an existing services with SDKs to satisfy business needs. My focus should be on the codebase's core purpose and not creating or managing the underlying technologies. I'll let someone else focus on the intricacies of a specialized service and all the maintenance burdens it necessitates.
There's a tradeoff between raw execution speed and speed of development. Abstractions -or relying on other services- lengthen execution time because of delays introduced down the execution stack. Each level from an operating system to a web page is underpinned by an ecosystem of services provided for by a lower level of abstraction. Raw computation speed may be alluring but in order to create specific functionality, more needs to be accounted for. The "closer to the metal" programs execute, the less the number services a developer can build upon.
For example, a computer churns through many layers of abstraction just to handle a button click on a web page. The computer needs to brute through the activity the button initiates then can stop right as soon as it has a result. A website's button click feels instantaneous if it reacts in under 100ms. In terms of computing, milliseconds are painfully slow. However this is acceptable performance from a button on a website. Let the lower layers thrash about as they will just as long as it produces the intended interactivity in reasonable amount of time.
In contrast to the web button, should a program have to run frequently or for a span of time, the delays compound and can become unacceptable. To correct for this we are then forced to step down one or more abstraction layers to bring the system back to speed. One commonly sees this when working with relational data at scale. It is common to side-step an ORM to write database queries directly for key data retrieval activities to improve overall system performance.
Going back to the client engagement, they were using speed to solve for a different problem. Development on their platform has been thorny because of its long life and their development practices. All of the ad hoc communication protocols, myriad hot-fixes, and shimmed in features (some not even still in use) made the platform labyrinthine and brittle. They needed the speed because they had a complicated system. It was doing a lot of things under the hood! A seemingly minor change - increasing the length of a text field to accommodate a long company name - created multi-ticket work. The db table row needed to be updated. As did the stored procs. Pass-though services needed updates to handle the changed string length (yes, really!). Finally, the front end form's validation needed to be updated. Is it worth the speed to make it painful to make such a small change? Or should they be solving for underlying issues system communication? That underlying issue was so difficult to address that it was ignored as long as possible.
One has to make the most value through tradeoffs. One one hand, one can relinquish control of how things how things happen to speed development and decrease maintenance burden. On the other hand, one can produce a very fast software but at increased development time and maintenance cost. One also has to think about where these tradeoffs intersect. Being able to address these tradeoffs early in a project could save a lot of difficulty down the road.
I'm open to work!
- Hi all! I am seeking a remote engineer position that can leverage a unique history of IT experience with several years of developing web applications.
- I've worked most recently with JavasScript, TypeScript, Python, PHP, and Ruby but am game to learn other scripted languages.
- Most importantly, I am all about making positive impact at organizations that see inclusivity as a strength rather than an obligation.
If you have room on your team and need someone that can contribute beyond just code, hit me up!
