In mathematics, a function has a maxima and minima. This means there are points at which the value of the function is at its highest or lowest. The word “maxima” is the plural form on maximum. It can be true of some given function that there is more than one maximum. The same is true of minima.
Like a mathematical function, the productivity and output of a software development team has maxima and minima as the inputs to the system change. These inputs can include the size of the team, the experience its members, the tools in use, and the process used to execute on delivery of the product.
With different ways of approaching the problems a team faces, the impact and success of the team will vary. Some practices, platforms, and languages will fit the team, individuals, and the problem better than others.
Math Class
Maxima and minima are the points in a function that, when represented graphically, are the peaks and valleys on a curve.
These points of interest are where a function has its greatest and least values, at least in a region bounded by the neighborhood of the given points.
Local maxima are points of maximum function output within a bounded area. Global maxima are points of maximum function output for the entire domain of the function. There can only be more than one global maximum for a function if there are multiple points at which the function has equal output and that output is the greatest for the function over its entire domain (for a constant function, every point is a global maximum).
Any maximum with a value less than the global maximum is merely a local maximum. It is a point of the largest output value in a range of input values. It is a peak on the curve representing the value of the function.
It’s a bit like the old proverb of being a big fish in a small pond. A local maximum is the best you can do in a confined area, but there may be bigger and higher peaks elsewhere.
Software Creator Productivity As a Function
Consider now, the value delivered by a software team. There will be some function that describes the output of the team as a function of the many inputs that make up the composition of a team. Among the inputs are the size, talent, experience, leadership, expertise, dedication, and camaraderie of the team. Other important inputs include the platform(s), language(s), and tools used by the team.
For the sake of simplicity, we can imagine holding all other things constant and focus on something like the way we approach problems with the constructs provided by a given language. Productivity and delivery can be thought of as a quantities (though hard to measure) that are functions of the mindset and approach used (especially as facilitated by the how the language enables ways of thinking regarding problems).
Picture, if you will, a plot of a function with peaks and valleys. It’s an irregular shape representing, on the horizontal axis, your programming approach (with discrete locations for purely dogmatic adherence to given approaches and a continuum of hybrids in between). On the vertical axis we have, as our dependent variable, ability to execute and deliver.
I acknowledge that this graph will have different characteristics and values for tackling different types of problems, but I want to keep this simple and ignore that for this argument to avoid getting distracted from the central point.
This graph will show many points of local maximum and minimum throughout the domain of different ways of tackling problems. Some of the maxima will be higher than others.
In deciding how we deliver software, learning from the examples of others, and experimenting over the course of a career, we are traversing this curve. With proper feedback loops in place, we can often see that we are climbing up a slope to increased productivity or descending to lesser delivered value.
One emphasis of the Agile Manifesto is about reflecting on what is working and what is not. It is about using feedback from delivery machine to correct course and get better over time.
There is a hazard, though, in this approach. Knowing that you are climbing a hill is good, but how do you know you’re climbing the right hill? How do you know you aren’t missing a mountain? It may be that you have, or are about to, arrive at a peak. Yet, there may a higher peak you could approach.
PragDave Delivers Perspective
I spoke with Dave Thomas during an episode of my podcast, Developer On Fire. Dave is an exceptional developer and and author, publisher, and extremely impressive person. He is best known, along with his partner in programming, writing, and publishing, Andy Hunt, as the authors of the legendary software bible, The Pragmatic Programmer.
Dave has the wisdom of decades of disciplined practice and experimentation with languages and practices. When I asked about the similarity of his feelings about Elixir now to the revolution he catalyzed with Ruby many years ago, he put emphasis on the excitement of something that delivers on new ways of thinking. The reasons for this are surprising and brilliant.
This line of conversation started at the 34:55 mark in the show.
“I’m finding that Elixir is opening my mind in the same way Ruby opened my mind when I first started using it and to me that’s the pleasurable experience. I like learning new things. I like putting things together in different ways. As you learn something you make connections between all these various other things you already knew and that’s where the synergy comes; that’s where the a-ha moments come. With Elixir, they are coming faster because, to me, it’s new and a lot of the techniques they are talking about are new.“
He continued to share why the new ways of thinking are so valuable and move us toward something better. Beyond the excitement and fun of working with something different, there’s a bigger reason to expand your scope of expertise in ways to approach problems.
“Part of it is the bright shiny new thing, but also part of it is this underlying feeling that we’re doing it wrong right now and I don’t know what right means. It’s kind of an exploration to try and find ways that are better than the way we’re doing it simply because it bugs me that we’re doing it wrong now.”
Dave finds joy in recognizing that what he is doing is suboptimal (I prefer saying suboptimal to “doing it wrong” because what we are doing may be pretty good and calling what someone does wrong can be divisive – the point is that we can do better). This is a unique way of looking at the situation. It is easy to view a recognition that something is not as good as it could be as a source of frustration.
Dave Thomas sees is as an opportunity to advance the state of the practice of software development.
He recognizes these chasms between where we are and where we could be as opportunities to improve by finding ways of moving from a place where progress is flat to find a new slope to climb.
Rather than trying merely to solve the problem in the moment, he wants to make it easier to solve problems in the future.
He emphasized escaping the local maximum to move into finding another maximum higher than the one in which you currently find yourself.
What a great way of looking at things.
Identifying a Local Maximum
When things are going really well in a project, it can be difficult for team members to recognize that it can be better. A local maximum is usually a point where things have gotten as good as they can get with a current paradigm.
While doing the best you can in your current form is not a disaster, knowing that you can do better should be a driver to trying to find better ways of operating.
Knowing that you are doing well but not improving is often a sign that you are in a maximum. It is impossible to ever know if that place is really the global maximum, or if there is some place that is still better. It’s safe to assume that as much as we can try to approach ideal practice, we’ll never get there. It’s also safe to assume there’s always room for improvement.
Given that you can improve, you’re in a local maximum. You probably have an opportunity to get better.
You want to avoid being like Admiral Ackbar in the Star Wars saga, who recognized the assault on the fearsome Imperial battle station amounted to falling into a trap only after the Rebel forces were fully committed and there was no contingency.
Escaping the Trap
If you find that things are not improving in your workplace in terms of your process for delivering, it’s probably a good time to try something different.
Even if you don’t identify a local maximum and a need to change to grow, you can always try new things in case you happen upon something that improves everything.
Here are some examples of ideas of things you can try to move out of a local maximum and change the way your brain approaches problems:
- Experiment with different types of technology
- If it’s not something you’re doing already, give pair programming a try. While you’re at it, dig into the whole of the ideas offered in Kent Beck’s classic Extreme Programming.
- Take pair programming to the extreme – try mob programming
- Spike a feature that hasn’t been requested to decide if it might provide value (and be clear that it’s an experiment, not a delivery, with an appropriate time-box for the experiment)
- Try Behavior-Driven Development (BDD) with your team (BDD is not just a choice of a tool, as it is often portrayed, but a way of operating with a team and incorporating technical and non-technical team members.) For a good resource on applying this to a team, try Gojko Adzic’s Bridging the Communication Gap. Though he uses the term Agile Acceptance Testing more than BDD, the ideas are the same.
- Take a different approach to testing – if you practice Test-Driven Development (TDD) dogmatically, try relaxing your approach – if you don’t TDD, give it a chance – do more/less testing via your user interface and see how it works out
- Play with a different language – use a functional language if you have only used object oriented languages before and vice versa
- Use a development machine running a different operating system and learn how to operate that system with the keyboard
- Try using different types of data stores than use typically use
Even if what you implement is never folded into your application and doesn’t get used by anyone, you’ve exposed yourself to something new and expanded your thinking. Finding different approaches makes you more valuable and better able to cope with different problem. In addition, you just might find another, higher productivity/quality peak to scale.
Keep Talking About It
I invite you to continue this conversation. Please comment with your ideas about identifying that you are in a local maximum with the potential to find one even higher. Please also add your thoughts on how to execute making that move and finding newer and better ways of operating.