The 80% abstraction
<p><a href="https://en.wikipedia.org/wiki/Entropy" rel="noopener ugc nofollow" target="_blank">Entropy</a> is a universal law: everything tends toward disorder without reinvested energy. Software is no exception. When evolutionary development is constrained by time and/or budget, systems become “monolithic”. That’s often a euphemism for spaghetti of inconsistent abstractions.</p>
<p>Gusto has been building Payroll software for over a decade. We now serve over <a href="https://gusto.com/about" rel="noopener ugc nofollow" target="_blank">300k businesses nationwide</a>. The abstractions we started with have grown along with our customers’ needs. Not to mention ever-evolving government & compliance requirements. People spend years becoming expert payroll professionals.</p>
<p>Ideal engineering balances requirements & constraints: solve necessary complexity, but simply, quickly, efficiently, and accurately. The resulting tradeoffs are universal in software growth, and even life: minding the future too much, or not enough. Both extremes are costly. Perfection protects the future but costs time & money, and is risky besides: the future is elusive & ever-changing. Speed protects the now but risks unnecessary complexity or even rework as we add features.</p>
<p>Let’s explore that tradeoff, and how we get to monolithic software in the first place. Then we’ll talk about a method to find simplifications in a complex system. We’ll use Ruby on Rails ActiveRecord abstractions as an example.</p>
<p><a href="https://medium.com/gusto-engineering/the-80-abstraction-d8ab95ab22f3">Visit Now</a></p>