Our Engineering Values, Practices and Habits

While it’s hard to express all of our engineering values in one succinct spot, this page is our stab at covering some of the most important values.  Give things a quick read – we think you’ll find some points you agree with, hopefully some you follow in your organization.

Hands-on coding practices are MUCH discussed (really argued-about) topics within engineering teams and across engineering organization.  Here are a handful of coding practices that are dear within Mercury.

Clean Code

Code is clean if it can be understood easily – by everyone on the team.  Clean code can be read and enhanced by a developer other than its original author and due to understandability, other engineers will benefit from changeability, extensibility and maintainability.

Magic Numbers

A magic number means we are assigning a number with no clear meaning.  Sometimes we use a value for a specific purpose, and we don’t assign the value in a meaningful variable.  The problem is that when someone works with your code, then the person doesn’t know the meaning of that direct value.

Deep Nesting

Sometimes we use nested loops that are difficult to understand. The way to handle that is to extract all loops into separate functions instead.

Comments

Comments help people to understand later, and they help other programmers to work on the same project.  While comments are neither inherently good nor bad, they can sometimes be used as a crutch.  You should write your code as if comments don’t exist – this forces you to write your code in the simplest, plainest, most self-documenting way you can.

Avoid Large Functions

When a function or a class is large, then we prefer that you break it into multiple functions – this will make our code easier, clean, easy to understand and also reusable.

Code Repetition

Repeated code means a code block that is repeated in your code more than once.  These code portions should be extracted into a function and used as needed without repeated the actual code.

Variable Naming

Camel case is the naming standard for variables, functions and other identifiers.  This means a name is supposed to begin with a small letter, and every first letter of the next word will be uppercase.  As in camelCase.

Meaningful Names

Always use a meaningful name for code objects but choosing a name that expresses the meaning of your purpose.  If we need a function that will get the user’s bank information, then using a name like getUserBankInfo would be superior to getUserInfo.

Use Nouns for Class Name & Use Pascal Case

Classes don’t take things; they are the things, therefore don’t use the verb in the class name.  Also, a class should contain Pascal case; Camel case is used for objects, so confusion will ensue if you also use Camel case for class.

Capitalize Constant Values (SNAKE UPPER CASE)

Always use fully capitalized names for constants.  Snake uppercase means all the letters will be uppercase, and an underscore will separate all the words.

Continuous Delivery is the ability to get software changes of all types – including new features, configuration changes and bug fixes – into production safely and quickly in a sustainable way.  Our goal is to make deployments predictable, routine affairs that can be performed on demand.  For this reason, all software at Mercury is built and deployed with continuous delivery pipelines.

Low Risk Releases

The primary goal of continuous delivery is to make software deployments painless, low-risk events that can be performed at any time, on demand.  By applying patterns such as blue-green deployments (a Mercury favorite) it is relatively straightforward to achieve zero-downtime deployments that are undetectable to users.

Lower Costs

Any successful software product (especially when following Agile development) will evolve significantly over the course of its lifetime.  By investing in build, test, deployment and environment automation, we substantially reduce the cost of making and delivering incremental changes to software by eliminating many of the fixed costs associated with the release process.

Better Products

Continuous delivery makes it economic to work in small batches.  This means we can develop as little as a single user story and get feedback from users throughout the delivery lifecycle.  This (and A/B testing using feature flags) means we can avoid the 2/3 of features the industry has typically built in the past that deliver zero value by identifying and closing off Product directions that are of no use to clients.

Happier Teams

Research (and anecdotal experience) shows that continuous delivery makes releases less painful and reduces team burnout.  Furthermore, when we release more frequently, software delivery teams can engage more actively with users, learn which ideas work and which don’t, and see firsthand the outcomes of the work they have done. By removing the low-value painful activities associated with software delivery, we can focus on what we care about most—continuously delighting our users.

It is a bit of a stretch to include “vertical slice” as a strategy in a list of engineering values (since it originates with Agile/Scrum) but since it has such far-reaching impacts on how we develop software, I have.

The term “vertical slice” refers to a cross-sectional slice through the layers that form the structure of the software code base.  In this approach, a vertical slice means a bit of every layer.  Again as an example, a new feature request like “showing x information on main screen” would contain these work bits:

• Work in the UX/UI that will display the information
• Work in the service layer to transform the information
• Work in the database layer to store / fetch the information

The strategic reasoning for this approach is that rather than, for example, building the entire data layer at one time and having zero shippable functionality to ship, perform the needed work across the data, app and interface tier to accomplish a single “vertical slice” (user story) which will have value immediately.  By then stacking side-by-side (rather than one horizontal “layer” upon another) we can slowly build an application with sequential vertical slices and ship value the whole time.

I can tell you from years of personal experience, no much how I might have thought that I understand what, for example, the data schema needed to look like for an entire enterprise application (based on a thick book of requirements, yuk!) I spent more time changing my initial work than building it in the first place.  Likewise with the idea of “we’ll just build the whole interface on what we see from the requirements and we’ll mate it up to the back-end later”.  Ouch.

There is a siren song of efficiency related to “do the whole tier at once” and layering horizontal layers but the truth is that vertical slices are not only better for regularly shipping working software, it also results in higher quality, cleaner code more effectively and often more efficiently.

One of the distinctions at the core of “are you a programmer or a software engineer?” is that of sustainability.  Your application is sustainable if (and only if), for the expected lifespan of your software, you are capable of reacting to whatever valuable change comes along (either technical or business reasons).  At MercuryWorks, we value sustainability highly as both technical and business changes come at us hard and heavy.

An important distinction here is that we value the capability to make significant changes as a result of technical or business changes – you may or may not choose to make the change due to the trade-offs involved but constructing software in such a way that we have the option to do so is essential.