My ADTRAN

ADTRAN

ADTRAN
TECHNOLOGY BLOG


Thoughts on code development, access technologies, and telecommunication networks from developers within ADTRAN’s R&D organization.

ARCHIVED BLOG POSTS

ADTRAN

ADTRAN
TECHNOLOGY BLOG


Thoughts on code development, access technologies, and telecommunication networks from developers within ADTRAN’s R&D organization.

ARCHIVED BLOG POSTS




ADTRAN

ADTRAN
TECHNOLOGY BLOG

Thoughts on code development, access technologies, and telecommunication networks from developers within ADTRAN’s R&D organization.

ARCHIVED BLOG POSTS

Written by: Tom Guevin
Published: 25 Jan 2017

To design and develop software that fits into modern products and pipelines, development areas at ADTRAN are a buzz of activity. Engineers use a suite of hard and soft skills to collaborate on software. This involves verbal communication, white board design, collaborative and individual coding, troubleshooting and organization. Activities require group and individual work, usually planned out at the daily group stand-up:



While not surgery, writing software is delicate work. It requires concentration, focus, and attention to detail. With the rapid adoption and realized benefits of Agile development, collaborative team environments have become the standard. The Agile team develops shared understanding and acceptance criteria, story point estimates and test cases and delivers working code. This requires both intra and inter-team work. Therefore a critical question that organizations must answer is how to harness the collaborative benefits of Agile, while also enabling developers the space to focus on the detailed work.

As highlighted in previous blog posts, ADTRAN is a strong Agile shop. As customer requirements shift, priorities can shift, which can cause ripple effects across the different types of teams that own different stakes in the product. When possible, team members are co-located in team rooms, to allow for collaborative communication and development.

As teams are connected to both remote and local teams, other business groups and a “bot based" build pipeline, there can be noise. Often, emails fly in, Skype for Business and HipChat messages pop-up, the continuous integration pipeline (Git, Jenkins, ROBOT) spits out notifications and a confluence of information is being updated on the collaboration wiki. Training, demos and design meetings can add to the commotion. In this environment, how does a developer concentrate and stay highly productive?



In the movie The Social Network, a scene portrays a raucous party at a Facebook office, where a “coder” with a pair of headphones is zoned in and continues to do deep work. While the example is hyperbolic, it illustrates one way for a developer to temporarily disconnect with music (or even noise cancellation for those who believe music is a distraction when coding). But there is always more work and attention required than we have resources, and interruptions--whether from another developer, a broken build, a code-review in need of attention, a failed test case, or a customer issue--need to be prioritized.

Product owners negotiate with the stakeholders to detail key priorities that add customer value. Plan changes are discouraged, but do happen. Teams use velocity to quantify the average buffers needed to allow them to service outside requests and handle day to day background priorities. This empowers teams to collaborate, without falling behind on priorities. Some teams have higher buffers than others, for example a system or integration team may have a larger buffer than a dedicated application or data team.

All that considered, how should a developer focus to do detailed work and write code? In his book, Deep Work, author Cal Newport (http://calnewport.com/) describes a regiment to eliminate distractions with techniques like not having a direct email address, disconnecting from social media, limiting office hours and even not teaching courses during certain times of the year. He also tries to delegate work, such that at least half his time is spent on work that only he can perform. And he uses the Pomodoro Technique to break up and track development time windows and priorities. While some of these techniques work for a college professor/computer researcher, it is harder in a customer-focused large team-based organization.

Teams at ADTRAN have used several common techniques. One is the morning/afternoon power-hour, where engineers will block off calendar time for focused work. Another is appointing dedicated team members to handle escalations (be it human or machine-originated) on certain days or during certain iterations. We tune our notification tools to be opt-in, where people can tune them out safely and accomplish work and then catch up on the feeds later. In this case, a critical escalation can still gain voice with certain techniques (like being @ messaged in a room, or getting an in-person request). Many of these techniques are commonly used by other companies. So what makes ADTRAN unique?

Similar to college professors, engineers publish and post "office hours," times in which the engineer is specifically available (on-line and in-person) for help, questions and discussion, on a first-come, first-serve basis. This allows the engineer to be reliably accessible, which is appreciated especially by those in remote offices. It also allows the engineer to focus on detailed work outside of office hours, knowing that others can utilize the office hours for the key questions. It is reasonable to push back on any non-emergency request outside of office hours. The usual pattern is as follows: an engineer announces office hours and participation is brisk; later when the engineer is asked a question, etiquette directs the questioner to office hours; the next office hours are more active; the pattern repeats.



To visually convey the state of an engineer at work, we use visual indicators. An engineer in a team/public area without headphones is open for discussions, interruptions, etc. They may be developing, but are not in a zone or crunch situation. When that same engineer puts on headphones in the team/public area, it means he or she is trying to zone in, but doesn't mind being interrupted for an important question/discussion. Finally we have a separate dedicated "down-time" area, which means no interruptions. Some engineers who don't use headphones have adopted different visual indicators, like using action figures or Legos stacked up in a certain way to convey busyness. And some even go as far as to use motion activated desk sensors to respond with flashing lights. Here's an example of a shared quiet room at ADTRAN, note the glass, so others can see you are focused and not to be disturbed:



Other blogs describe other non-verbal techniques to convey busyness - one interesting one is here

In previous ADTRAN blogs, we have discussed the key building blocks of our architecture, specifically microservices, test-driven development, and continuous integration. Delivering software in Agile increments allows us to break the work down into small chunks that can be developed and tested in short order. Even small free chunks of 30 to 60 minutes allow for writing unit and behavior tests, or implementing (or refactoring) the production code. Most engineers post at least one Pull Request a day, scoped down to a specific microservice. To this degree, being Agile allows engineers to be highly productive in advancing the features and software, even if some are not coding during large continuous blocks of time.

Productivity is a key metric that everyone is looking to improve. Collaboration makes us more productive, but software also requires individual detailed work. Finding a good balance between the two can increase productivity, and by making it fun (as we have at ADTRAN), it can be professionally and personally rewarding.

Archived Blog Posts