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.

Building Customer Friendly Teams

How do you develop wonderful user experiences if your development team has contempt for your users?

OK – I admit this may be a bit strong. But bear with me for a minute.

Think about your development team – top to bottom. Do you have folks that refuse to talk to customers? Or folks that insist they know what the customer needs, even though they have never spoken to a customer?

I’ve seen this across every company I’ve worked for, and at all levels. Sometimes it was an engineer who knew that a user “would never do something that way”. Other times it was a development leader who believed it is “Product Management’s job to talk to customers.”

In either case, you, your company, and your customers lose. I’m not going to discuss you all lose – that is better left to a different post. After all, I’m writing this post under the assumption that you want to create a customer friendly team. With that, let me share some guidelines that can help you build a customer friendly development team.

Set the tone
As the leader, you set the tone that the customer is the highest priority. In practice, this means you:

• never disparage your customers (e.g., refer to them as ‘dumb users’, etc.).
• always include customer considerations in product decisions (e.g., this feature will make our users more efficient, happier, etc).
• show respect for your customers in every interaction with them, even if your team members aren’t there.
  

Find opportunities to teach
Bring members of your team with you to visit customers, to observe end users, and to attend conferences. These are excellent environments to role model. I especially find it helpful to debrief team members on why I acted a particular way with a customer.

For example, I may agree to add a certain enhancement on behalf of a customer. I’ll share with my team member the background on why I made the commitment. For example, perhaps the request was already in the queue and will generate goodwill for a very vocal customer, at very little impact to the roadmap. Or perhaps this is a customer who provides tremendous references and has “earned” the right to get small requests periodically.

These interactions serve to teach team members that more goes into product decisions than technical decisions. This is the basis for developing future business leaders. Keep this in mind - most (all?) successful C-level people handle customers exceptionally well. Chances are they learned that skill somewhere along the way. Why not give a future CEO the chance to credit you with their success!

Expect user interaction from your team
I expect every member of my team to interact with users. That expectation drives all team behavior from hiring through annual reviews. Every one of my managers had goals associated with attending user groups or customer visits. That, in turn, set the tone for their direct reports.

As a result, team members look for opportunities to get out with customers. There are even team members who reach out to customers on their own for input during the development process. Not only does the person get great input, the customers who were asked develop greater affinity for your company and “their” product.

The investment you make in creating a customer friendly team pays dividends:

• Increased customer loyalty (Customers tend to give you the benefit of the doubt if they know you and your team care about them and their challenges)
• Better decisions (Who better to know how a feature can work best other than the people who do the job every day?)
• Higher maturity teams (Technology takes place in a context – and the context is the customer environment, not the SDLC)

Now go out and find a customer to meet.

Building Process Scalability into Software

We often associate scalability with system response time. There is another aspect of scalability that is often ignored until too late. Ironically, it is perhaps one of the easiest aspects of scalability to address before any code is written. I'm referring to scalability of the software to support large, complex processes that touch many people.

Here are two examples:

• Adding large numbers of something to your system at one time. For example, users, payments, or products.
• Making administrative changes across many items. For example, changing permissions for many users, adjusting process to many items, or applying payments to many customer accounts.

I've noticed most software appears to be designed for entry of one new user, changing one product, and so on. This works well most of the time. However, two things usually happen:

1. A customer grows so large that updates happen frequently enough to start impacting productivity. For example, posting a customer payment by hand may be reasonable if you get a few payments a day. What happens for a multiple location business with centralized billing and dozens or even hundreds of payments?
2. Periodic bulk changes consume very large amounts of time and effort for a short period of time. New laws and across the board price adjustments are examples of things that may occur only once or twice a year, but have to be done for many, many items in a very short period of time.

Scalability in this context means scalability of process. It may be fine that it takes 30 seconds to increase the price of one product by 5%. But what if I need to increase the price for 10,000 products? You are going to have to provide me an efficient way to do this.

Unlike hunting down slow performing algorithms, you have to apply user experience principles. Identify operations your users perform to large numbers of items. There are three questions that arise from this:

1. Who are your users and what are they trying to accomplish? From here, identify the most critical operations that are performed frequently.
2. What does “perform frequently” mean to them (not you). Something that is performed once daily, but takes 30 minutes may be frequent to your user. This is especially true if it is something that they will likely do more frequently if their business grows.
3. How big is "large numbers"? For some things, 3-5 times may be a large number if each time it take 2-3 minutes. In other cases, it may be hundreds of times, even if each time takes a few seconds.
   

