Developer Workflow

While most will focus on tooling, developer workflow should be the ideal place for a situation that has a golden path while also allowing for as much variation as needed. This means developers should be provided with a main workflow that comes with all the benefits such as continual maintenance and updates. While also having the freedom to chose a different path if they require but with the understanding that all of that overhead will now fall on the team to provide for themselves. This allows teams to make the best decisions for themselves while also allowing most teams to take advantage of the golden path saving them time and resource while allowing them to focus on their end goal.

One of the main objectives of a developer workflow should be to provide feedback to a developer as fast as possible. This happens across many different stages and they are all additive. Starting from the developer workstation itself and going all the way to getting feedback from customer usage patterns. These stages should be thought of as concentric circles around a developer allowing them to move in any direction while still providing feedback quickly and effectively and they work from the inside out each level providing useful feedback. The idea with the concentric circle is to help visualize how quickly the feedback should happen at each level. The inner most circle with build and test should happen almost instantaneously. This should be the lowest friction area. All tests run here should be small and fast and provide feedback if anything is seriously broken or has broken something else. Then as you move further out into larger test and integration tests along with fuzzing, and any other tooling that would provide feedback to the developer. As we move past the acceptance and validation that the changes can be deployed we transition into collecting feedback about the changes as they are deployed. This can start with logging and errors that are picked up when a change is rolling out. Either allowing a rollout to continue or causing a rollback. Then if everything went smoothly the next level is to see how the changes have impacted users and if the changes should be accepted or revisited based on how users have been impacted. This is a key stage in the process that allows everyone to understand and align on why changes are made and what the goal should be for changes. It is also key that if a change is rolled back or removed because of poor reception by users that should not be seen as negative but another positive step to continually providing a better experience to users. No one can guarantee that all of their ideas will have the expected impact on end user. But if you are open to taking feedback and allowing your users to help guide decisions you can greatly improve the effectiveness of everyones work. In this context users are the consumers of your service that could be through a ui, api or any other means others interact with you through your external interface.

Let’s take an example, I believe everyone has tried software that they liked and thought was working for them then one day you open the software and everything has changed and you lose all the productivity this product provided you in the first place. This adds more unexpected work to your day as you have to relearn everything with the new layout and you are now considering other software because if you are forced to relearn something you might as well look around and see if this is still the best thing to learn. It also removes trust in the application and confidence that you want to continue using this in the future. As an example say the transition from windows 7 to windows 8, this could have been done smoothly but large jarring changes were made and huge backlash ensued. The initial reaction was so bad even changes to go back couldn’t fix the problem and windows 10 was expedited to fix the situation. On the other side of this you have products like google search or youtube that are more concentrated around incremental improvements that push the product in a direction consumers enjoy on a continual basis. This provides a more consistent user experience that has the ability to evolve quickly over time while still providing a familiar experience to users everyday.

I think creating a developer workflow that allows for these small and quick changes on a regular basis should be the goal. Developers want their work to be used and get feedback on it, your customers want bugs fixed and new features both of these things can be aligned with a developer workflow that is focused towards this.