You can work at a level of productivity that redefines your present expectations by learning how to intentionally control and observe your software. Controlling and observing is something that every developer does. Doing it consciously makes productivity intentional - it brings productivity squarely under your control and conditions you to see ways of creating even more of it.
You can't use what you don't understand. It's as simple as that. The easier it is to understand how your software works, the easier it is to understand the repercussions of making needed changes to it. The easier it is to understand how your software works, the quicker you can get to work on it and the quicker you can get done. Inevitably you understand how your software works by observing it. In order to observe your software, you have to be able to control it.
Controlling your software means putting it into a state where you can directly run the chunk of code that you're concerned with without having to prepare adjacent chunks of code. If those adjacent chunks of code aren't your direct concern, then you should minimize their interference with the observations you're trying to make and with the understanding that you're trying to develop.
In the end, all software is controllable. If you can open one of your application's screens, fill in some text boxes, click on some buttons, and end up saving some data in your database, then you're controlling your database through those screens. The issue isn't that software is or is not controllable, but how easy it is to control it. You don't get productivity from the mere fact that software can be controlled. You get productivity from how software can be controlled. Some ways of controlling software are incredibly productive - beyond most people's expectations.
The more direct control you have over your software, the more productivity you'll have. Direct control means that if you're trying to run some bit of code in order to observe it, that you only have to setup that bit of code and interact with that bit of code. If your software is designed for controlled productivity, you can do this at all levels of your system, from function libraries, to classes, to layers in n-tier and distributed applications, to user interfaces, to deployment systems, to runtime monitoring.
We're so used to primitive productivity in software development and primitive productivity is so common and so prevalent that we've lost track of basic principles that are still available to us if we step outside of the limitations of our current view of software development - a view that has taken up residence in software development only within the last ten or so years.
The principles are also unfortunately named. The names almost complete obscure their meaning, making incredibly simple and incredibly powerful ideas accessible to only a few people who have a natural penchant for deciphering software development legalese.
Designing Productivity
Higher order productivity - productivity beyond what you'd expect would be possible - is only created by software design. That's it. No tool, no matter how elaborate, can ever create the level of productivity that controllable software can (unless you're applying that tool to your work after having made your software easily-controllable and readily-observable).
To make software controllable, you simply design it in a way that you can have direct control over any bite-sized chunk of it so that you can make observations of it with an absolute minimum of effort and minimum of distractions by concerns other than the one in your crosshairs. The means to designing controllable software is also deceptively simple. It's based on utterly and trivially-easy exercises that can be done with any software development tool whether it costs thousands of dollars, or whether it's absolutely free.
There's a simple way to test if your software can easily be controlled and observed: Choose one bit of important logic buried in your software that is only executed when some if/then statement (or other conditional branch) flows execution to that bit of code. See how much code you have to write before you can run that bit of code, and print out its results. If you have to control not only the code that you're concerned with, but also adjacent code, classes, systems, database tables, logins, etc, then your code is more difficult than necessary to control and observe.
You loose productivity as well as motivation as your system becomes more difficult to control. There's another level of productivity available to you. That level of productivity can increase your effectiveness by many multiples, and maybe even by orders of magnitude.
Next: Mistaking Efficiency for 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
