What-if-itis

I've discovered a potentially fatal disease that can severely damage all or some of a software project. Initially it seems benign. You don't notice it at first, since it appears as a helpful set of behaviors: caution, thoughtfulness, building robustness, and many others.

After a while, you notice that your team's ability to decide and produce software has slowly eroded. Before you know it, you have succumb to this disease.

Your team has contracted what-if-itis.

Symptoms
Symptoms include team members introducing scenarios, new technologies, and arguments proposing overly-complex solution to problems that may never occur. Here is an example of how the disease presents.

Someone on the team will (in all sincerity) raise an issue about the application usage. Something like, "What if a customer buys 1,000 different books at once?" Everyone may start out looking around at each other saying, "Wow 1,000 books *would* bog down the shopping cart. We ought to think about pagination, implement some client side caching to avoid server round trips, and..."

Curing Sudden Onsets
Acknowledge the input but gently ask the team, "Is anyone really going to buy 1,000 books?" And if someone did, how frequently would it occur? In other words, yes, this scenario could happen. But is it worth spending precious effort on it?

The easiest and fastest way to rid yourself of a sudden onset of what-if-itis is to get business stakeholders or customers to validate or refute the scenario. Even here you have to be careful. Don't ask if the scenario is possible (it is). Ask:

• How frequently would this scenario occur?
• Under what circumstances?
• What type of user would typically perform this task and towards what goal?

Depending on your relationship with sales, you could also add:

• Would handling this scenario win more sales?
• Would not handling it lose customers?

Once you have answers, you should have a good sense of whether this is worth addressing or not.


Immunizing your team
There are several things you can do to immunize your team:

• Educate
  Educate your team on the domain, the users, and their goals. If the team knows your website is intended to sell books to the general population at a competitive price, then the 1,000 book scenario will be understood immediately as unlikely. Without this knowledge, a team member could legitimately wonder "What if a librarian came along looking to do an annual purchase or to stock a new library?"
• Keep a backlog
  When what-if-itis strikes, "quarantine" it to your project backlog. Your goal is to understand quickly whether the scenario is realistic or not. People often fight for it because they think it will get ignored and cause harm to the product later. Having a backlog assures people that their concern will later be addressed or shown to be outside reasonable system expectations.

The key is to reduce or eliminate the amount of what-if-itis. When it occurs, move quickly to validate it or move it to the backlog. The damage occurs when resources are diverted to researching, designing, and building software for scenarios that may reasonably be considered to be outside normal system usage.

One final consideration. Your market and your customers are the final arbiters of normal system usage. What you may find outside normal system usage may in fact be a very real scenario that your customer faces infrequently, but that you have to handle with elegance. Unless you are highly certain, engage your customers.

Getting Change Done

I am responsible for helping set strategy and direction. When I change current direction, the change may be a little. Or, it may be a lot. The greater the change, the greater potential for angst among the people impacted.

No executive wants to cause her team additional stress. On the other hand, no executive wants to maintain status quo and allow his business to fold. Navigating this tension is difficult. Here are a few things I’ve learned along the way to ease (but not eliminate) this tension.

Start doing, stop talking
Once you know the direction you want to go, start walking. Planning is needed, but not at the expense of learning. You seldom know how things will turn out, so begin to execute and make adjustments. Plan enough to get you started and to share the general direction and goals with key team members. That may mean a few hours or a few weeks – that depends on the scope and magnitude of the strategy to execute. Here are some recommendations:

• Encourage key team members to find the quickest items to start executing, as well as defer everything that doesn’t need to be known immediately.
• Reinforce to them you aren’t looking for perfection and you expect adjustments to be made continually along the way.
• Lay out significant milestones and ask for a plan to achieve them. They own the plan (how); you own the results (what).
  

Stay focused on the storyline, not the sentences
I recently worked with my team to deploy a new (to us) suite of development tools. Do I agree with every configuration and option the team selected? In honesty, I can’t answer the question because I don’t know every configuration and option the team selected. I am pretty sure if I reviewed every choice, there are things I would do differently.

