The Quiet Crisis unfolding in Software Development

About Me

I’ve been working in software development for twenty-eight years. My current position is Senior Development Director at a software consulting company in Austin, Texas, a position I’ve held for just over six years.

My progression was originally technical in nature — I started out as an Associate Programmer Analyst fresh out of college. Back in those days one of my favorite hobbies was making fun of the stupidity of management. Only much later did I discover I had an aptitude for management — and actually enjoyed it.

The universe employs a cruel kind of karma.

In my current position as Senior Development Director there are six Development Managers that report to me. There are just under fifty software developers in my organization. We have enviably low employee turnover and very high customer satisfaction.

Over the years I’ve given my direct reports and their direct reports the same insights I’m going to share with you now. These insights are hard-won wisdom rather than something I intuitively knew or read about. That is to say, I learned the hard way.

The reason I’m sharing this is because over the last ten to fifteen years I’ve noticed a quiet crisis unfolding in software development leading to low quality applications, unhappy employees and unhappy users. Silver bullet solutions keep creeping into our awareness (Scrum, anyone?) and predictably keep letting us down.

This is almost entirely the fault poor management — or perhaps it should be called fad management. In the past I was to blame as much as anyone until I discovered and refined a basic set of practices that for the most part cause everything else to fall into place — at least in my experience. No promises. Here we go.

Be Wary of High Performers

Undoubtedly you’ve identified some of the developers on your team as high performers. These are the developers that tend to get work done quickly. Managers often choose and prefer these developers for projects in order to increase the odds of meeting aggressive — and frequently artificial — deadlines.

Actual high performers are rare — very rare. You probably don’t have one on your team. You might think you do but you’re almost certainly wrong.

Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. Examples of shortcuts are not taking the time to design and architect things well at all levels (low to high — think objects and object hierarchies, database schema changes, etc.), failing to test adequately, and crafting code that is hard to read, maintain and extend.

These kinds of high performers are actually low performers when when TCO is factored in. Unless you’re a startup where time to market is the highest priority, keep these kinds of developers under close scrutiny with extensive design and code reviews.

If design and code reviews aren’t highly interactive with lots of questions and recommendations, your employees aren’t taking them seriously or they’re too shy to speak up. Very often one or two developers are interested in them but without obvious interest and input from the rest of the team even interested developers will tend to severely curtail their questions and recommendations.

With proper supervision and guidance in the long run so-called high performers will become better and happier developers and the overall productivity of your team will accelerate and improve: win-win.

Encourage Continual Product Improvement

Despite your best efforts technical debt will accrue: features are grafted into the application with ugly results, high priority bugs are patched in a quick and dirty fashion, management has unrealistic deadlines, requirements change — we’ve all been there.

Encourage developers to improve the application while working on their projects. Examples of improvements are creating reusable objects out of copypasta code and breaking up large objects that are difficult to maintain into smaller objects that individually are easier to reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. With the benefit of hindsight update the user interface to improve user experience — sometimes even just changing a word or two makes a big difference.

Developers that become accustomed to doing continual improvement tend to be happier developers because continual improvement gives them autonomy and a strong sense of making valuable contributions on their own terms. Don’t underestimate the morale boost.

When continual improvement is part of the DNA of your team you’ll be amazed with the results, but give those results some time to become apparent — it won’t happen overnight. It also means management will need to recognize that things will take more time since developers will be working on their primary project while simultaneously making incremental improvements.

Continual improvement isn’t a stand alone project. If you make it a stand alone project you’ll eventually find a reason to abandon it entirely because it’s impacting deadlines. It should be something developers are tasked to do all the time during their normal development activities. This is not unlike the power of compound interest. Continual improvement will eventually snowball into astonishing results.

Encourage Code Ownership

It’s no surprise that management likes to reduce risk by treating developers as interchangeable widgets. It usually takes the form of all developers being expected to be familiar with all areas of the code. That minimizes the pain when any individual developer leaves the team or the company.

This is false economy. Your employees like working for you — right? — which means turnover should be low. Don’t optimize for developers leaving which should be the uncommon scenario. For best results optimize for the common scenario.

Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.

It also helps you identify developers that need extra attention. Some developers produce more bugs just as some carpenters produce inferior kitchen cabinets. As an example if a developer is given primary ownership of the user interface and an unusually high number of bugs are found there it will become immediately apparent where you — as a manager — need to pay extra attention and possibly take action.

Recognize Leaders

