To some, winning means finding what works and to keep on doing it. Many franchises have been built and continue with the strength of this truth. Is this concept universal? If a truth appears universal, but something changes with our products, and services in creation, distribution or consumption we call that change disruption. The question before us to day is related to developer environments. Has something changed that would be disruptive to following what has worked for us time and time again? Is what we know, what we are familiar with getting in the way of what we should do today?
Disruption is more than the evolution of business and technology practices. Disruption is the season when previous and current practices don’t smoothly transition to the new reality. Things that were facts before shift from relevant to irrelevant. We are going to look at recent changes to development that for a few may be pivots, but for most businesses, the slow steady pivots were not a winning path to productivity and focus. Therefore, for the majority of us, these changes of modern development environments will effectively be disruptions. Yes, these are needed changes.
We will look at why the changes are needed as well as the cost of not changing. The article will cover technical focus but we will keep the content broad because we realize technology is here to serve business needs. Therefore in respect of the non-technical audience we will try to not geek out here.
What is Productive Friction?
Developers have a nearly universal tradition these days when working in teams. We have what we call sprints. Sprints may be one week or one month. Typically they are two weeks long in my experience. Sprints are the start of new sets of features and issues work that will be promoted to production. The word sprint is a good term for understanding what is meant by productive friction.
When sprinters settle in to start a race, they settle into starting blocks. The purpose of the starting blocks is to come up to speed faster. It increases traction from the very start of the race. There is no question that using starting blocks translates to faster race times. Imagine if you were a sprinter when they started using starting blocks, and you had to run the race without them, and most of the other racers were using them. This is what we call, in business, disruption. Doing things the old way will not produce as predictable a win as it used to. In this case, it is time to pivot or get out of the race.
Starting blocks are positive traction, but there are other positive reactions. Runners often talk about having the wind at their backs. The wind also has friction and tends to pull the runner toward their goal, but only when the wind is at their backs. When running into the wind, it is negative traction. The friction of the wind is resisting the runner’s objective.
When we translate that to writing software, we want to be aware of both types of friction challenges. The starting block is a routine positive friction that we apply in every sprint. Getting started delays the time to productivity. Sometimes we may have a benefit in delaying. Yet, when it comes to modernizing development environments, the changes of recent times have just as disruptive an impact as starting blocks for sprinters.
The other type of productive friction may seem more abstract. That is, how do we deal with making sure the wind is at our backs or reducing the impact of the wind in our faces? This is not an abstract challenge in writing software. It is a real and present challenge for all projects that are complex and longer in terms of creation and in terms of support. As stated earlier, we will skip the technical here to keep the article digestible to the broader audience.
What changed?
First, we will look at the starting block style changes.
For decades the way to create software has been to set up a computer with all the toolbox and workbench as a local workspace. Many failures can be answered with the question, what changed? Pushing our finished works to production is moving to a system that is different from our development space. The more differences there are, the greater the chance for production issues.
If pushing to production wasn’t enough, there is the whole challenge of two developers thinking their systems are set up the same, but they are not. I have worked at companies with multiple teams, and the projects a team is working on are going great. Then a developer gets shifted to a different team, and it feels like the sprinter walking up to the starting line with no starting blocks. Something is different.
Second, we will look at headwind style issues.
On new projects, there are change orders. On old projects, changes could be external systems that the old system needs to work with. It could be new features being added to an existing system. Few and far between are the systems that don’t require change. As we change, older assumptions lose focus, and the chance of creating issues rises. Developers call these regression issues. One of the ways to prevent this is to do regression testing.
There is a hard business challenge here. It is actually not as much a technical challenge as a business challenge. Changes, as systems grow in size and complexity, can make the system brittle. On a sailboat, this is definitely true. The larger the boat, the more things need to happen together to be agile on the seas. This is true if the wind is at your back or in your face. Time to respond is a high-value reality both on sea and in business.
So we now understand the principal types of challenges.
Understanding the Developer
It took the developer time and focus to be able to code and produce something that moves a business forward. In technology and beyond, we refer to that part of the work as implementation. The implementation comes in layers like onions that make those outside the specialty cry as the layers get peeled back.
So, when working with developers, communication is critical. Each of us, when we are challenged, gravitates to our strengths, our familiar traction areas. If we raise the anxiety of a developer too high, they will go technical on us. If we still don’t get it, they will dive another layer deep, and the onion test has begun. How many layers will it take to make the non-technical people in the room start to cry?
The challenge is that the developer is being handed abstract tasks. How do we help the developer understand the tasks so they can answer without peeling through the deep technical layers? Stop believing the myth that developers are not good with people. When we isolate developers from the users, they create and communicate abstractly. Team leads definitely should be connected with the end users, but if there are still issues, consider including developers with end users. This was a solution brought up in the book, Change, by the Heath brothers.
Why is this part of a talk on modernizing developer environments? It is because we need to see the developer’s challenges to see how to equip them to serve us. Great leadership doesn’t just hire developers who rise above challenges. Great leadership hires people, and all people have challenges. People rise above challenges much more often when they are accepted as a mix of strengths and challenges.
To avoid getting lost down that rabbit trail, the focus here is seeing how to overcome the challenges with the developer rather than seeing developers as the challenge. Oh, and developers, we need to avoid highly technical answers even if non-technical answers are not getting traction. This will keep the communication door open.
The Developer’s Technical Challenges
Developers want to produce, create, and see their work winning for others. There is a term called grind. In the technical world, this means things that we do that keep us from doing productive work. Here is a short list of technical areas, so ignore the details if you are not technical. If you ask, you might get one of those onion answers.
- computer configuration
- project environment setup
- shared code management
- project updates, logging, etc.
- deployment
- testing
- meetings
Yes, that last one; we all understand the last one isn’t technical. We understand getting the whole team to the next level is essential.
I am a veteran, and some of what I learned in the service adds light here. Doctors also have technical challenges. As a doctor cares for soldiers or a sports doctor cares for athletes, they need to understand the needs of the individual they are caring for. Another truth is we need to understand the needs of the physician. There is a clear difference between doctors and developers, but the similarities here are the ones that matter. If we don’t take time to understand the concerns they have and, the questions they ask, the needs they present, we ask them to operate purely focused on outcomes.
Times will change, disruption will continue, and your developer is aware of this. It is not that your developer only wants the new shiny toys. In fact, most seasoned developers resist the new shiny toy. Here is another one of the challenges. Nothing tends to change as fast as technology. The developers are on the same team, especially if the culture is good. They are just bringing a different perspective. This brings us to our last section.
Disrupting Modern Development Environments
When we change things, it always has an impact. It is highly beneficial to understand what now exists to make sure our pivots cause less disruption to our business and customers. Especially in technology, change is inevitable. Learning the right time and the right changes is always best when decisions are collaborations.
Getting things set up happens with new team members getting set up, upgrading development systems, and when a system crashes. The grind we talked about above is the excess time a developer spends getting things ready to produce. The grind is the time a developer is blocked from working.
Things have improved with version control and package management systems. With all those improvements, we still feel that grind when we routinely come to parts of our work that are delays to production. Where there are challenges, there are opportunities. Sometimes, one or more of us work on reducing the grind in ways that prove valuable.
Docker is one of those technologies with the potential to reduce the grind. We are not saying this is the only approach or the right approach for your company. It is a real-world, proven illustration. First, it delivered moving code from development to production disruption that changed business drastically.
What follows is the next level of disruption. What we learned is that delivering technology more reliably to production has a similar benefit to the developers. It has the power to reduce grind.
- Develop with a consistent, easily reproducible toolchain on the same operating system you deploy to.
- Quickly swap between different, separate development environments and safely make updates without worrying about impacting your local machine.
- Make it easy for new team members/contributors to get up and running in a consistent development environment.
We see this being done in multiple ways. The future promises that gone are the days when a second or legacy project will compromise the stability of a developer’s system. Well, legacy projects still have risks because they were created before the benefits in the bullet list above.
What used to take hours to deploy to production is done in minutes these days. These same benefits exist for developers. We have skipped several details of that because they get technical, and those will be covered in other articles.
These benefits extend through the entire list above, the list that ends with meetings. Yes, the new solutions that have come out in recent years, when done right, reduce grind and make technology better at accelerating and automating business based on the business model, not based on the joy of new technology. That is the joy of this new technology, what it does for business. It equips the business to be more profitable, not for the sake of profit but because it helps serve the patrons of the business better.
Recent Comments