3 Things YOU Can Do to Increase Your Developers’ Productivity
Project managers, raise your hand if you’ve ever asked or been asked this question:
How many lines of code have you created this month?
For some reason, there is a belief that goes around non-programming circles that a good software developer can be judged by how many lines of code they can write at a time. But actual programmers know that this is largely untrue, and that the quality of the code is at least as important as the amount of code produced.
If you think about it, though, it makes sense that this distinction can go overlooked; productivity is often measured by how many deliverables you have to show at the end of a given time period. So by that logic, the more code you produce, the more productive you have been, right?
Not necessarily. When you are aiming for quantity over quality, you leave your program susceptible to bugs, sloppy structure, and poorly documented code. No matter how much time you may have saved by getting something coded quickly, a few bugs in the code can become incredibly costly when they aren’t caught early. Beyond that, dealing with unmaintainable code, or at least difficult to maintain code, can completely undo all that “productivity” from before. All code that is being used is considered as being maintained, whether this is a case of bugs getting fixed, or new code being properly added and documented. If the code is hard to understand or designed poorly, the cost (both in time and money) of maintenance goes up, and productivity tanks.
The cost of a bug (defect) goes up the later it is found in a development cycle. Image courtesy of Hewlett Packard Enterprise Community (community.hpe.com).
So what can you do to optimize your software quality (and productivity) the first time around?
1. Define Reasonable Requirements Based on Quality, not Quantity
Having a clear set of requirements and deadlines based on the qualitative needs of the moment enables developers to work towards meeting achievable goals. And while the ideal endpoint is a complete, bug-free product that requires minimal maintenance, it’s just not realistic to use as a sole benchmark. Instead, goals that meet immediate needs are easier for developers to reach, and reduce the stress of trying to create some unattainable monolith.
That isn’t to say that you need to lower your expectations. An under-performing product is no good, and while easier goals make for great stepping stones, figuring out which benchmarks are most important can take up a lot of time.
Overall, the best advice is to define exactly what requirements you need to meet to have a functional product that falls within time constraints, budget, and the amount of resources available. A great first step is to publish simple quality metrics accessible to all members of the team. Having an open and uniform set of expectations will do wonders for software quality. By listing items such as the total allowable number of defects per phase or the basic functionalities required by certain deadlines, you can give developers a concrete visualization of where they are in terms of progress, and where they need to go. Having a clearly defined path, and a way to gauge where they are on that path can keep developers on target and productive.
Leave A Comment