There have always been echoes through computer science that coding will be a part of education in our future in the same way that written language and mathematics are a part of every industry today. It never truly made sense to me as a developer that everyone should know coding as intimately as they know mathematics. Applications were always part of large codebases and making any change required not only the knowledge of coding in a particular language, but also the domain specific language that each team had dreamed up to architect their program. It seemed that only software engineers really needed to know how to code. All the talk of coding as the new mathematics or language sounded to me like developers self-glorifying the importance of their craft. But now the rise of easily extendable software tools is beginning to show me the future those echoes were dreaming about.

Services have offered the ability for their users to add extensions and plugins for years. These usually came with the overhead of yet another language to learn, difficult environments to set up, new applications to install, and domains that often grew so large entire industries have formed around customizing those services. That era of extensibility never made the case for me that coding was going to be a necessity like math. It still felt like coding was going to be left to a team of developers that were specialized on the subject. Even if a user understood programming concepts, there is only a small chance they would have the time and capacity to learn the specialized pieces necessary to create plugins. It never felt like building extensions to products was accessible to anyone other than software developers.

The internet has made Javascript ubiquitous. It could be argued that our massive consumption of the internet is reason enough to understand the loops and variables that drive it, but most of us know very little of the bits flying around to generate the SaaS products we all use. A lack of understanding of how code works doesn’t hinder the use of SaaS services. Even though we interact with code most hours of the day, there still hasn’t seemed like a good argument for why everyone ought to know what a for loop is.

A conversation with a people success manager at Aha! convinced me that learning code should actually be as commonplace as algebra. We recently launched Aha! Develop with javascript extensions that allow for very powerful customization of the service. At Aha! we strongly believe in dog-fooding our own product and we utilize Aha! for not only our own product management and software development, but also things like applicant tracking for people success. The manager was so excited about the possibilities of extensions that he was contemplating learning javascript to start writing them. Aha! Develop extensions were built to require very little overhead to getting started with extensions. The command line tool builds the project for the user leaving only the functions they need to write to implement the functionality they want to see. If coding had been taught as commonly as how to graph a line, this manager would be able to contribute extensions to the product from a role in people success. There would be no software engineer required to make unique customizations to the tools he was using. This new class of extensions can enable SaaS products in all industries to become customizable by users with very basic understanding of how to code.

Our goal as software engineers should be to embrace a world where all of our users understand code. The tools we build in the future will need to provide users with multiple points of customization. These entry points need to be easily accessible, but also powerful. It is important that future users have very little overhead to accessing the customizations available through code, but also very extensive possibilities once they are building customizations. With the right tools available to customize services, we will hit an inflection point where every user can access direct benefits from the ability to code. The pontification about the value of understanding code can finally be realized.

In every organization I have been a part of, some aspect of the operation has become the role of every member of a group to maintain. This could be the documentation about an API usages, creating a new branch for a release, writing acceptance criteria on tickets, reviewing code for pull requests, and many other tasks. These items are deemed important enough for us to believe in them as an organization, but our implementation usually leaves them incomplete or unmanaged, because they lack ownership.

To ensure that the proper focus is put on important tasks, we must make those tasks the responsibility of an individual. Once we have given the focus of a task to a single individual, they will spend their time making sure that the appropriate parties are performing the task. This does not mean that one person must now complete the task all by themselves, or that one person is accountable for the tasks. Rather, this just means that one person is actually focused on making sure that the task is being completed.

We are not trying to end collaborative efforts by assigning roles and duties to individuals anymore than assigning developers to tickets ends the collaboration in engineering. A developer often finds help in conversation, pairing, white boarding with a colleague, and many other collaborative efforts even so far as taking commits on their code from other developers. Assigning a role does not end this collaboration, it merely defines an interface for completing the work and an owner for that interface.

If there is anything important in your organization, make it the job of an individual. Do this even for tasks that need to be completed by a number of individuals across disciplines. Without an individual owner, everyone’s job becomes no one’s job.

