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.

2. Use Peer Reviews to Take Advantage of Resources You Already Have

Peer review is when the author of a program and one or more of their colleagues sit down and examine the code in order to detect and correct any issues within. This method is often used in literature between writers and editors, and the principle is sound. A fresh pair of eyes will often catch mistakes that the author themselves would otherwise miss.

Peer review is generally considered the cheapest, easiest method of early bug detection. It requires no additional hardware and gives developers a chance to practice their skills and help each other learn, which in turn can prevent similar mistakes in the future. This testing also happens very early in the development phase, meaning that bugs can be caught before they become expensive (and stressful) problems. Inspection is even faster than automated testing, as studies have shown that developers can find defects in code 3–4 times faster through inspections than can be found through testing.

Worried that taking developers away from their own code to do reviews will reduce productivity? Don’t be. Inspections expert Tom Gilb reports that “each defect uncovered by peer review can save up to nine hours of work when compared to having to find and fix a defect later on in the cycle.”

3. Complement Reviews with Quality Testing Practices

Skills essential for a good software tester. Image courtesy of Guru99.com.

Although peer review is highly effective, it shouldn’t be the only process used to review software quality. System performance and UI usability can’t be determined by just looking at lines of code. Furthermore, there’s always a margin for human error, as even the most skilled editors miss errors on occasion. And while peer review often catches issues such as redundancy in the code, unclear error messages, and inadequate comments, software testing demonstrates the actual behavior of the code in the system. Testing puts your team in the seat of the user, giving them a whole new perspective on the quality of their software.

The two aspects of software testing. Image courtesy of dotnetcurry.com.

There are two major forms of software testing: automated and functional. Automated testing is when a tester uses a specified debugging program to run through the code. When the debugger is finished, it returns a list of the code sections that are passing or failing the checks. This method of testing is good for finding spots where code simply isn’t executing properly, and leaves the tester free to work on other projects while the test program is running.

There are times, though, where automated testing can be fairly inefficient. For example, if one aspect of the code fails, the debugger usually immediately stops checking that section. If there is another error further down the line, it will be passed over until the initial defect is corrected.

Functional testing, on the other hand, is when a person or group of people sit down with a working version of the software, and test individual aspects manually. This is where most system performance and user interface defects are identified, as developers get to see the software in action.

Functional testing also serves to test the outcome of six essential criteria (source: Wikipedia):

  1. It verifies the functions that the software is expected to perform
  2. It creates input data based on the section of code that is being tested
  3. It determines the output of the section of code that is being tested
  4. It ensures that the test case executes correctly
  5. It demonstrates the difference between the actual output and the expected outputs
  6. It checks whether or not the application works as per the customer need

Functional testing, of course, runs into similar concerns as those tied to peer review regarding time, resources, and developer involvement. Since it’s a manual form of testing, a human needs to be present to navigate through the software and to record errors, specifically what they were doing when the error occurred, and the steps required to recreate the error.

While each of these suggestions is a powerful tool individually, the best way to improve your software quality is to use all three in tandem. Using these three methods of catching defects in your software will greatly improve its quality before it even gets passed to QA.

Next week, we will go more in depth on the various methods of peer review, so make sure to subscribe!

Originally published at www.deepcoredata.com on February 19, 2016.