A Glossary of Product Design and Development Terminology

At Revelry, you don’t have to know and you can always ask. Two of our Core Values lay the groundwork for this:

1. “Earn and Dispense Trust”
2. “Fear is the Mind Killer”

There’s a lot of jargon thrown around in software design and development land. Before your eyes glaze over wondering about the last three acronyms you heard, polish up your linguistic lingo with Revelry’s handy glossary of tech terms / terminology below. 

And, as you work with our team of product managers, UI / UX design engineers, and back-end developers, you’re encouraged to ask about anything that’s unclear and to trust we are happy to make sure we all have a shared understanding of any and all concepts. After all, innovation is a team sport.

Glossary of Terms

AC – Acceptance Criteria

Acceptance Criteria define the expected behavior the user should experience when using this feature of the app. AC make up our stories, which make up our tickets. Stories are written in BDD (business development driven) language and broken out into scenarios as needed. Both the PM and the product owner must agree upon the Acceptance Criteria before scoring and working can begin.

Actual Fire

Something has actually gone very wrong and needs immediate attention and fixing.

API – Application Programming Interface

API is a set of subroutine definitions, communication protocols, and tools for building software. We “call” endpoints or data of a particular category to populate a site. As the API is updated, the data and features available to us are updated.

We use the Twilio API when we want to send text messages. We use SendGrid’s API to send emails on behalf of clients. We also build our own APIs for interacting with smartphone applications that we’ve built, as we did with 20Echo.

API Key

A key that connects app to an API (normal and secret); code passed in by computer programs calling an API to identify the calling program, its developer, or its user to the web site.

Blockchain

Blockchain technology is used in certain circumstances when added transparency, verification, and trust are needed. Blockchain is a distributed ledger among every entity in the network. Although Blockchain may be a buzzword right now, we believe in finding the proper use for implementing it.

Using a database might be a good enough option if you don’t need the extra layers of security that a blockchain provides.

Bugs

Bugs are a natural part of software development. A bug is something that doesn’t work as expected. A bug can be something that wasn’t already predefined and is not an enhancement.

Some edge cases are bugs that we didn’t account for in the initial implementation. Many projects use Rollbar, a service that automatically logs a bug ticket when there is an error in the code. This helps the team stay on top of bugs that could manifest in the front end. When a bug is logged by either someone on the team or Rollbar, a PM or engineer will triage the bug to decide on its level of criticality.

We can commit to bug tickets just like feature tickets in a sprint, but a non-critical bug that pops up mid-sprint typically gets worked directly after the commitment tickets have moved to “in review” or QA.

Continuous Integration

Continuous Integration, or CI, refers to the continuous work of pushing new features into the main codebase. We use Travis CI to manage the integration of new code. This allows teams to detect problems early. We use pull requests to constantly update applications while sharing code across teams easily. Before CI, engineers may not have shared code for a week or two. With CI, developers can pull down code changes from other team members while they’re working on their own code.

Test suite finds mistakes before the code gets into someone’s local environment. Coveralls is part of our CI system to determine how much of your application code is covered by tests.

Agile teams typically configure CI to include automated compilation, unit test execution, and source control integration.

CRM – Customer Relationship Management

Practices, strategies, and technologies that companies use to manage and analyze customer interactions and data throughout the customer lifecycle, with the goal of improving business relationships with customers, assisting in customer retention and driving sales

Demo Drill

A team from a project in early-mid active development will invite the entire company or a subset of Revelers to hit the app in real-time to discover bugs and confusing aspects of the application. All of this feedback goes into the #demodrill channel in real-time to be processed by the team later and converted into tickets.

Design and Styling

Design involves selecting the imagery, the colors, and the fonts that feed into the user interface (UI).

Styling is the process of implementing design choices into the code using CSS or SASS.

At Revelry, we always start a project with a living styleguide on a web or mobile app page that will guide all styling choices as the product is built. While Revelry does offer branding services, if a client comes to us with a brand guideline, we use that as inspiration to bring the product to life.

Dumpster Fire

A bunch of things have spiraled out of control for a particular project or client; multiple fires at once; a really serious, business-impacting fire. AKA trash fire.

Elastic Search

Elasticsearch is a highly scalable open-source full-text search and analytics engine. It allows you to store, search, and analyze big volumes of data quickly and in near real time. More on the Elastic Search website.

Fire Drill

Reporting in the #firedrill slack channel any of the above reasons, a thread will ensue with feedback from appropriate parties.

Once resolved, the original person who called the fire drill ~out~ the message and marks as resolved

GitHub Repository

We store project information and code in GitHub, and each project has its own codebase structure. That structure is called a repository. The driver behind the Git framework is version control: the ability to save and separate work so that nothing committed can be lost or overwritten.

Our engineers deploy their codebase to each project’s repository. And, the whole project team writes tickets using GitHub Issues in order to prioritize work. We also use a kanban tool in order to move these tickets through each sprint. AKA Repo.

Harmonium

Harmonium is a framework of React components optimized for teams that want to ship apps fast. It is a curated list of components that work together and have cohesive styles. One of our design goals is that you never have to research and handpick component packages. Whatever you need is already here.