You will undoubtedly recognize that some of your developers are more likely than others to be involved in whiteboard discussions, more likely than others to have team members at their work area asking for help or advice, and more likely than others to be invited to design meetings even when they won’t be the developer working on that project.

These developers are your natural leaders. His or her co-workers have already done the hard work of identifying your natural leaders for you. These leaders should be recognized as such and require special consideration.

First be aware that being both a software developer and a leader is time consuming. Software development requires concentration — concentration which is easily broken by one quick question or ten minutes helping at the whiteboard. Getting back into the zone takes time. Expect your leaders to take more time to complete their projects — after all, they’re doing two jobs.

These leaders should also be publicly recognized as such. Promote them to the job they’re already doing. This formalization makes it easier for them to assist other developers without hard feelings — it’s now part of their official job description! — and provides them with recognition which increases morale. Without that official recognition, providing assistance can often feel like little more than an unwelcome burden. Don’t let that happen to your employees.

Most companies have large overlaps in compensation in positions such as Senior Software Developer and Lead Software Developer so there’s very little financial motivation to deny these promotions. Don’t make your (often shy) natural leaders ask for a promotion — just do it. The icing on the cake for you — as their manager — is the loyalty you’ll receive in return.

Watch Out for Misleading Metrics

Do you keep a count of the number of work items completed per employee? Is that count easily available for all software developers to view? Even worse: does upper management have access to that count? Stop doing that right away.

Software developers aren’t stupid and some of them will quickly learn how to game the system if counterproductive incentives are visible. Completed work item counts are an extremely counterproductive incentive and the game quickly becomes all about having the highest completed work item count.

If completed work item counts are part of your daily or weekly staff meetings some of those software developers will learn to tackle the easy items to inflate their count. Software developers that dig into the more difficult problems that take more time will consciously or unconsciously experience a drop in morale which is bad for the team and bad for productivity.

Even worse is when bug fixes are included in completed work item counts when those bugs are fixed by the software developers that caused them in the first place. For example consider a project that developer #1 is likely to complete in ten days with a low or nonexistent bug count vs. developer #2 who is likely to complete it in five days but the feature ends up with four bugs eventually being discovered, each of which take two days to patch. Not to mention the extra support costs and negative customer experience that will result from those bugs.

In this scenario developer #1 only completed one work item in ten days and developer #2 completed five work items in thirteen days. Which developer is more productive? Your own completed work item metrics are probably lying to you. Don’t trust them and absolutely don’t publicize them.

Limit Interruptions

Some employees aren’t aware of the impact they have on other team members and interrupt them frequently with one quick question or worse. Encourage your team to prefer communication in roughly the following order so that interruptions are minimized: e-mail, chat room (if your team isn’t using a chat room yet, they should be), instant message, phone call/dropping by in person.

In addition one of the fundamental positions all managers should play whether they realize it or not is defense. Members of outside groups should almost always talk to you — the manager — first, at which point you can determine who on your team to include and when to include them.

These recommendations for limiting interruptions are rather softer rules than the others because a careful balance must be struck between appearing uncooperative and limiting employee distractions.

Prefer Private Workspaces

We’ve all seen pictures of open office floor plans in which software developers are crammed in and a majority of them are wearing headphones in a vain attempt to achieve some kind of concentration.

Despite there not being a single shred of scientific evidence in favor of open office workspaces being a good idea and overwhelming evidence in favor of them being counterproductive for most software developers, this unfortunate fad is currently widespread. Software developers need private workspaces to ply their trade. Audible and visual distractions should be minimized which means at a minimum each developer should have a cubicle with high cube walls and a small entrance — but big enough to meet important safety regulations of course.

In the unlikely event a project arises in which close collaboration is required most offices have plenty of meeting rooms that can be temporarily repurposed as an open office space.

Encourage Experimentation

We’ve all heard of Google’s famous 20% time which made it possible for such breakthroughs as Gmail to germinate and turn into the cornerstone of Google’s highly successful online applications business.

While most companies don’t have the enormous monetary resources necessary to truly implement a 20% policy, experimentation should nonetheless be periodically encouraged and supported. Software developers are not devoid of good ideas and have the in-the-trenches experience to have good instincts about how applications may be improved and extended.

Giving them the autonomy to occasionally perform blue sky research and development can pay unexpectedly high dividends as well as increase morale considerably. It’s also a good way to help managers identify natural leaders who have taken the time to evaluate and consider better solutions for various requirements.

This doesn’t mean software developers who prefer to keep work at work and home at home aren’t worthy contributors — but pay special attention to those software developers who think they might know of a better way to implement something or might have thought of a feature your customers will love.

