Are there any formalised minimum quality standards for software development?

Question

I've joined a very large new company who have very different ideas about what constitutes quality in development. In trying to convince managers about what should change, are there any well accepted documents about development practices in an agile environment?

We work in mobile development and the existing developers are more concerned about speed and deadlines, rather than the following...

• unit testing,
• testing coverage %
• code review,
• having any merge/pull requests
• using separate branches for features vs everyone committing directing to dev branch.
• what should block code merges/accepting pull requests,

Answer 1

The bullet points you describe in your question are all either ways to measure code quality or support processes. While they do attempt to verify that your code meets a particular quality standard and provide some organizational tools, they don't actually produce good quality code. Sensible software development practices do that.

Let's take your bullets in turn:

Unit testing

The purpose of unit testing is to validate method functionality, provide some test automation, allow refactoring to proceed without breaking existing code, and to encourage good design. You and I both believe that it's a good practice, but there are coders who can produce good code without unit tests. How do you tell those folks that they now have to do it your way?

Testing coverage

Mostly a red herring, having a high degree of testing coverage is widely believed to demonstrate and prove that your code works, when the reality is that simplifying your code so that you need less test coverage is probably a better practice.

Code Review

How many shops actually take the time to do this? I have yet to work in one.

Having any Merge/Pull Requests

Git workflow is a scene all unto itself. Git is a Swiss Army knife with 30 gadgets, when most shops probably only need 5. Do you need a sensible Git workflow? Absolutely. Does it involve Pull Requests? Not necessarily. If you are a project owner on Github, then you'll deal with Pull Requests. But if you're part of an internal team, I don't see how Pull Requests are relevant.

Using separate branches for features

This has some merit, but merging can be a very difficult process, and unless you're very disciplined, staying out of the main branch until your done with your feature (and then resolving the inevitable conflicts when you merge your branch back into the main trunk) can become a nightmare.

What should block code merges/accepting pull requests

It should probably build. Beyond that, you have to decide how much top-level authority you need. Does a team leader review all requests before commit? Again, I've never work in a shop that required this.

So what is the point?

The point is that these processes are all ceremony. None of them have anything to do with code quality, except insofar as they provide checks and balances to whatever effective coding practices are already in place to produce high-quality code.

Answer 2

There's always the Joel Test which I vaguely remembered and instantly found as the highest Google result for "programming team quality" so I would say it is widely known if not "accepted", and consists of the following elements:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

And if you can't answer "yes" to at least 10 of those you have a problem.