Skip to main content

· 4 min read
Josh Kaplan

Despite the wide adoption of modern agile practices, formal engineering requirements remain important in many organizations. Formal requirements are often defined early in a project (i.e. before design and implementation), though they often evolve throughout the product lifecycle. They are important because project and industries that define formal requirements specifications tend to hold engineering teams accountable to meeting those requirements. Formal requirements can derive from industry regulation and compliance standards such as FAA regulations, FCC requirements, NIST cybersecurity standards, HIPPA compliance, PCI standards, etc. or be defined by engineering teams in collaboration with customers to capture project-specific constraints.

· 2 min read
Josh Kaplan

As I built this site, I created a simple color palette; largely black and white with a single dark-blue added to add some color. I am no web designer and it's not a skill I intend to explore with this site. But, I want a simple and professional color scheme so I began reevaluating my color scheme. This post is a visualization of the full color palette.

· 3 min read
Josh Kaplan

Welcome to the first in running series of articles titled Bits of Bad Code! I've always found failure to be a powerful learning mechanism. The ability to learn from the failure of others is an important part of that. This article series stems from a habit a built up with some of my teams to share example of bad code we've found and talk about why they are bad and how to make them better. This has been a fun experience for a my teams and a wonderful learning experience for growing software engineers. The goal of this series is to share similar examples of bad code and talk about how to make them better.