Let Employees Leave

If an employee approaches you and asks to leave the group for another group graciously allow them to do so. This doesn’t mean you have to let them leave in the middle of crunch time but as a general rule if they want to leave the group something isn’t working out for them and you should let them transfer even if they haven’t been in the group very long — say, less than one year.

Forcing employees to remain in your group can never lead anywhere good. It’ll impact their morale which impacts the morale of the entire group. It’s also likely they’ll become less effective and in extreme circumstances simply leave the company. Any manager that doesn’t allow their employees to leave has completely misunderstood how to produce the best possible balance of happiness and productivity in their employees and is a rookie mistake I’ve seen even experienced managers make far too often.

Never Turn Down Small Requests

Does your employee want a bigger monitor? Buy them one. Do they want a certain keyboard? Buy them one. Do they want to work from home every other Wednesday to accommodate a personal requirement? Let them. Do they want a Mac instead of a PC? Give it to them.

Unless they have a constant stream of requests that never seems to end you should never say no with only one exception: if you believe the entire team will then want the same small request and it really will impact the budget too much.

When compared to their salary and benefits these little requests go a long way toward keeping morale and thus productivity high and they cost peanuts. If you don’t have the budget for these kinds of small requests it’s time to start looking for work at another company because mid- and upper-level management is broken. If you’ve turned down anything small recently go back to your employee and tell them you’ve reconsidered and give them their small request.

Abolish Yearly and Bi-Yearly Performance Reviews

Your employees should never wait six to twelve months to discover what you feel they’ve excelled at and what they need to work on. Communication between managers and employees should be like a river that never stops flowing. Too many companies are still stuck in the past with their harmful and counterproductive periodic performance reviews. Some performance reviews even require peer ratings which is a recipe for employees to secretly engage in ensuring each other good reviews — or employees that don’t like each other blasting each other. In either case the results are less than useful and typically actively harmful.

This manager/employee communication should not take place during artificially forced periodic one-on-one meetings — often done weekly or semi-weekly — which are usually an uncomfortable requirement for both managers and employees when there’s nothing that needs to be discussed. Both managers and employees should feel relatively comfortable approaching each other when communication is deemed necessary. If an employee is extremely uncomfortable initiating communication with their manager or vice-versa it’s indicative of a bigger problem.

You’re Not Better than Your Employees

Software development is a job. Software development management is a job. Just because your employees report to you doesn’t imply you’re somehow smarter or better. A lot of software developers — dare I say most software developers — just plain love being software developers. Don’t you confuse and don’t let your software developers confuse management as career progression — it’s just a different job even if it generally pays a bit more.

One of the worst things you could ever overhear an employee say is that their career is stalled because they haven’t landed a promotion to management. There’s nothing wrong with a lifelong career that keeps your brain engaged in a positive way and software development remains an outstanding career. Developers should want to get into management for only one reason — because that’s what they want to do, not because it’s considered a step up.

Don’t Discount Younger or Older Developers

Younger employees really do have more energy which improves productivity. Older employees really do have more experience and wisdom which improves productivity. Build a team with diversity in age and watch them blossom into something more than the sum of their parts.

All ages have an important role to play and the best developer teams I’ve worked with have invariably had people of all age ranges — from their twenties to those approaching retirement age. They complement each other extremely well. The synergy is hard to explain but easy to see from a management perspective. In other words don’t let age play a role in your hiring process and you and your employees will benefit in the end.

Don’t have Stupid Dress Codes

As a manager it’s likely you don’t have a whole lot of say here but if you do, allow your employees to dress casually. You certainly don’t want them going to work with torn up jeans or in their pajamas, but a nice pair of jeans and any decent shirt with a collar should do just fine.

By now humanity has learned that over-the-top dress codes don’t improve productivity or company success. And certainly the only men left wearing neckties should be bankers or lawyers. Okay, I’m kidding about that last part — a little. Let your employees be comfortable. For some of them that’s jeans and a basic collared shirt and for others it’s business casual. They’re adults and you should let them decide.

Summary

This article is a very long-winded way to help you learn how to care for your software development employees with best results. If you properly care for your employees they will take care of you, leading to better product outcomes and higher career satisfaction for both you and them.

This is mostly a compilation of common sense but I felt it needed to be compiled in one place for all those low level software development managers out there. I wish it had existed my first day as a software development manager.

This was all learned on the job through trial and error and I can’t guarantee it’ll work for every team, but I’ve done my best and look forward to feedback. I’m sure it’s by no means complete, but it should get any software development manager on the track to success.