For a couple decades now there has been a story floating around about an experiment with monkeys, bananas, and a cold water spray. The experiment is designed to explain how we often follow the rules created by a team without even being present at the formation of those rules, and without questioning the genesis of those rules. Here is a diagram that explains it (origins of this image are unknown to me, honestly I found it in a stackexchange post, or I would give proper credit):

The image itself even provides a bit of analysis about what we can learn from this fable; I call it a fable because there is no evidence that an experiment ever occured. The lesson is clear, we should continue to question the ways we are told to do things because there may be a better way out there.

But I wonder if that is truly the lesson we should be taking away here. There is also another interesting dynamic taking place in this diagram. The new monkeys do not have to feel the pain of the mistakes the old monkeys have made. If the new monkeys would have climbed the ladder, they would have all been doused with cold water. The problem is not that the monkeys are keeping each other from continuing to climb the ladder when they know it will not be fuitful. The problem is that the monkeys have lost the knowledge of why they do not climb the ladder.

The lesson here is not that we should always question any current behaviors, but rather that we need to document the knowledge we are gaining from our failures and explain why we have arrived at the current process. The monkeys should be sharing the knowledge of the water sprinklers with the new monkeys, not just beating them up when they attempt to climb the ladder. Maybe climbing the ladder will always be a foolish task, but it is important that the new monkeys know why.

It is important because a new monkey may bring in a creative development that can solve the initial problem. If the monkey knows that water is the real issue, and not getting beat up by monkeys, perhaps it can devise a method to stop the water. Maybe this new monkey came from a previous group where they had learned the technology of umbrellas. Perhaps this new monkey could teach all of the other monkeys how to defeat the water and eat the bananas.

The lesson here is not to question those that beat us. The lesson is not for the new monkeys. The lesson here is for the old monkeys. We should not be beating the new monkeys out of the patterns we failed to achieve. We should be explaining to the new monkeys how we failed and perhaps their minds will help us all succeed.

A major theme of agile development is that teams are made of individuals. This concept is at the very core as one of the main phrases from the manifesto:

Individuals and interactions over processes and tools

Teams are made of individuals, and software is developed by humans. We all know that the goals and motivations of humans can vary wildly. Entire industries have formed around assessing the personality traits of teams and helping them to learn how to exploit each other’s strengths and support each other’s weaknesses. But even beyond strengths and weakness, humans communicate differently, solve problems differently, manage their time differently, and most definitely work differently.

Why then do so many companies and agile practitioners seek to standardize the process? The core foundation of agile is rooted in the inability to standardize processes when the individuals that contribute to those process are always different, yet we try to create rules that all teams must adhere to even if they hurt an individual team. These rules limit agility.

Our goal instead should be to provide teams with tools to maintain agility. Those things we thought of as rules before (stand ups, groomings, story points, sprints, WIP limits, etc) should really be presented as tools that can help solve a problem that a team is having with agility.

It is important that we remember the goal is to continue to adjust the process for our ever changing team, not to adjust our team to match a standard process. We should learn every type of software process that we can and remember the things described in those processes as rules are really just tools that can be used in our work in a way that fits our team.

During large changes I often hear the term “the new normal” to describe the settled period after transition has occurred. This term is loaded with the idea that change is some sort of step input that will then allow things to normalize. In reality, change is the only constant and adapting to change is the “normal” we should be seeking.

We are never going to find the perfect process, but we can always find a better process. That is the goal of retrospection in agile development. We are meant to look at our processes continually and find improvements. As we grow we will see changes in our team, our technology, our product, and many other aspects that affect product development. Our process must adapt continually to those changes.

There is no “new normal” because there is no normal in software development. Changes may be large or small, but we can never assume they are done or that our process is complete.

We shouldn’t be searching to normalize and settle down. We should be continuallly looking to improve and constantly driving value in new ways.

The most interesting part of a ouija board session is that results are generated. After the candles have been lit and the chants have been moaned, the ouija board actually creates words. The participants all pull and push in different directions, with none of them feeling in control. This chaos would seem wasteful, yet somehow words begin to emerge from the board. The ouija board is successful in producing results, but it is missing any real value.

