By mistaking developer efficiency for developer productivity, we end up creating less productivity. It's an easy trap to fall into. The very shape of your organization is an amalgamation of past responses to productivity problems. Efforts to increase productivity that don't penetrate to the depths of the problem but only reach so far as efficiencies localized to particular job functions not only fail to solve productivity problems, they also fail to fix the counter-productive organizational problems that are the unfortunate side effects of previous naive attempts at treating productivity problems to local efficiency solutions. The organizational problems are also contributors to the vicious circle that worsens software development productivity.
Trying to solve productivity problems by chasing efficiencies that are tied to a particular job function and are not coordinated with other job functions is like swimming in quicksand: even though your right hand and your left hand are doing everything right for everything you know about swimming, the swimming motions applied to the actual medium that you're in are just as likely to make you sink. Swimming is the wrong response to being immersed in quicksand. No matter what your panicing mind is telling you to do, it's just grasping at desperate straws of well-established habits rather than assessing this new situation with responses that might be new to you, and thus quite likely less informed by existing habit. Applying the wrong physics to a medium is almost guaranteed to create side effects that defeat the progress you make against the productivity problem you're trying to solve.
The software development productivity problems that you face are due to a productivity balance sheet that fails to tally the losses as well as the gains. If you simply add more gains to the balance sheet without any regard to the losses, you're not going to understand why the bottom line keeps getting smaller while you're continuing to invest ever more energy into the individual parts of your software development effort. It's not enough to get a bigger bucket to bail the water out of a sinking ship if you're not paying any attention whether the that hole letting the water in is bigger than your biggest bucket. Most software productivity efforts end up snatching a fire axe off the wall and desperately trying to hack another hole in the hull to let the rising water out.
If your organization chases local efficiency solutions to productivity problems, it will end up fracturing itself along job functions that are not entirely separate job functions, but rather individual items on job completion checklists for cohesive workgroups or single workers. As your organization adds to the weight of the processes that petition the productivity spirits to unleash more of this mysterious magical substance from whence we know not, it invariably creates more high ceremony work for managers, eventually calcifying them into clerical functionary roles rather than freeing them to be effective and experienced teachers. The increased ceremonial workload leaves your organization devoid of the leaders who ensure that your organization cultivates successive generations of master workers.
The increased management of ceremony makes it seem as if these managers are doing so much work that the organization around the workload deserves to be promoted to its own department. The resulting departmentalization creates even more of the handoffs and coordination problems that are the fuel for the productivity bonfire consuming your project's allowance of money, people, and motivation.
Your organization will tend to become a fractured collection of organizational shards as it spends more and more of its energy dealing with the mounting productivity losses rather than on producing. This kind of organization produces more internal processes than goods and services that it can exchange with customers for money. Worse, it dries up the pool of knowledge, insight, and vision that creates compelling products and attractive, compelling organizations that compete successfully for more good people and that transform their people into the next generation of success makers.
If you're working off of a one-sided balance sheet, you're failing to connect cause and effect. Failing to connect cause and effect is one of the most common behaviors of contemporary software development when it comes to productivity.
The one-sided balance sheet is a glaring genetic marker of software development that has not been able to connect the effects of it's efforts to the causes of impoverished productivity. The more that one-sided, uncoordinated efforts for productivity fracture organizations along unnatural lines, the more difficult it becomes for software development workers to see the causes of their effects, and the more that dramatic under-performance becomes remarkable. This kind of organization has forgotten the vast wealth of productivity that is its birthright.
The real productivity that you should be experiencing is far beyond the level of productivity machinations that are typically entertained today. The greatest drawback to the promise of software development productivity is just how far-fetched the proposition of potential productivity is. It's multiples greater or orders of magnitude greater than what has become common today.
Amidst all the unbelievable claims of missed productivity is an anchor that can hold you fast to reality of high performance software development: the answers to productivity are incredibly simple, incredibly straight-forward, and incredibly easy to put into practice. There's no magic, there's no mysticism. There are just plain old software design principles at the heart of the matter. Principles that, while seemingly named in a fury of self-indulgent academic terminology fetishism, are nonetheless very easy to understand in practice when they are connected to cause and effect in software development productivity. They are simple principles that can be brought into effect in software through even simpler exercises. Deceptively simple exercises, in fact.
But first, cause and effect have to be connected so that the actions and habits that create the detrimental effects are recognized, understood, and curtailed, and the actions and habits that create productivity are practiced, understood, reinforced, and communicated to others.
First things first: the people who create software must be required to prove that the software that they create can quickly and easily be proven to meet the expectations of it. Expectations for just how quickly and easily these proofs can be made will seem daunting at first, as the organizational fracturing that has been allowed to infect software development as a result of one-sided productivity balance sheets has cultivated a generation of software development that has lost touch with the design simplicity that allows software creators to assume the burden of proof of their own work.
The moment that developers are reconnected with the burden of proof of their own work, software development productivity restoration begins in earnest. To restore software development productivity to your organization, you must reclaim the responsibility of the burden of proof for your work. You do this by learning the dead-simple techniques that cultivate the ability to control and observe your software.
In order to provide a proof that your software works, you need to be able to be able to rapidly control and observe your software. This will invariably change the designs that you tend to use, and guide you toward more simple and clear designs that end up being more easily understood by others, which even further improves software development productivity. Software that isn't easily-understood is the single most important subject in software development productivity. The inability to easily and readily understand software at a glance is a huge part of the productivity loss that goes unaccounted in software development management.
Because of the exasperated fracturing of your organization into departments that are not natural reflections of productive software development, and that contribute to the productivity losses on your software development performance balance sheet, you will not have developed a sensitivity to productive designs. That sensitivity will come. It will come with practice. And while you're practicing control and observe techniques, you're breaking down the barriers that keep both your software and your organization from its productive potential.
The moment you assume the burden of proof, you take steps to radically re-shape your software and your organization to a level of sustained productivity that you would not have presumed possible. By learning to control and observe your software ever more effectively you'll naturally close the gap between the cause of productivity and it's effects.
Next: Denying Productivity
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
