In a low-effective developer environment, “everything takes longer than it should,” says Tim Cochran, Technical Director for the US East Market at ThoughtWorks, in a research-based blog post at MartinFowler.com.
As a software developer in such an environment, “your day is made up of endless blockers and bureaucracy. It is not just one thing; it is many. This is akin to death by 1,000 cuts. Slowly, productivity is destroyed by small inefficiencies, which have compounding effects,” he writes.
In contrast, within a highly effective environment, “there is a feeling of momentum; everything is easy and efficient, and developers encounter little friction. They spend more time creating value,” Cochran says.
Maximizing Effectiveness
In the article, Cochran describes a framework for maximizing developer effectiveness, identifying key developer feedback loops. These should be optimized, he says, so they are quick, simple, and impactful for developers.
Being productive motivates developers, he notes, and “without the friction, they have time to think creatively and apply themselves.” Cochran writes:
What I am describing in the highly effective environment is what it feels like to work in a company that has fully embraced a DevOps culture, continuous delivery and product thinking. Very sensibly, most companies are on a journey towards achieving this environment. They have read Accelerate and the State of DevOps report. They know what type of organization they are striving to build. The four key metrics (lead time, deployment frequency, MTTR and change fail percentage) are great measures of DevOps performance.
Micro-Feedback Loops
A primary reason problems arise, Cochran posits, is that, while transforming, the organization has “introduced too many new processes, too many new tools and new technologies, which has led to increased complexity and added friction in their everyday tasks.”
To avoid this low level of effectiveness, he says, “you have to nail the basics, the things that developers do 10, 100 or 200 times a day. I call them micro-feedback loops. This could be running a unit test while fixing a bug. It could be seeing a code change reflected in your local environment or development environments. It could be refreshing data in your environment.” These micro-feedback loops will then compound to affect larger feedback loops.
Read more at MartinFowler.com.
Comments