What software development methods maximize return on investment?

The software development team in my organization (which is developing the middleware API) is required to accept at least one best practice at a time. The list contains:

Unit testing (in its real sense), Automatic unit testing, Testing and design, Static code analysis, Continuous integration capabilities, etc.

Can someone please call me a study that shows which "best" adoption practices have the best return on investment and improve software quality faster. Is there any research there? This should help me (support my claim) to prioritize the implementation of these methods.

+4
source share
8 answers

"a study that shows which" best "adoption practices have better return on investment and improve software quality faster"

It would not be great! If that were the case, we would all do this, and you would just read it in DDJ.

Because no, you must accept a painful judgment.

There is no value "make X for ROI 8%". Some of the methods require significant investment. Others can be run for free.

  • Unit testing (in its real sense) - Free - ROI starts immediately.
  • Automatic unit testing - not free - requires automation.
  • Test Driven Design and Development - Free - ROI starts immediately.
  • Static code analysis - requires tools.
  • Continuous integration capabilities - inexpensive but not free

You cannot know the ROI. Thus, you can give high priority to investments. Some things are easier for people than others. You must consider your team’s willingness to accept the technique.

Change Unit testing is free.

  • “The time taken to encode the test could be taken to encode the next function on the list.” True, testing means developers do more work, but support does less debugging. I think this is not a 1: 1 trade. A little more time spent on written (and passing) formal unit tests significantly reduces support costs.

  • "What about legacy code?" The fact is that freedom is a matter of cost management. If you add unit tests to legacy code, the cost is not free. So don’t do it. Instead, add unit tests as part of maintenance, bug fixes, and new development — then it's free.

  • “Moving is a problem” In my experience, this is a matter of several solid examples, as well as requirements for managing unit tests in addition to code. It does not require more than a whole-hand meeting to explain that unit tests are necessary, and here are some examples. He then requires that everyone report their status as “tests, written / passed tests”. You have not completed 60%, you are 232 out of 315 tests.

  • "he is only free on average if he works for a given project." Always true, good point.

  • “it takes more time, time is not free for business” You can write bad code that does not work well and requires a lot of support, or you can write good code that works and does not require a lot of support. I think that the time taken to complete the tests actually reduces the cost of support, maintenance and debugging. In my experience, the value of unit tests for refactoring dramatically reduces the time it takes to make architectural changes. This reduces the time to add features.

  • “I don’t think it’s an ROI right away.” In fact, one unit test has such a huge payback that it is difficult to characterize. The first test to pass will be the one who thinks that you really can trust. Having just one trustworthy piece of code is a time saver because this is the least you need to think about.

History of war

This week I had to finish the bulk data loader; it checks and downloads 30,000 line files that we accept from clients. We have a good library that we use to download some internal files. I wanted to use this module for client files. But the client files are different enough that I could see that the library module API is not suitable.

So, I rewrote the API, repeated the tests, and checked the changes. This was a significant change to the API. A lot of damage. A large number of links to the source to find all the links and fix them.

After completing the appropriate tests, I checked it. And then I repeated what I thought was not a closely related test. By email Oh. He had a failure. He tested something that was not part of the API, which also broke. Fixed. Checked again (one hour later).

Without basic unit testing, this would violate QA, would require a bug report, would require debugging and refinement. Look at the work: 1 hour of a QA person to find and report a bug + 2 hours of developer time to recover the QA script and find a problem + 1 hour to determine what to fix.

For unit testing: 1 hour to understand that the test failed and fix the code.

Bottom line . It took me 3 hours to write a test? No. But the project received three hours ago for my investment in writing the test.

+7
source

You suggest that the list you submit is a collection of “best practices” (although I would agree that it probably is, btw)

Instead of trying to cherry-pick one process change, why not explore your current practices?

Ask yourself:

Where do you feel a lot of pain? What can you change to reduce / eliminate it?

Repeat until anesthesia.

+1
source

There are several references to ROI regarding unit testing and TDD. See my answer to this related question; Is there strong evidence of the cost-effectiveness of unit testing? .

0
source

There is such a thing as a "local optimum." You can read about it in Goldratt’s book, The Goal. It says that innovation is of any value only if it improves overall throughput. The decision to introduce new technology must be connected with critical paths within the projects. If the technology is already accelerating fast enough, it only creates an unnecessary lag in the finished modules. Which is not necessary, improves the overall speed of project development.

0
source

You do not mention code reviews on your list. For our team, this is probably what gave us the highest return on investment (yes, the investments were cool, but the return was even greater). I know that Code Complete (at least in the original version) mentioned statistics regarding the effectiveness of reviews when searching for testing for a VS defect.

0
source

I would like for me to have a better answer than the other answers, but I do not, because what I think really pays off is currently not ordinary. That is, in design to minimize redundancy . Easy to say, but experience.

In the data, this means that the data is normalized, and when this is not possible, process them differently, which can withstand some inconsistency without relying on tightly coupled notifications. If you do this, it will greatly simplify the code and reduce the need for unit tests.

In the source code, this means that some of your "input data" changes at a very low speed, you can consider generating code to simplify the source code and get extra performance. If the source code is simpler, it is easier to view, and the need for testing is reduced.

Not to be jealousy, but, I am afraid, from the projects that I saw there is a strong tendency to excessive design, with too many "layers of abstraction", the correctness of which should not be questioned if they were not there.

0
source

One practice at a time does not give a better return on investment. Practice is not independent.

0
source

All Articles