These guidelines are a starting point. Each project and client has different requirements that we should adjust to accordingly. The goals of development standards are to drive the efficiency and quality of the work we do.
- Do great work and be great to work with.
- Embrace change.
- Be solution-oriented. “No, but…”
- What’s right for the project is not always what’s easy for the developer.
- Make the complex simple.
Instrument’s primary focus is on user experiences whether they are web, native applications, physical installations, connected products, or AR/VR. To support these experiences we work with everything that takes us from ideation to prototyping to execution and deployment.
Select the right process
Every project needs good process to drive efficiency, quality, and creativity. It’s important to agree to a process up front with careful consideration of what the best process is for the project requirements, stakeholders, and delivery success. Buy-in by all disciplines, and not just development, is critical to successful adoption and execution. This means you may use different processes for different projects.
Select your SDLC methodology
Agreeing on the SDLC model up front is critical to the smooth operation of a project. Depending on project and client needs you should be able to flexibly work within several different models.
At Instrument we regularly use SCRUM, Kanban, and iterative models in most of our projects.
Evaluate your process
Routinely review and evaluate how a process is working for your team and client. Don’t be afraid to implement changes that improve efficiency, product quality, and quality of life.
Nothing beats working side-by-side, but it isn’t always an option. We use multiple levels of communication and collaboration that respect people’s time and focus needed to execute work. We primarily use Slack as a way to quickly and efficiently communicate or request more personal communication. However you best communicate, doing so frequently is a cornerstone of how we work together.
Be involved in design
Creating compelling digital experiences requires a close relationship between designers (visual/feel) and developers (execution/function). Pair programming with designers allows a free exchange of forward-thinking ideas that are both feasible and compelling. Injecting developers early in the design process cuts down on wasted effort and produces more innovative ideas.
Develop as a team
We don’t expect our developers to figure everything out by themselves. As a team, our shared knowledge and joint problem solving allow us to move quickly, arrive at solid solutions, and continually learn from each other. Slack is a great way to start communication unobtrusively. From there you can request face-to-face time or agree on other methods of collaborating.
Using a ticketing system is critical for setting expectations, forecasting delivery, predicting velocity, and understanding requirements. We use meaningful titles and descriptions in tickets and keep them up-to-date so the team knows what everyone is working on and what the current status is.
Check code in often
We check in our code often to protect against device loss, sickness, and other cases where a developer may not be able to continue on a feature. This practice helps enforce smaller more frequent feature completion.
Keep PRs small
Focused, single ticket PRs are easier to review and validate. It helps the development team stay efficient by making the pull request easily understandable and reviewable. PRs should be frequent and tied to a single ticket in most cases.
Documentation is a key component of good collaboration and communication. Document as you go with clear code commenting, technical docs, and architecture docs. Writing should be tailored to a specific audience and organized in a way that is clear to new team members and clients.
We aim for the right solution that fits the technical challenge. We avoid over-engineering, keep the end-goals of the project always in mind, and keep it simple. We write code we’d be glad to inherit from someone else. As we rapidly iterate on features, we keep it lean, focused, and don’t prematurely optimize.
This often requires more mental effort and a good holistic view of the goals of a project. Our developers are more than just coders, they’re thinkers, strategists, and creative problem solvers.
Use Enforceable Standards
Often code reviews are just two developers arguing over their preferred formatting. Skip that step and choose consistent styles at the beginning of a project. Then, we can focus code reviews on what matters.
Using a style guide and linting is a great first step in setting up any project.
We often need to adhere to other client and 3rd party standards or requirements (functional, accessibility, analytics, maintainability, deployment, etc.)
We automate development as much as possible. Automation reduces bugs, increases efficiency, and ensures quality. Automating for continuous integration, development builds, unit tests, and deployment is part of our regular SDLC process.
We strive to make every software engineers development experience on a project to be consistent and predictable utilizing technologies like Docker and Kubernetes. Being able to rebuild development environments from scratch quickly is key to flexibility and code protection.
Control Your Code
We always use source code control. It allows us to work in parallel, protects against data loss, and provides for rollback if things go wrong. We have preferred standards for code management but conform to client standards when necessary.
Security is critical in software development and getting more important to our clients every year. Security requirements vary between clients and projects, so it is important to raise the subject early in the project. Come to an agreement with the client and the team what your project’s standards will be, and what process you will use to ensure those standards are met.
Accessibility is a must for modern digital experiences. Not only is it a legal issue for many sectors but it’s part of being considerate of your users. Not all projects will have deep accessibility needs but we should aways start with accessibility being part of the equation when possible.