In spite of excellent productivity advances in software development tools, I believe that developers are working harder to get less done. It would be interesting to see some hard statistics on productivity (if you know of any, please let me know). When I searched for information, I mostly found advertising for tools that help improve your productivity and articles on how difficult programmer productivity is to measure!
Intended AudienceThis article provides suggestions on how to improve the productivity of your development and support staff. Although the suggestions are oriented toward software development, many of them transcend that discipline. The intended audience is senior software developers, project managers, and development managers. |
Having worked as both a developer and manager in Corporate America, I’ve had a chance to see problems related to productivity up close. I’ve also been able to contrast what I saw in the corporate environment with my own experiences working from home as an independent contractor. The productivity disparity between the two environments is alarming.
One day a year ago or so, I sat down and analyzed the issue. My wife tells me, with a mixture of affection and exasperation, that I spend a lot of time analyzing things. After a few hours of thinking through the things I’ve seen slow down development projects, I summarized my findings and formulated the following recommendations for improvement, more or less in the order of their application:
- Eliminate distractions
- Simplify and optimize
- Plan for change and reuse
- Document rationale and complexity
- Maintain production integrity
- Fix defects
Since that time a year ago, I’ve had many opportunities to test my theories, and I haven’t seen anything that has changed my mind. I recently dusted off the little sign I made that has these reminders and decided to expand upon them and share them. This article is the result of that decision.
My approach to analyzing and improving productivity is a little unusual from the standpoint that it doesn’t present scientific measurement procedures or detailed process analysis. I’ve found that social and political influences have a profound impact on whether or not you have a well-defined process to analyze in the first place. The recommendations presented here are more oriented toward rethinking IT departmental policies and practices.
Eliminate Distractions
This point covers a lot of ground, and it is by far the most important productivity tip of the bunch. If you can’t eliminate distractions, all of the rest of the tips won’t do you much good because you will never be able to implement them effectively.
With few exceptions, the best software developers are those who are able to concentrate for an extended period of time. Software design, like any "engineering" effort, is complex. It requires the simultaneous consideration of many factors. For example, it often takes you 10 or 15 minutes to "get back into the groove" after a significant interruption that takes your mind off of what you were doing.
I’ve watched entire development teams stumble through a day getting little accomplished because they are constantly side-tracked by meetings, support issues, hallway conversations, phone calls, and instant messaging. I’m not saying that some of these distractions aren’t worthwhile, but they do need to be managed.
Here are a few suggestions on managing distractions:
- Pick the part of the day you are most productive, and block out a chunk of "work time" on your calendar. Schedule at least two hours of work time per day and you’ll be amazed at how much more you get done in a week.
- Whenever possible, schedule meetings back-to-back instead of leaving useless half-hour holes between them.
- Avoid going to meetings that don’t require your participation. Just wait for the memo.
- Learn to ignore all those fancy gadgets. Unless you are on call and must react to emergencies, ignore your phone, email, and IM, at least during your scheduled work time. I believe that Blackberry devices and IM are responsible for more lost productivity that any other technological "advance" in recent history.
- Isolate yourself as much as possible. Corporate America is in love with Steelcase. That means you are probably sitting in a small cube within whispering distance of several other people. One idiot on his speaker phone is going to destroy every last shred of concentration you have going. If you can’t escape with your laptop to a quieter location during your chosen work time, then invest in some comfortable headphones and use them.
One of the problems with constantly operating in a distracting environment is that it becomes harder and harder for you to focus when the time comes for you to do so. Distraction management is something you must practice all the time, to one degree or another, if you hope to ever get anything accomplished.
Simplify and Optimize
I lump simplification and optimization together because I’ve often found that the best way to optimize a process is to simplify it, but of course that isn’t always the case. So, how does this recommendation relate to productivity, you ask?
Well, take a look at the opposite end of the spectrum here: Complexity and inefficiency are the enemies of productivity. The more complex the process, the harder it is to support, troubleshoot, and modify.
Processes don’t necessarily start off being complex. They often become that way over months or years as enhancements are patched onto them. Eventually, the process becomes a Frankenstein of poorly-integrated business rules that only works most of the time. The way to avoid this "organic" evolution of process is to invest a little extra time during the design phase of any enhancements you make. Enhancements almost always have ripple effects, so it is important to identify the moment when the underlying architecture of the process is no longer up to the challenge of the new requirements. If a redesign is needed, factor it into your estimates for the enhancement.
From a productivity perspective, the most important place to simplify is in any kind of user interface. Granted, automated processes benefit from simplification as well, but it is human productivity I’m most concerned with here. If users have difficulty understanding how to use an administration tool, consider redesigning that tool to match the way they think about the problem they have to solve, and try to support their normal work flow.
Sometimes a missing administration tool is the problem. I’ll get into that more in the Maintain Production Integrity section.
Plan for Change and Reuse in Context
Out in the wild, planning is what many development activities lack. The business owners want something and they want it yesterday, so you are expected to hack something into place ASAP. Once business owners conceive the enhancement, every day you don’t have it done is another day they are leaving money on the table. Sound familiar? You have already lost the race before you take the first step. This situation often leads to poorly managed, schedule-driven projects and a demoralized development team.
Meanwhile, back in the cubicles, the business context is often played down or ignored. At heart, most developers are technologists and aren’t particularly interested in the business that hosts them. After all, they probably won’t be there very long anyway. The lack of business focus causes these technologists to abstract their design to the point where it no longer resembles the business it is supposed to model.
With the struggle between the business and technologists in mind, here are a few suggestions that can improve the long-term success of your application and the productivity of those who must work on it.
Architecture is not optional
Designing for change and reuse requires architecture, so architecture must be planned into the project. If you can follow established patterns and practices, so much the better, but they still must be applied as part of an architectural plan that is tailored for the problem at hand.
I’m not talking about spending months on it. Even a little planning goes a long way. If you plan what you are going to do before you start doing it, your team can be far more efficient at implementing a solution. This concept works well in iterative methodologies and is essential for waterfall methodologies.
Keep your abstractions within context
With object-oriented technologies going gangbusters, reuse is a major buzzword. In practice, however, reuse can be taken to the extreme, until it eventually becomes reuseless (yes, your spell checker will frown on that word).
The problem is that object-oriented purists have a fascination with abstraction. My feeling is that you stop abstracting when the entities you create no longer relate directly to the business context. If you have to make up names for things that don’t have a direct analogy in the business environment, you are probably abstracting things too far. The developers who follow you will have no frame of reference to understand what you did, costing them extra time while they try to unravel your "elegant" (in reality, "over-engineered") solution.
Code for today’s requirements
Don’t anticipate tomorrow’s requirements because you probably don’t know the business direction well enough to anticipate them accurately. Whatever code you produce in anticipation of a requirement will probably have to be recoded later, making the correct implementation harder, not easier.
My main point in this section on reuse is to always keep the business context in mind when you develop a solution. Doing so helps you do a better job of implementing and clarifying the business requirements. You also do a better job of modeling a solution that makes sense to those who follow you, which reduces the likelihood that their response to your solution will be "we need to throw this away and start over."
Document Rationale and Complexity
Every development project I’ve ever worked on required the team to make certain command decisions about how they were going to approach a problem that has several possible solutions. You rarely have a single, clear solution for every problem.
If you are lucky, the team documents the final solution. With few exceptions, however, that documentation rarely offers the answer to the most important question: Why? In some cases, the business requirements documentation provides the answers, but you often see a gap between the business requirements and the technical design. This gap is generally caused by the same context-agnostic mentality in the technical team I referred to earlier in the abstraction section above.
If you don’t document your rationale for doing something, someone later wastes valuable time second-guessing what you did. If you do document rationale, you not only understand why a design decision was made, but you know if the assumptions under which it was made are still valid. It might really be the right time to change the way something works, if the business requirements have evolved.
The trick to recognizing what information should be recorded for posterity is to look at the tough decisions you had to make and the points of confusion you had to clear up during the course of developing the project. The best place to identify this information is during the architectural review, design review, and code review. If your software development life cycle doesn’t include these review points, it should.
The materials you prepare that explain how things work at each review point are priceless to those who come into the project later. During the course of the review, pay careful attention to the questions that come up because those questions identify areas that probably require extra explanation in your code and your docs. This is particularly true of any "why" questions.
If you integrate the practice of recording the why answers into your development lifecycle, you can painlessly provide a valuable, time-saving legacy for the developers who must later revisit the application. Remember, that person might just be you.
Maintain Production Integrity
Developers rarely think about the post-deployment lifetime of the applications they build. Most applications require monitoring and periodic maintenance in order to remain healthy. However, it isn’t unusual to see an application roll out into production, only to fall on its face a few months later because the database server ran out of disk space. Everyone drops what they are doing to fix the problem and business is interrupted until the problem is corrected. A few weeks or months later, the same thing happens again.
Don’t let this kind of thing happen to your project. Take system maintenance and monitoring into account. They should be incorporated into the design phase of the project. It is much easier to incorporate logging, instrumentation, and maintenance processes during the application’s original design and development than it is to hack them in later. Even if you miss a few things that you do have to add later, you will already have the basic architecture in place.
Putting the necessary monitoring hooks into the application is one thing, but giving the production support staff the tools they need to make use of that information is quite another. Too often the support staff is expected to use a cobbled-together collection of raw tools (e.g. DTS packages and batch files) that were left behind by the development team. In reality, if the application is mission critical, the monitoring and maintenance of that application should be a high priority. The production support staff should have first-rate tools to help them do their job.
When you deliver the application, the production rollout should include a monitoring dashboard and an administration interface that provides the features necessary to operate the system, research common support questions, and identify potential problems before they result in system failure.
Fix Defects
Albert Einstein said that the definition of insanity is "doing the same thing over and over again and expecting different results." Yet many times, IT management lets a production failure occur repeatedly, even after the source of the failure is discovered. Do they really think the problem will just go away on its own? The truth is that computers are notoriously consistent in their behavior, both for good and ill.
Sometimes, rather than fixing the problem, the development team must devise a whole new recovery procedure to deal with the recurring failure. That solution is only slightly less insane (at least you anticipate consistent results now). The problem is that you have effectively formalized a waste of time into your standard operating procedures.
Unfortunately, post-production bug fixes generally have a much lower priority than you might expect. Once an application is in production, attention turns to other projects or enhancements that have high business value. Unless a defect causes loss of revenue, it will probably sit on a wish list somewhere until the portion of code relating to it is revisited for other reasons (if then).
What the business ignores is the fact that bugs usually do cost a lot of money. But that loss is expressed as wasted time for those who must recover the system from the problems caused by the defect. Additionally, every moment the development and support staff must spend on a recovery procedure is another moment they cannot spend getting those shiny new "high business value" projects out the door.
This lost time is often swept under the rug. The development team may not want to call attention to the defect, and management just wants to get things running again. Unless the defect is explicitly named as the source of a new project schedule slip, or the problem recurs so often that it gets the attention of upper management, it is unlikely that anything will ever be done to correct it.
To be fair, not all defects are particularly damaging. Just because something doesn’t work as intended doesn’t mean it doesn’t work well enough. My criteria for deciding when the defect goes on the wish list and when it gets put on the schedule is based on what it costs to let the defect persist. In general, it is cheaper to just fix any defect that causes recurring support issues than it is to let the problem persist. Defects that do not require a recovery procedure can often wait.
However, before you can make the decision to put off fixing a defect, you probably have to research the problem and estimate a solution. Don’t waste that research effort: document it. Ideally, you are using some kind of bug tracking system that lets you provide plenty of descriptive information to explain the defect and the steps necessary to correct it. Later, when the issue is revisited, the notes from your research can save someone a lot of time.
Manage the Struggle
This article gives you a few ideas for how you can evaluate and manage the environmental and procedural factors that contribute to poor productivity. If you have experienced some of the problems that I’ve discussed in this article and felt dismayed by them, don’t worry, you aren’t alone: The struggle between business and technology has been around since technology was introduced into the business environment. The trick is learning to manage the way they interact.
Take a few moments to evaluate your own environment. Do you see problems like the ones I described? If so, think of it as an opportunity to improve your productivity and feel better about the applications and processes you leave behind.