You can find the gallery of components at Harmonium.Revelry.Co, and it’s open source so anyone can contribute to it!

How We Roll

How we work, our process, what we build, and how we build it. See Also “The Process”.

Implementation/ Implementators

The implementation team at Revelry are our developers and engineers who work within a codebase. They are the builders of products and writers of code.

We have a wide range of languages and backgrounds that our developers come from before working here. Knowing a particular language is not a requirement for working as a developer at Revelry because we place strong emphasis on pairing and continuing education. Some of our strongest developers were startup founders or worked for Fortune 500 companies.

Labels (Github)

We use GitHub labels to quickly identify tickets on the kanban board. (See GitHub repository, below.) This allows us to quickly scan the board and visually see the current status of tickets. Labels can also be used on Pull Requests to know the status. Some common labels are:

• Draft
• Blocked
• Points 1-13

Almost every ticket has a label to help the team quickly understand the current status of the ticket. A freshly opened ticket is labeled “draft” while the Acceptance Criteria (AC) are written and agreed upon. The Product Manager assigns the Product Owner to review and approve the AC by removing the “draft” label and adding the “approve” label. 

When the Product Owner approves the AC, they replace the “approve” label with a “SCORE” label. This lets the producer know that the ticket is ready to be scored during the next planning poker session.

“Blocked” is a frequently used label. If someone has a question or can’t move forward, they will leave a ticket comment clearly stating the question or need, add the “block” label, and assign the ticket to the person they need an answer from.

Merge and Deploy

Merging is the process of merging a new set of code written into a larger codebase. Before this can happen, we have lots of layers of review by both bot and human.

Lintron is a bot that checks all code. Once that checks out, another developer, either on the project or not, is assigned to manually review the code. They can either leave feedback or merge the code in.

Deploying code involves pushing a codebase to a Heroku instance. We like using Codeship because it does this for us automatically when code is merged. Therefore, the new code gets pushed straight to staging, which is where our quality assurance (QA) team gets to work testing.

Mockup

When a project calls for it, we’ll create static mockups for screens so that the team can collaborate on UI, UX, and design before implementation and styling. These are useful for establishing a look and feel on the first few screens/pages of a product and for getting product owner buy in.

Pairing

This is what we say when two teammates, usually engineers, pair to solve a problem, and usually it’s pairing to code. One engineer “drives” another watches “over their shoulder” to give input. (This is often done remotely, such as over Zoom instead of side-by-side.)

Typically, the teammate who is learning something will “drive” while the more senior engineer gives guidance. At the cost of about a 15% increase in development time, pairing produces code with fewer errors, and even makes us happier at work.

Production

Production is the live site, for the most part. The production site can be used for user acceptance testing (UAT) after QA and regression testing has been completed, but typically UAT occurs on staging.

Some code, like payment processing, requires testing on production with real credit card credentials. Merging to “master” and deploying to production tends to be a controlled exercise for our team.

Some of our project partners have a weekly standing deploy time where our devops team member will oversee the push. Then, the rest of the team can test to ensure nothing broke. If and when this happens, we already have people’s attention to quickly assess and fix the issue.

Project Management

A member from project management serves as the Scrum master. Project management involves moving the project forward while managing all of the moving parts: resources, decisions, ideas, bugs, features, etc.

Since we move so quickly and do one-week sprints at Revelry, it’s easy for a project to go off the rails in a short amount of time. This is why one of our core philosophies is “call your shots”. That way, everyone on the team is aware of what you’re about to do and can provide input or pivot you if needed.

The PM takes this responsibility full on by constantly striving to understand the product owner’s priorities and keeping the project team informed. In exchange, the PM helps unblock the team and decipher issues or speed bumps and relay to the product owner.

QA

Quality Assurance is both a department and a part of our process here at Revelry. QA team members test the applications that we build on staging and production. They check that what was spec’d to be built is built the right way, and help us identify areas of our products that need more work. In layman’s terms, they make sure we have crossed our t’s and dotted our i’s. QA is also responsible for exploratory testing the product and logging any bugs or regressions found.

Refactor

Clarifying and simplifying the design of existing code, without changing its behavior.

Refactoring can sound like a negative thing to clients, particularly when the term is used while problem-solving a bug. Refactoring code does not necessarily mean changing code that was written poorly before. Instead, think of it as optimizing old code to better fit within new code and infrastructure as the project goes on.

Refactoring is a never-ending job that should be done whenever work is performed on a codebase. Our team actively refactors code while working on new, similar feature work. 

But sometimes, an engineer will pause and call out a specific component that has grown so much through the course of the project that it needs some extra love to get it into the healthiest place possible.

As a PM, I encourage my teams to refactor often and allow them the space to do so when they recognize opportunities. This means the team cares about the code quality and is invested in your product’s long-term health.

Regressions

When something worked once but an unexpected event occurs, it regresses back to a state of not working. Regressions are caused by bugs in the software due to new code being deployed into the existing code. While Revelry does a solid job of documenting, commenting, reviewing, and coding clean in general, regressions are also a natural part of software development.