When an engineering team does not have clear guidance and a strong focus, it begins to function like a ouija board. The different teams pull and push in different directions, none of the teams feel in control, and the results are random and lacking in any real value.

A roadmap can help to break the cycle of ouija board engineering. It is important that all of the teams and individuals working on a project dont just see the next quarter of work, but understand how value is going to be generated over the next 12-18 months.

The goal is to stop producing scattered work like the words spiraling out of a ouija board, and instead produce incremental work that is building towards common goals and themes. Your ouija board should be writing words that form sentences that tell a story, not creating random work that looks productive.

Many times throughout your life you will find opportunities where the knowledge you gain from one discipline can be applied to another discipline. One of the reasons I try to maintain so many interests is so that I can learn new perspectives that may one day help me in ways I could have never anticipated. When I began training for triathlons, I didn’t realize how much I would be able to utilize the techniques I learned in triathlon in other aspects of my life. However, the negative split is one such technique that I have been able to cross-apply to product development in a very useful way.

When I first began to run long distances, I encountered a lot of burnout. Each lap would be slower than the last and as I reached the end of the run it was all I could do just to keep moving. My energy and enthusiasm was burning away far too quickly.

A split is calculated by taking the time for the current lap and subtracting the the duration of the previous lap. With each lap my splits would become more and more positive. I was running as hard as I could but moving slower and slower with each step. I would sprint through the first miles of a workout only to find myself barely walking the final mile.

I was burning out. It was becoming impossible to estimate my performance over long distance because there was no consistency.

If I was going to finish a race with a decent pace I would need to employee some new techniques. This is when I found the negative split.

I began to focus not on exerting as much energy as I could at all times, but rather on making sure that each lap contained more effort than the previous. I would need to be more reserved and thoughtful at the beginning of my workouts. Instead of pushing my body to its limits I was focused on holding back just enough so that I would have more to give.

Eventually I was able to control the pace of my runs and break myself of sprinting to death. Enforcing the negative split in my workouts had allowed me to find a pace that made sense for long distances.

My past was also full of half-finished projects and just-started ventures. There were so many times when I had rushed with enthusiasm into a new project only to leave so many others in the dust. I would work tirelessly on projects energized with the spark of a new idea. But inevitably my enthusiasm would burn away. Each week I would produce less and less.

I was burning out. It was impossible to estimate completion of a project because there was no pacing or cadence to my work.

If my work was broken down into laps it was clear that my projects were facing the same problems that my runs had faced. I was creating a positive split in my work effort as I threw my full effort into each new project leaving no room for growth.

Incorporating a negative split into my new projects has helped to slow burnout and keep projects alive. For new projects, I try to always take a calculated and slow approach, making sure that I have more effort to apply with each successive iteration.

Being consumed by a new product idea or new project was hurting my productivity. With the negative split I not only finish more projects, but I’ve also been able to really understand what my pace should be. It took me some time to understand the limits of my time and those limits continually change, but pacing and focusing on negative splits will always help me to recalibrate.

These same patterns can be seen across product development organizations. New projects and products can gobble up resources and focus for companies. Teams become frustrated and overworked, older products wither, and flow of work is difficult to predict.

The negative split can be used to help pace product work. By starting with minimal effort, the team can slowly increase with each iteration. This might mean increasing the size of the team over time, increasing the number of tickets completed in each iteration, increasing the funding for a particular project, or slowly ramping up traffic to a service. The goal is to decrease the possibity of burnout and to also maintain a steady pace that allows you to keep all of your products and projects in order.

I plan to utilize this space to share my musings on software development practices and how they can be improved.

I have worked in scrum teams for around a decade and I have always felt there is something more to the process, or perhaps something less.

This space will be an exploration and a retrospective into the agile practice I have seen through the years and the practices I would like to see in the future.

I hope you enjoy, please come back soon for updates.