In part 1, I talked about the reasons that it is so hard to squeeze more work out of programmers and a few common approaches that yield bad results. Now, I’d like to talk about some better ways, that may require more work, but will give you better, sustainable return on your investment.
The “Better” Way
Think about optimization, in general. When you are optimizing a server or app, there is no setting “Set slowness=off, speed=11” (or somebody would have already tried it). The answer differs somewhat, depending on your conditions. Therefore, you have to figure it out, each time.
So, you need to take a few minutes (or hours/days) to study the system. Observe the system and see if it is taking unnecessarily long pauses or determine if some tasks are stealing all of the CPU time. That is pretty simple and obvious. Everybody starts here. Unfortunately, some people stop here too. I know it is tempting to say you already found the solution: the programmers waste too much time. Bam! Done! (Ha ha. Nice try! Keep reading)
With my “server optimization” metaphor: the best way to optimize code or a DB is to consider all of the components involved in the entire system and then determine what things might be impeding it from going faster. Take several measurements. Look for bottle-necks all along the process. Consider everything and determine how much impedance is resulting from each bottle-neck. It can be a lot of information, but often, the devil is in the details.
So, for optimizing your programmers, don’t just look at a programmer and ask him to work better. Look at the development lifecycle and see if there are other bottlenecks that might affect the performance of the developer. There are probably several. Determine if there is easier/greater productivity to be gained from doing something, across a broad spectrum of areas. Try to develop more than one strategy and think of how to measure them effectively.
Step 1 – Analysis of the system
When you apply this technique to the software development process, you get some interesting, but challenging insights. The bottle-necks, become visible, but not the solutions. That is a good place to start. Don’t just pick one and focus on it. Try to find all bottlenecks (even the ones that seem more like jar necks or bucket necks).
The hardest bottlenecks to isolate are the ones that occur early in the development process. However, these are usually the most significant ones. Generally speaking, once a project is past the half-way point, there is usually not much that can be changed to get it done sooner, unless you cut the scope. The 10th law of programming states “Adding programmers to a project that is behind, will only make things worse”. So, there is a strong chance that you will get a bigger ROI if you look closely at the earliest parts of your process.
This is where things get pretty weird. There are so many companies who prefer the Agile process or Cowboy process because they don’t have much of an understanding about the early stages of a project. “You don’t know what to do until you know what to do. So, just get in there and start doing something”. “Fake it till you make it”, is the battle-cry for many people. In contrast, there are some people who use the waterfall process. Those people are like ghost ninjas or something. Maybe they are aliens or robots who can see the future. You may think that is the only reasonable explanation for how a team could be successful with waterfall. Therefore, you have probably already dismissed that idea. Maybe you should reconsider.
Step 2 – Determine if you have found the root cause.
You may have found plenty of problems to treat, but sometimes, the problems were the result of a deeper problem. It is always a good idea to take a few minutes to think about some action or condition that may have produced the thing that produced the problem (one deeper layer of indirection). Who knows, maybe there is even something beneath that too. Take the time to consider these things so you don’t apply a superficial fix, like patching a bicycle tire “inner tube” but failing to remove the nail that punctured it. You will just have to revisit it again, until you address the root cause. It is best to know how deep it goes, before you start fixing stuff.
Step 3 – Choose to treat the effect or fix the cause
Of course, fixing “the cause”, is usually the best course of action but sometimes, it is not a reasonable option. Maybe the cause of all of your problems is coming from the CEO or VP of your company. You can ask nicely for that person to change, but do not suggest firing “the big cheese”. That is impractical and downright risky. Instead, you might have to treat the effect. Some people call this “rolling with the punches”. Sometimes, it is your only reasonable option. It is not a dead-end. You just need to find a less-optimal route. Don’t just shrug your shoulders and say there is nothing you can do. There is. You just have to commit to treating the effect, frequently.
Step 4 – Adjust and Repeat
Of course, when you are applying a fix, it is best to only apply one fix at a time, make sure it works, and then move-on to the next step. It is like eating a pizza. You cannot fit the whole pizza in your mouth and swallow. Start with one slice and one bite of that slice. Once you have chewed and swallowed it, then proceed. Same goes with process optimization. Be realistic about what you can accomplish. Design a roadmap for improvement. Be willing to add more pressure to enact change and also be ready to admit defeat and cut your losses and move-on sometimes.
Step 5 – Get Good at it
So many teams quit before this step. If you want to get good at something, you have to commit to getting good at it, you have to study it, and you have to be disciplined to work on getting better. It doesn’t happen naturally. It requires an investment. This is why so few teams are good at waterfall and so many revert to Agile/Cowboy.
If you want a program done sooner, you could try guessing, but if you want it done much sooner, pick several things to improve. Start with one bottle-neck, focus on it, and get it done. Then move to the next one. Repeat as necessary and adjust often. It might take some time. Like eating a whole pizza. Don’t choke on it by trying to swallow the whole thing. Bite, chew, swallow and repeat. Your software development process will get better, and people will be amazed by your ghost ninja skills and suspect that you might be a robot, or something.