When this happens, we treat the issue like a bug with high priority. The steps to reproduce are logged and we bring it to the top of the icebox to prioritize and work via the process. So if there was AC previously written and worked for the issue you are seeing, it is a regression.

Service Configuration

Arrangement; or the process of making the arrangement of the parts that make up a whole. 

Specific hardware and software details in terms of devices attached, capacity or capability, and exactly what the system is made of.

Smelling Smoke – Raising a flag, prelude to a fire drill or fire. This can be a gut feeling, seeing a comment, something missed, ideally seen from _before_ the fire occurs. The best way to handle smelling smoke is to call an informational fire drill.

That way, all eyes can be on the issue at hand and people can be aware or guard against

SSL/TLS

Commonly known as SSL (Secure Socket Layer), today it’s called Transport Layer Security (TLS). This is an upgraded version of SSL, and both of these things are options for a Security certificate for websites. Steps we take to secure websites include redirecting http to https. We also deploy security layers when sites utilize payment processing or other sensitive information. But at this point in web development, Google’s algorithms pretty much want every site to be a secure site, even if no sensitive information is being transferred. So, if we’re building a site for you, you’ll get familiar with security terms.

Staging

Staging is a test site, usually run through Heroku or Kubernetes that hosts our client’s site. Only our team can access staging; it is not open to the public. This means we can test and play and mess up and get things straightened out before pushing to production, which is typically the live site.

We seed realistic data whenever possible to replicate what’s on production, however, staging and production are hardly ever exactly the same. When the QA process has been completed, we can merge the branch from “develop” to “master”, to view the code on production.

This is typically done manually in a more controlled way to allow for immediate testing and fixing of any bugs or discrepancies that could affect our client’s business.

Technical Debt

“Tech Debt” is the concept in software development that a short term approach was used, and there is a cost to update and rework a better solution to move forward on additional progress.

A concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Technical debt is the time and effort lost to short term solutions that require extra development cycles to update portions of the software to better code.

The Cluster

A cluster is a piece of software that lets us use virtual computers in the cloud as a single system to host and configure multiple software applications with a unified administrative interface. The Cluster is our own, home grown hosting platform at Revelry. We started building The Cluster in summer of 2017, and by fall 2017 we started putting apps on it.

We built The Cluster to replace Heroku, and we’ll eventually release The Cluster as an open source Platform-as-a-Service to be sold and licensed to other teams. The Revelry Cluster aims to provide the ease of management of a solution like Heroku, with the low cost and portability that comes with platform independence.

Building cluster infrastructure is very difficult and time consuming, so many developers and businesses look to outsource to a reliable provider. Organizations need to get to building and scaling applications faster. We know that at Revelry, and everything we build is to serve that purpose.

The Tools

We use these tools to automate our development — try them out and let us know how they do.

• GitHub – Story tracking
• Kanban – Automatically-updated visualization of Issues
• Standups in Slack – How we automate standups at Revelry
• Codeship – Automatic code deployment and continuous integration
• /Poker – Slack bot for efficient story scoring
• Issue Bot — Slack bot for creating GitHub issues

UAT / User Acceptance Testing

UAT is where the product owner checks what we’ve set up in staging against the AC. Since the product owner knows their customer or user best, it is helpful for the team to receive feedback on this feature from that perspective. Similar to the QA process, once the product owner tests against the AC on the proper devices and browsers, they can comment with feedback and assign back to their PM, or close out, meaning the issue has passed their expectations.

UI / User Interface

UI stands for user interface, which is how the design and styles are applied to the digital product. A bit simpler than UX, UI determines all of the styles that will be used in the product, from the H1 font to the button border width, while also taking into consideration responsiveness of screens and devices.

At Revelry, our design team members can also do front end development, so our designs are involved not only in the design and UX discussions but also the implementation of the UI. Throughout a sprint, designers and developers will tag team tickets: passing a ticket back and forth until both the implementation and design meets our standards and acceptance criteria (AC).

UX / User Experience

At its simplest form, UX is considering the user’s experience as they use your product. Revelry approaches this starting with userflows, which can be accomplished in the form of flowcharts, wireframes, or acceptance criteria. Device or browser usage constraints also factor into UX decisions.

Pinpointing the target audience is key. It’s important to know what drives your audience. What do they want to do with your product? What problem is your app solving for them? How old are they? What is their level of technical experience? Developing user profiles is an excellent exercise that we encourage all of our clients to do, particularly startup founders. The more an ideal user can be described, the more tailored the user experience.

Wireframes

Not intended to serve as a visual indicator for how a page or feature will look, wireframes are more for base-level planning of how the user will get from point A to point B.

Wireframes are a good place to start before creating full mockups. Sometimes, wireframes are viewed as the “skeleton” of the site. We use them more for outlining everything that needs to be included on a single page before deploying UI/UX to refine. A wireframe at Revelry can be as simple as a sketch in a notebook or whiteboard, and as elaborate as grayscale mockups using tools such as Balsamic or Sketch.