May 26th, 2020

Robust. Lean. Flexible. Accessible.


Every developer is familiar with these words. They are the culmination of what we all strive to create day to day: robust products that are easily read, flexible to new requirements, and accessible for the entire world.

However, developing the perfect component within a project takes time -- a lot of time. To create the best user experience possible you might begin trying to account for every potential interaction, focusing on every browser, and using cutting edge techniques with three levels of fallbacks just in case. This is the pitfall and where it falls apart.

Your once beautifully designed, simple component is now hundreds of lines of code to account for every potential scenario under the sun. There’s a certain counter-intuitiveness to the next statement but this isn't the goal. The goal should be to create a hyper flexible, hyper lean component that might, one day, grow into a full-featured, robust component. Focusing too early on non-required, but nice, specifications will quickly tank your time, budget, and deadlines.

There is no end-all, be-all solution to the above dilemma but there are a few key areas to focus on to ensure that you keep yourself, and your product, on track.

Create a mindset and set expectations

To develop flexible, lean components is more of a "mindset and level-setting of expectations" exercise than a “do X to solve Y” exercise. It’s the mental divide between spending time focusing on the required tasks while not culling creative, enhancement possibilities. If you can separate those two, not only will you deliver what’s required on time but you can come back to the project and provide extra value by pitching a slew of improved mechanics and enhancements.

Balance minimum viable product (MVP) and future functionality

It’s about balance. It’s about creating the barebones, requirement fulfilling components for the task at hand while still ensuring what’s being built could be expanded to accept those new unknown requirements. It requires a certain level of assuming without acting on those assumptions. It’s easy to get lost in the details but to maintain lean flexibility means tackling issues as they crop up instead of all up front.

Develop to spec at the start and expand as data or requirements change. The end goal of being flexible while also staying lean is to avoid fixing and adjusting and rewriting for problems that don’t, and might never, exist.

Constrain creativity (for now)

There’s not much less fun about development than being told to only do the bare requirements and don’t try any of the fun, fancy things. Don’t think of this as a suggestion to never do the fun stuff. The goal here is to spend your time early getting the product built to spec. If you get yourself in the mindset of creating a flexible core system and build out a system that fulfills the requirements, in theory you have now left yourself with more time to tackle the fun things. Keep those ideas handy and act on them -- just act on them after MVP.

Don’t skimp the basics

The last word up there was accessible. There’s a nasty habit in development to save accessibility as a checklist item at the end prior to delivery. But what if you build your core components with better HTML and CSS semantics so that they’re accessible out of the gate? Not only is your system more robust and usable, but you can then spend time later on making improvements, instead of spending that time shoehorning in terrible accessibility hacks later down the road.

All in all, there’s no checklist or hard rules to making sure flexible, lean development happens. Building robust systems that are also lean and only built to specifications while being able to expand to greater things seems impossible. The key is that while everything can happen on your project, it needs to happen in the right order to ensure the time spent is spent as efficiently as possible. Plan your builds with milestones. Separate tasks from enhancements. And bring value to your projects by both delivering on expectations quickly and providing suggested improvements for down the road.