How to Use The Rule of Three to Ship a Better Product

It’s no revelation that the technology industry can never let well enough alone, and for good reason. The nature of tech is rooted in rapid innovation: companies must continually pivot, build, and launch new products and features to outrun obsolescence. Project managers and engineers alike endlessly calibrate productivity through a myriad of methodologies. Thus, work processes emerge and adapt, albeit not as expedient as the software built and iterated upon such philosophies. The familiar dogma of proven strategies echo throughout every office. Perhaps the great acoustics for strategy reverb is why open office plans gained so much popularity in the past decade? When pressed, team leads crack a half-smile as they acknowledge “yes, we’re agile…ish” or nod sagely with the bold claim of running a lean operation. That beautiful waterfall methodology softly rings in the distant past, but the passé cubicle walls obscure the sound.

Everyone is familiar with the “pick two out of three” triangle of project delivery and constraint. If you are not acutely aware, the corners of which include: timeliness, quality, and reasonable cost. (Apologies for the obtuse polygonal pun). All three corners have the utmost importance, but survey says only two are realistically achievable. Everything in balance.

When it comes to creating software, engineers are not exempt from these seemingly managerial preoccupations. From a programmer’s perspective, task and project deadlines are certainly relevant enough. Identical to the triangle concept: code quality, speed of delivery, and the cost of technical debt must be acknowledged as priorities in balance. Is it possible to achieve all three to an acceptable degree?

Taking a step back to observe, there is a noted dichotomy between engineers who have a tendency to slowly write and rewrite the perfect code in the most optimal (often shiny new) language, and those who churn out code so rapidly it ends up more brittle than a piece of ancient pottery dipped in liquid nitrogen. The majority of developers end up somewhere in the middle of this bell curve, but lean one way or the other under pressure.

With the former, the code is never considered complete enough to ship, and takes ages to write. It may be the most beautiful code anyone’s ever laid eyes on. However… users will (hopefully, barring any security breach) never see this pristine part of the product. Yes a sturdy foundation is important — but is not paramount. Getting something reasonably complete out there for users to get their hands on is the business objective. Conversely, spinning up code quickly to the chagrin of quality is a recipe for disaster. Hey, who doesn’t love broken software? Bueller? 

To get a project delivered with a pleasant blend of quality, timeliness and architectural soundness, write code with the following three in mind:

1. It actually works of course — in a performant fashion

Yes, it’s a given the code must work. Cover the default path and few top edge cases for starters, and ensure sure it loads quickly. If you absolutely have to wait a few seconds for a heavy API call, add a simple animation. It’s not fluff if it helps your users gain an extra second or two of patience before they bounce.

2. The code is easy to maintain

Maintenance of code is a top tier objective, since it’s extremely rare the only person who wrote the code will only be the ever person to work on it again. Cleverness should not be valued above ease of understanding. A general rule in improvisational comedy is “be obvious” — a principle that easily translates to writing code for posterity.

3. The project is secure

Last but not least important is code security. In lieu of sacrificing precious time on a programming project, security is oftentimes the first to get thrown out the window — if it’s even considered. However, this is the biggest risk to a company even if a breach is unlikely. Keep libraries and third party services up to date within a reasonable time frame. Waiting years to upgrade could prove disastrous, especially if significant and well-known security breaches are lurking in the version your software uses. Not to mention it’s a time sink being put off to a later date, upgrading old code takes effort. A small time investment up front will assuredly save accrued technical debt with a wild variance of interest rate depending on how vicious a security vulnerability proves.

A blend of the above three goals might not solve all your problems when it comes to delivering a high caliber product on the tech scene. Omne trium perfectum is a Latin phrase that defines the rule of three — When things come in three it feels more complete, satisfying, or effective. Go for omne trium productivity and see if it balances out your team.

Learn more about Self‑Directed retirement plans with our ultimate guide.

Get your FREE copy sent straight to your inbox now!