Recently I gave a presentation regarding developer productivity - something that has always interested me. Generally, when a system gets out of control with spiralling technical debt and software entropy it becomes impossible to make changes or add new functionality to that system in a reasonable and predictive way. At a critical level, this can be the difference between project success and project failure. If processes are smart, good structures are in place, developers are productive not burning out from late hours debugging crazy code, terrified of the impacts of any change.
Everyone wants a path to project delivery that is smoother. No matter what the job or the task it is generally far easier to get a sense of satisfaction from a sense of productivity. But let's face it; software entropy exists in nearly every project. Why? Are we not smart enough to use the machines we designed? Do commercial realities inevitably mean bad code happens more than good code?
These are questions that spark lively discussions. In this presentation, I outline some of my own ideas on developer productivity.
Everyone wants a path to project delivery that is smoother. No matter what the job or the task it is generally far easier to get a sense of satisfaction from a sense of productivity. But let's face it; software entropy exists in nearly every project. Why? Are we not smart enough to use the machines we designed? Do commercial realities inevitably mean bad code happens more than good code?
These are questions that spark lively discussions. In this presentation, I outline some of my own ideas on developer productivity.
