Pressure To Produce

When programmers complain about the "pressure to produce more," I usually describe this as a positive thing. Programmers, managers, software companies, and consumers all want more and better software. It is the basic axiom of our field.

When I say "if I could find a way to produce 10 times as much quality software in a day, I would do it in a heartbeat," all the programmers' heads nod in violent agreement.

Most of us came to this field because we really like writing programs, solving problems, and making things work.  Learning algorithms and data structures was a small part of the answer, as was learning programming languages and idioms. But the underlying drive is still to make things that work using logic and flow and structure and all the IQ we can muster. We build because we love to build.

There is more than productivity to consider in software, such as building the right thing (product management), and building things well (craftsmanship), but productivity matters to everyone in this field.

This is the healthy pressure to produce.

There is an unhealthy pressure to produce as well. It comes from people making too many large promises. Again, they were doing the best they knew how to do, and there are usually significant opportunities for revenue or positioning.

When those who make promises aren't informed by a feedback loop that lets them know what is possible and how much reserve capacity the teams have (you do have slack, don't you?) then no rate of production will be sufficient. Too much will never be enough.

Worse, if those who make promises are in authority over those that have to deliver, and are not responsible to those who have to deliver (a common large corporation problem) then the problem is always seen as a failure of the development team to deliver.

Either way, the most positive result possible is to revise the system of production to its maximum productivity.  This involves having a more evolved theory of productivity, greater information to support decision-making, better teamwork, and more explicit management of code quality. It's all hard stuff that takes time.

The least positive way is to abandon all discipline and intelligent approaches and just write bad code as quickly as possible (usually with cut-paste-edit cycles) so that the resulting products will destroy your ability to move forward in the near future. The appeal of this approach is that you can begin it immediately (and may already have).

Either way, once you see the pressure to deliver you have to respond. You can refuse to change, take the low road, or take the high road. Only one of these is really interesting and has any promise for a brighter future but your team must make a choice.