That doesn’t matter.

What matters is that the tools are deployed effectively to increase the efficiency of the development team. In other words, allow the team to determine how the change is implemented. The message to the team is twofold: I trust you to make good enough (not perfect) decisions and I trust you to make course corrections as needed.

Acknowledge the team’s discomfort
It is normal (and part of being human) to feel anxiety and excitement simultaneously during changes of direction. Knowing that feeling frustrated and anxious is normal won’t stop the pain, but it is enough for most people to help them get through the change.

• Be there to help them work through the initial angst. When the first set of people emerge “on the other side”, enlist them to help bring others across.
• Remain firm that the direction is not negotiable (keep in mind if you really blew it, then of course redirect – for now assume your direction is appropriate). Some people may continue to resist, but strangely, knowing that you are committed is reassuring to them.

In the end, How much is too hard to push? If you are moving people out of their comfort zone, then aren’t you making them uncomfortable? And is that bad?

These questions have been buzzing around in my head for years. I’m not sure there is a right answer. More than likely, there isn’t.

Coding a Mile in Someone Else's Market

It is easy to look at legacy software systems written by others and criticize the design and implementation. I'm not proud to admit it, but I've done this myself through the years. Time and experience have allowed me to appreciate the difficulties inherent in building software in an ever changing world.

Consider 10 years ago.

