First of all, nothing is truly "future-proof." I know my code will never be perfect and I'm always trying to improve. However, I believe thinking about how to reduce vulnerabilities in your code helps improve its sustainability.
My definition of Future-Proof Development:
A method of building components for the web in a way that can accommodate most contexts outside of project-specific requirements and endure future browser iterations.
A key part of this methodology is to think outside of the immediate requirements, anticipating how the user could interact with the component and build fail-safes for those edge-cases.
What prompted this idea?
At Vodori, I was leveraged primarily for my HTML/CSS/Responsive expertise. I floated across many project teams, in and out of sprints patching up many visual bugs that could have been prevented with this "Future-proof" methodology.
What makes it "Future-Proof"?
This is not a new concept . Everything I practice is a culmination of the work of industry leaders. The focus of "Future-proof development methodology" has roots in minimalism.
As a former designer, concepts like "minimalism" influenced my career trajectory. The concept of stripping something down to its core with the goal of telling the story more effectively really resonated with me.
Minimalism is very applicable to software development plays a big role in this "Future-Proof Development" idea (we'll refer to it as "FPD".) When I'm looking at a component, let's say; a button, the first thing I do is go through my FPD checklist:
- Does this work in legacy IE browsers?
- Is there anything here preventing this from working in all the major modern browsers?
- Are there any unnecessary rules? If so, delete them (with caution, of course)
- Can I do this same thing with fewer rules?
- What does this look like on mobile devices, larger TVs, laptops?
- What is the most simple way I can build this?
Needless to say, even a "small" styling issue goes through a number of mental filters. I cringe when I hear "it's a quick styling issue, it shouldn't take any time to fix."
There's almost no such thing as a "quick styling issue"
On the surface, cleaning up a bug like overflowing text in a container might seem trivial. However, bugs like this end up reaching more people outside of the developer. Let's look at my current agency workflow:
- QA analyst is looking at a feature.
- QA analyst realizes that the text of a button is overflowing a button due to too many characters.
- QA analyst creates a bug ticket and writes acceptance criteria for the ticket. This - includes how to create the defect, an example page where the defect occurs, and what the correct result should be.
- QA analyst assigns a bug ticket to a developer.
- Developer receives the ticket.
- Developer branches off of the project-appropriate git branch.
- Developer fixes and tests the bug.
- Developer submits the branch to be reviewed by a tech lead in a pull-request.
- Tech lead reviews the code in the pull request and initiates any communication with the developer if needed.
- Tech lead merges the branch into the stable branch (develop, usually)
- Tech lead executes a build to a QA environment
- Tech lead assigns the ticket back to the QA analyst.
- QA Analyst reviews the ticket and marks as resolved, or documents if the defect still exists.
That's three people involved, two of them at much higher billable rates than developers (usually). All this could have been prevented with some thought investment. "What happens if this button has a lot of text?" Those 12 steps (give or take a few based on your organization's workflow) and hours of cumulative time would have been saved.
When we are under pressure to work quickly, we as developers can get hyper-focused on the immediate requirements of the feature and lose sight of the bigger picture. If we can take a step back and think more broadly about the implications of our decisions, we could potentially save a significant amount of time, money, and sanity for our clients and ourselves!