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,
  • Each of those bullet points is really a question by itself.
    – david25272
    Commented Aug 28, 2016 at 23:44
  • The bullet points seem to be distracting from an otherwise valid question. There are various standards for software development, but those usually pre-date the agile movement, hence, it seems a fine question to ask for a standard in that environment.
    – Frank
    Commented Aug 29, 2016 at 6:52
  • There are several minimum quality standards: 1. Compiles on my machine. 2. Compiles on other machines. 3. Starts without crashing immediately. 4. Starts without crashing if the user touches it. 5. Doesn't crash if I run it and only touch the bits that I know are safe. And so on. (I forgot "Compiles and links" which is good to have as well).
    – gnasher729
    Commented Aug 29, 2016 at 13:26
  • Each environment develops there own standards and guidelines. Sounds like your company has none. Here's NASA's... sdtimes.com/nasas-10-rules-developing-safety-critical-code
    – Jon Raynor
    Commented Aug 29, 2016 at 17:24
  • 2
    None of your bullet points "constitutes quality in development" or are "quality standards". They are simply possible steps in a software development process. The title of your question should probably be the last sentence of the 1st paragraph. FWIW, going into a company with a culture having a "hacker" mentality of speed over substance, you likely will find your desire to add substance is not going to go over very well. Convincing management is not your problem, convincing the developers is. Management just cares about speed and deadlines, they assume you already are building in quality.
    – Dunk
    Commented Aug 29, 2016 at 21:25

2 Answers 2


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.


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.