Seconds add up
Saving one person 2 hours per task, when it is performed 10 times per week, is easy to understand. Be careful to not overlook an opportunity to save 30 seconds of a 2 minute operation when 10,000 people perform it 2 times a week. I've used somewhat extreme examples to make a point - not to set a standard. The core point is that saving time from seemingly small operations for many users can provide a very real net benefit to your customer over time. Don't overlook those opportunities, even if the savings seems small initially.

These lessons can be applied very early in the development cycle - well before any code has been written. The observations made through interacting with the users allow you to focus energy on making your customers efficient with your software, even if that means slightly fewer features.

Keep in mind - you are likely to be better off with fewer usable features than a lot of features that are inefficient. And let's not fool ourselves - once a feature is released we seldom go back and improve it proactively. Take the time to build in support for scalable processes along with all the other "ilities."

Hire for attitude

I was chatting with someone the other day (as opposed to chatting with myself - but that is another story...) about the state of talent in our industry. I relayed to him a quote I learned from Michelle Jackman (http://www.mjbizwiz.com/) many years ago: Hire for attitude and train for skills.

Given that I heard this from Michelle in 1988, it is among the most impressionable things I’ve learned in my career. Along the way, I’ve discovered a few things that help me assess a potential team member’s attitude. This is not an exhaustive list, and I welcome your thoughts.

Focus on principles, not tools
The best candidates (and subsequently, hires) have been the ones with whom I’ve had a conversation about software engineering fundamentals and principles. How do they view design? How do they view build management? Does the art and discipline of software development excite them? If none of this matters to them, I don’t care if they know languages and data structures.

You may be asking, “How do you know if they actually have skills, though? These sound like philosophical conversations.” You are correct - they are about philosophy. However, if you dig deeper, you’ll realize the candidate has developed their philosophy through their experience and learning. A candidate can’t talk to me intelligently about multi-branch, concurrent release management unless she has dealt with it in her career. I don’t necessarily care if she has used CVS, Subversion, Jazz, or ClearCase. What I care about is that she experienced the challenges with this and has developed principles about release management that are consistent with (or will add to) mine.

In addition to software engineering principles, a person must love to learn. I ask things like what websites and journals they subscribe to. I ask them what the last couple of books are that they’ve read. Candidates that come up blank are not asked back. If the candidate shows no interest in learning on their own, they aren’t going to be fit on my team.

Focus on customers, not process
I want to know if the candidate wants to be left alone to code or understands that we build software for people. If the candidate shows little to no interest in the customer, they don’t get on my team, regardless of talent.

I had a key senior architect who I wanted to accompany me on a customer visit. This was a key customer, with a team of highly technical staff. My guidance to my architect consisted of something like, “We are visiting customer ABC, to discuss our foo-bar capability. They are going to have several of their technical folks at the meeting. I want you to discuss our architecture with them. Take care; I’m on the road for the next couple of weeks. See you at the customer.”

He prepared customer friendly architecture drawings. He kept me posted on progress and asked my thoughts about the overall level of discussion and breadth of topics. In other words, he demonstrated the attitude that customers are important, and that we need to be prepared when meeting with them. That attitude, by the way, was infused into his designs.

His response was exactly what I expected based on our conversations during the hiring process. My faith in him was not drawn from his technical ability (although it was very high). It was drawn from knowing his attitude about software engineering and customers.

Concluding example

I once was approached by a person who wanted to join my team. He was a developer earlier in his career and then a manager for several years. He realized he was happier as a developer and saw an opening on our team. On the surface, there was no reason to hire him. He hadn’t developed in years and was pretty rusty with his technical skills.

Since this was an internal candidate, I took him to lunch as a courtesy. In the course of the conversation, I was impressed with his work ethic, empathy for the challenges of management, and his strong customer-centric approach to software development. Late in the conversation, I told him flatly that I loved his attitude, but had concerns about his ability to develop after being out of it for many years.

He assured me he would spend his own time re-learning languages and environments. This was one of those “look a person in the eyes and judge whether he is sincere or not” moments. I judged him to be sincere. He went through the rest of the interview process, and we agreed to hire him, strictly on attitude. After all, how often do you get a chance to bring someone with management experience and a customer focus onto your development team?

Results? He became one of our most trusted developers. He won company awards and frequently was asked to personally address issues with top customer accounts. His attitude of self-motivation, customer focus, and results were the keys to his success. Yes – I could have hired a person with a couple years of programming experience that on paper would have “coded circles around him.” But the results would not have come close to what this person delivered in his years working for me.

Think about how you acquire talent. Do you engage candidates in meaning dialogue about learning, customers, and principles of software engineering?