Bullet Proof Development

What is "Bullet-Proof Development?

First of all, nothing is truly "bullet-proof." I know my code will never be perfect and I'm always trying to improve. However, I believe there are methodologies that can reduce the number of vulnerabilities in your code.

My definition of Bullet-Proof Development: a method of building components for the web in a way that can accommodate most contexts outside of project-specific requirements. 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 styling bugs. So many of these bugs could have been prevented with Bullet-proof development methodology.

What makes it "Bullet-Proof"?

This is not a new concept. Everything I know and practice is a culmination of knowledge of industry leaders. "Bullet-proof development methodology" is not about over-engineering, or accounting for every edge-case. It's more about minimalism.

Minimalism?

I started my career as a graphic designer. Terms like "gestalt", "visual weight", "minimalism", are examples of some of the vocabulary of that world that are very applicable to web development.

The term "minimalism" was one that always stuck out to me. Most likely because it is so widely applicable in contexts beyond the work I do every day. The concept of stripping things down into their most core with the goal of telling the story more effectively really resonated with me.

Minimalism plays a big role in Bullet-Proof Development (we'll refer to it as "BPD".) When I'm looking at a component, let's say; a button, the first thing I do is go through my BPD checklist:

  • Does this work in IE8?
  • 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?

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 no such thing as a "quick" styling issue

On the surface, cleaning up little bugs like overflowing text in a container seem innocent enough and not very time-intense. However, little bugs like this end up reaching more people outside of the developer. Let's look at my workflow at Vodori:

  1. QA analyst is looking at a feature.
  2. QA analyst realizes that the text of a button is overflowing a button due to too many characters.
  3. 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.
  4. QA analyst assigns a bug ticket to a developer.
  5. Developer receives the ticket.
  6. Developer branches off of the project-appropriate git branch.
  7. Developer fixes and tests the bug.
  8. Developer submits the branch to be reviewed by a tech lead in a pull-request.
  9. Tech lead reviews the code in the pull request and initiates any communication with the developer if needed.
  10. Tech lead merges the branch into the stable branch (develop, usually)
  11. Tech lead executes a build to a QA environment
  12. Tech lead assigns the ticket back to the QA analyst.
  13. 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.

TLDR;

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!

Previous
Previous

My First Large Scale App Experience

Next
Next

Communication > Coding