& Continuous Learning

I attended a No Fluff Just Stuff Symposium a few weeks ago. One of the main emphasis during the weekend was learning new languages that are available on the JVM. While there are a variety of reasons that we need to take time to learn new programming languages, one of the most profound is learning to think about problems differently.

Paradigm Shift

When I entered the development scene I was immersed in Object Oriented programming. As a result, I tend to think of good design in objects. A few years ago I began to learn and apply Groovy. With closures I was able to bleed into the realm of Functional programming. This gave me a small taste of a new paradigm. I thought of new ways to solve problems that I couldn’t see with Java. I can only imagine how much more I could learn if I developed exclusively in a Functional language for several months.

I tend to see two camps when it comes to learning new languages. The first camp thinks that the language that they know is sufficient for solving all programming problems. The second camp runs after the newest hot thing and divorces themselves from their old language. Neither extreme is healthy. We need to see languages as tools. A hammer is not good for solving all problems. Sure you might be able to turn a screw with the claw of a hammer but why would you. We need to understand our problems first and select a language that solves it best.

JVM languages allow us to make this decision at the last responsible moment. We can select a JVM language that seems appropriate and begin coding. If it becomes clear later that this language is not well suited to solve this problem then we can change our mind. The JVM provides a single platform for us to use the best tool for the job. We can even use multiple languages to develop one system. The JVM is an amazing canvas for agility.

Detour

Now I want to take what may seem like a major detour. However I would suggest that this does not stray all that far. We need to extend our effort to become multilingual beyond the JVM. As professionals we would benefit from learning the language of different business areas. Management, Testers, and Business Analysts solve problems in different language paradigms.

Many developers begin to tune out as I mention management. Feelings of frustration begin to take over. We can tolerate BA’s and Testers for the most part but management is just a waste of time. The pain and frustration from the past takes over and we just tune out. We code in secret and try not to disturb the gods of management. We avoid them and hopefully they will leave us alone.

While I’m not here to say that all management is just massively misunderstood and we need to forgive and forget, we do need to learn to communicate. We often contribute to our own misery. We are either silent or we speak in a language that makes no sense. We need to learn their language.

Speaking the Same Language

Before I proceed let me make a very important side note. Not all managers are open to an intelligent and rational discussions. Some have given in to money and power and they just want to be right no matter the cost. While this can be true, I think that there are many managers that can be reasonable. The challenge is not intellectual but one of language.

How do managers think? Well one simple way to find out is to listen to them. What are they focused on? What excites them? What frustrates them? But the most important question is why. Why are they focused on certain things? The question of why delves into the area of motivation. What motivates management? Sure we can go for the easy answer of money, but is that the whole story?

Expanding our Library

Once you start listening I believe we need to move to education. We need to add a few business books to our technical library. Begin to understand the information that managers are focused on. Take time to understand how they get information and how that effects their decisions. And now it’s time for a big leap. How can we provide information from our development effort that can influence management decisions. Now I want to caution you. This will not always work. But if we are not speaking manager-eez then we can not expect to influence their decisions. I see this same challenge in my marriage. My wife doesn’t focus on the same things that I do. Nevertheless, over time we’ve learned to speak each others language. We work to bridge this divide because we “care" about each other. I know I brought out a feeling word. We can try to avoid the “F" word, but if we don’t care enough to take the first step to bridge the technical and management divide who will?

Balancing Act

Once you have a good understanding of how your management team makes decisions, you need to get the right information to them. While every company and manager is different there tend to be some common ingredients in their decision making process. The first ingredient is return on investment (ROI). The second ingredient is generally risk management.

As a developer these tend to make me irritated. ROI appears to be something that can not be accurately measured and risk management just results in more work. However these are things that we deal with in our personal lives all the time. Marriage, 401K, children, cars, investments, homes all require us to consider ROI and risk. After buying three homes and selling two I am painfully aware of ROI and the need for risk assessment. Each purchase has different factors. A starter home needs to be something that I can resell in a few years. However starter homes often require a lot of maintenance and updating. A retirement home needs to be built to last. Similarly, every management decision has specific factors that drive the decision.

In software development the major factors tend to be: time-to-market, timeliness, development cost, maintenance costs, usability, scalability, security and features. The right product at the wrong time results in a useless product. A great 8 track player delivered in 1980 as the cassette tape market was on the rise, would be a waste of money. If you were one of the 70 million customers of Sony’s PlayStation that had their information stolen this year, all the other features became less important. Developing software, or products, is not just a matter of putting the correct components together. Good managers try to balance all the moving parts.

Show me the Facts

So how can we provide valuable information? One vital piece of information is the project burndown. A burndown projects the projected completion date based on the historical velocity and the size of the feature backlog. But marching towards the finish line does not always equate to a valuable product. Regular demos to the customer allows us to calibrate the relevance and usability. Tracking the feedback from these demos helps us measure the value of the current product.

Another factor to measure is the maintainability of a product. As we set a development pace we need to determine if this pace is creating waste. Managers have to weigh the cost of speedy development with the cost of long-term maintenance. But without any data this decision can not be made. Are developers just wasting time trying to make a Rolls-Royce when we just need a Pinto? We need facts not opinions to steer the ship of management. Instead of pretending that I am an expert in this area I am going to recommend that you read two of Neal Ford’s articles on “Evolutionary architecture and emergent design".

• Evolutionary architecture and emergent design: Environmental considerations for design, Part 1
• Evolutionary architecture and emergent design: Emergent design through metrics

While the topic may be a little different from this blog these articles contain amazing insight on gathering, analyzing and visualizing technical debt. Technical debt is that elusive beast that we feed when we, with the best intentions, just try to “get-er done". The fatter this beast gets the harder it is to make changes during the development process and during long-term maintenance. In this case harder means more costly.

Summary

As developers we are focused on language. We use words to create software. We translate business words into code. We are in fact professional interpreters. We use our multilingual skills to translate concepts into working software. But when it comes to bridging the communication divide between software development and management decisions we often give up. We try to use emotion pleas or technical words to effect change but people quickly stop listening.

As professional, multilingual, translators we need to focus our skills on effectively communicating with management. We need to understand their domain and gather valuable and relevant information that can guide their decisions. Instead of avoiding management we need to engage them. We need to gather information that only we poses and translate it into information that makes sense to critical decision makers. We need to become part of the solution instead of contributing to an overwhelming problem.