Low-Friction Development Environments

At Bottle Rocket Studios, we do our best to provide our developers with a low-friction development environment. We do this to help maximize productivity – for both our customers’ and developers’ benefit.

Elements of low-friction development environments

Developers select the tools best suited for a given task

Many projects will have predefined toolsets such as Xcode for iOS and Android Studios for Android, but that’s just the foundation. Developers doing the work should, whenever possible, select the tools they find work best for the task at hand. The only real exceptions to this are tools that may be a security risk or are undeniably less productive. Projects and workflows will vary, so the tools used in each should be expected to change as well. Flexibility has a low cost and can lead to a sense of ownership and comfort.

Developers are free to research new tools as needed

Since developers select their own tools, they also have the freedom to research new tools as needed. From interactive Slack channels to Google searches, there is no shortage of sites to leverage and each developer will have their favorites. This freedom of access will increase productivity. Developers will do what’s needed to get the information they’re looking for; reducing the barriers to doing so means they have more energy and time to spend on projects.

Open Communication

Open communication is a hallmark of low-friction development environments. A developer should never have to wonder the importance of a given task or where it fits in relationship to the project as a whole. Open communication must be practiced to be effective. An organization can’t simply state that they value open communication; it must be demonstrated that communication channels are open and that asking tough questions is acceptable and encouraged. Without asking tough questions, developers don’t get to deliver their best work quickly. Without answers to tough questions, the project is unlikely to succeed.

Developer-driven task sequencing

In a low-friction development environment, developers have the freedom to select the tasks that they will work on at any given time. This does not mean that the features and deadlines are subject to the whims of developers – it means that after presenting a set of requirements and a timeline, the person doing the work knows best how to accomplish that task. The developers best know how to sequence sub-tasks. This removes a significant amount of overhead and gives developers a sense of self-determination that leads to improved productivity and satisfaction.

Freedom to focus

One of the most vital things a developer can have in their work environment is the ability to focus fully on their work. This is not achieved through isolation or being freed from meetings – those come in a close second and third place. The most important thing to help a developer focus on the work is for the work to be meaningful and challenging. When a developer has a challenging (but not too difficult) task that matters to the completion of their project, they’re more able to ignore distractions. Tasks that seem meaningless lead to distraction. It is important to present developers with directed challenges, or they will find their own. They will gravitate toward what they know and enhance or replace solutions to problems that were already solved adequately. Try to focus them on problems that provide the most value to the project like a UI feature that is orders of magnitude better than the norm instead of a slightly more efficient or succinct way to load images.

Benefits of a low-friction development environment

Higher Productivity

When the developer is free to use familiar tools instead of the tools everyone else uses, productivity will increase. As long as their tool is capable of producing standard outputs and follows the same process as the rest of the team, they will work faster and happier. It is important to keep in mind that any burden of converting the work to a team agreed standard format is incumbent upon the user of the unique tool. If the user of the unique tool can prove that it is objectively better and easy to use, the team may switch and evolve. If the tool is truly better, the whole team can eventually see a boost in productivity that rigid adherence to the old way would have prohibited.

Increased Job Satisfaction

A sense of self-direction drives job satisfaction. Being treated as a peer and not a commodity provides a sense of belonging and worth. Truly innovative developers are like good craftsmen – they’ll never be happy building the same set of cabinets over and over. It may be cheaper to build a spec home, but it will never make the cover of a magazine. Similarly, putting an experienced developer on rails and having them fill in templates will make them insulted, then despondent, then someone else’s employee. Similarly, challenging developers with new problems or creative UI will allow them to stretch their skills and produce noteworthy software.

Being low-friction without being no-friction

There are drawbacks to having absolutely zero guidance for developers. For one, each project can be an experimental work of art understood by one or a few people. This is difficult for a maintenance team because they must learn to unravel the new flavor of the month used by the developer. A developer could also take a new direction and find it causes more problems than it provides solutions, putting the project in jeopardy.

Provide developers with challenges that keep them producing quality software without micro-managing them. Encourage them to evaluate the risk/benefit of using a new approach or tool. If the risk is high and the benefit is small or merely cosmetic, have them do a sample project on their own to prove it out. Review the solution and provide feedback. They might have just discovered a valuable new approach and the risk to a project was never taken.

Review projects to give them a health check. It is imperative that architectural review doesn’t become a blocking portion of the development process. However, that doesn’t mean you should defer the review indefinitely. Developers are generally receptive to meaningful and well-delivered feedback. This excludes seagull management where one flies into the room yells a lot and poops on everything. You should perform a considered, prioritized evaluation of the project with explanations for criticism and direction for solving the problem. Present this to the team lead and let them digest the changes and present it to the rest of the team.

Conclusion

Having a productive, low-friction environment for developers requires keeping an open mind about tools and approaches to software development. Good developers have some creativity and are eager to express it. Give them an ability and a channel in which to express it, and they’ll be a long-term asset to the organization. Keep them challenged, but provide direction and monitor their ability to rise to the challenge. Guide them to innovate where needed, and they will produce high quality and innovative applications.