What technology were you using? We had just come out of the Y2K scare, the web was still about "eyeballs", and Silverlight and the iPhone were years away. You had Java as your main option for writing web applications (which I'm not sure were called web applications).

Were the applications written then bad because they aren't using Entity Frameworks and Service Composition? Of course not. Smart people were using the latest and greatest patterns (Gang of Four, anyone?) and practices (eXtreme Programming).

It is interesting to approach "legacy" applications from a historical perspective. What was the state of technology when they were written? What was the state of the market they were serving? How has that market changed over time?

You may find it interesting that these are the same questions you ought to be asking about technology, your application, and your market today.

The bottom line is this: It's hard to write software. Period. You have to handle today's problem. You have to anticipate what the market may need in the future. And more often than not, you are tied to customers who are using your current product.

Instead of re-writing an application, consider extending it by adopting newer technologies for new features. You may have to write some adapter code, but that may be easier than re-writing a bunch of functionality that works fine today. For example, I managed a project that integrated C# WinForms into a Delphi application. We extended integration and other processing by surrounding the core Delphi engine with .NET web services. We saved a lot of time not re-writing and regressing testing code that worked.

I'm not saying don't rewrite applications. What I am saying is that you should make sure you are doing it for sound business reasons, not just to move to newer technology for the sake of new technology.

Keep this in mind: That hot Silverlight application you are writing today will be someone else's legacy application in five years.

Small Comments in Passing

A combination of personal and professional opportunities recently led me to say a very difficult good-bye to a group of individuals I'd grown immensely fond of. This is a team I had, to a large degree, built over more than six years.

I was humbled by the outpouring of good wishes, friendship, and respect shown to me in my final weeks with the team. I will take with me many, many fond memories of the accomplishments these folks achieved. I will be rooting for them from a distance to continue their path of excellence.

We all read and are told about the power of words to lift or to destroy. For several weeks, I received evidence of the truth of this belief.

Team members came by to say good-bye or retell certain events that occurred years ago. Many began with something like "I remember when you did..." or "The time you asked me (or said to me)...".

In many cases, I had only a fleeting memory of the conversation or action. However, something tangible remained in the mind of the person and affected them as a professional and as a person.

It was a humbling reminder that as a senior leader, my words and actions have impact, regardless of how small they seem to me. Your every action and every word can resonate deeply inside the other person. That is an awesome responsibility --- and an equally awesome gift.

I can't pretend to prescribe how to do this. Here are a few things for you to consider, though.

• When you praise someone - mean it. Look them in the eye and tell them specifically why you are proud of them. Give them examples of what they did or said that is worthy of praise. If you aren't genuinely excited and proud of the person, then stay quiet until you are.
• If you have to provide constructive feedback, do it because you believe in them and you know they can do better. Let them know that you expect more from them because you see more in them than perhaps they see in themselves.
• Challenge them to excel not as a way to meet your goals, but as a way to help them grow. Along the way, your goals are going to not only be met, but in most cases be exceeded.

Don't be afraid to care about people on your team. After all, if you don't care about them, why should they care about you or your goals.

Should You Be The Smartest?

Should you, the leader (think manager, director, VP, etc.), be the best technically on your team?

I struggled with this early in my management career. When I managed teams with excellent developers, I felt a need to show them I could get down and dirty into the code. Periodically, I'd make minor changes just to show them I "still had it."

However, technology changes.

Fast.

The only way I could remain competent in technology was at the expense of my manager role. So here I was, facing a dilemma: To manage technical folks, I had to remain technically at the top. To remain technically at the top, I couldn't spend time managing.

So I did what we used to do when we coded ourselves into a circular loop.

I hit control-C and stopped my internal “programming”. I gradually developed new internal programming.

My management value isn’t determined by being the smartest technically on the team. It is based on recruiting and retaining people technically superior to me. More than that, it is developing each of them to grow in their professional (and yes, personal) lives. This recognition changed my relationship with my teams. Most importantly, it freed me from having to prove my technical skills every day.

Instead, I could focus on learning the business in order to help my team make better technical choices. That’s right - in order to get the most out of a technical team, I had to transform myself into a business leader.

You may be saying to yourself (and the many friends who are certainly huddled around your monitor as you read this), “You have to be technical to manage technical teams. That is the only way they respect you.”

I would agree – to an extent. I’m not suggesting that you ignore technology. It is a matter of focus. Instead of spending days writing code, consider the value of time spent learning your business and what your customers are attempting to achieve. You then have an opportunity to return to the technical discussion with a perspective that your team members may not have (as a complement to this, see my post on building customer facing teams).

Keep in mind that many successful coaches were great players. But when their teams won the championship, they were on the sidelines, not the field.

History: Its there for a reason

I recently had discussions with several senior engineers about “modern” software architectures. The conversation turned to service-oriented architecture. While discussing the merits of SOA principles, I was struck by their consistency with principles developed 30 years ago or more. For example, fundamentals such as information hiding, modularity, and coupling. These are time-tested principles that have been the foundation of major evolutions in software architecture since the 1970’s (and perhaps earlier).

Don’t get me wrong – I’m not suggesting that SOA is merely a new name for old concepts. The SOA discussion was merely a trigger for me to consider how we, as practitioners of our discipline, learn from and incorporate lessons from our past. My observations have led me to believe few development folks spend much time seeking and learning from the past. For example, how many members of your team have heard of Fred Brooks, Jerry Weinberg, Tom DeMarco, Dave Parnas, Barry Boehm, Watts Humphreys, and many others who paved the trail for large system software development and managing teams? Of those that have heard of these people, how many can articulate the key concepts and contributions these folks have brought?

Let me fast forward to my point, or more accurately, my question to you. What are you doing to know the history of software development, and what are you doing to encourage your team members to do the same?

You may ask why I seem concerned with lessons that are in some cases 35+ years old. I would tell you that the variety and depth of reading/learning I’ve done has served me well.

New technology doesn’t appear as “new”. Process innovation looks more like a natural evolution of what I know, versus, well – innovation. I view emerging technology and practices with a critical eye of “how is this like what I know” and “to what degree does it differ”, as opposed to “wow – I have to learn a whole new (insert your favorite thing that will be obsolete in 5-10 years).”

By learning about software engineering history, I have at my fingertips some of the best and worst methods that have been learned in the trenches. That gives me a much broader experience base than what I would have if I limited myself to only what I’ve seen firsthand. This in turn, increases the set of responses available to me when faced with “new.”

So next time you are looking for a new book, consider an “oldie-but-goodie”. You might just find that someone has grappled with very similar problems years ago that you are facing today.