Like almost anyone who's been programming for a while, I'm familiar with the term "production code" and have a vague sense of what it means. However, can someone offer a semi-rigorous definition, since it seems Wikipedia and Google can't? It seems like there are a lot of gray areas in what counts as production, such as internal tools that are used by a small group of people and therefore not "formalized" in terms of UI, documentation, etc. and open source apps that are feature complete, reasonably bug free and working, but lack polish, UI and extensive testing.
The definition as I understand it is that production code is any code that is installed or in use on a live, non-test-bed system. A server used internally to a company is a production system if it is the live system used by the employees of the company. The point here is that code running on a server internal to the company writing the code can be production code.
Usually, a good distinction when looking at internal code is whether or not the group maintaining the code is separate from the group using the code. If the groups are separate, odds are that the code is production code. If running the business depends on the code, then it is certainly production code, even if it is developed and maintained in-house.
Production means anything that you need to work reliably, and consistently.
Whether is a build script, or a public facing web server.
When others rely on your code, particularly folks who may not understand it (i.e. even "smart" developers but perhaps not in your group, but using a library you wrote), that code is production code.
It's production because "work stops" and "money is lost" when the production code fails.
When your code runs on a production system, that means it is being used by the intended audience in a real-world situation.
Production code, however, does not necessarily mean robust, reliable, or stable code. The Daily WTF provides plenty of evidence in this regard.
Any code that will be used by it's intended userbase would fit into my definition of 'production code'.
Of course, the grey area in that definition would be clearly defining who your userbase is.
G-Man
EDIT: The short answer: If you are "betting the farm on it", it is "production".
This is a great question--an absolutely critical distinction that routinely gets everyone in trouble due to misunderstandings. The question of what is "production" is a subset of the related question of what is an "environment".
So part of the answer is that "production" is THE "environment" that is most important and is most trusted as THE "real" thing.
So now we must define "environment" (and then revisit "production"). We are still far from a satisfactory answer.
We programmers use the term "environment" constantly to refer to computer systems consisting of hardware that is executing software. That software is the code that we wrote plus software that it depends upon, which was written by others. We write our code and integrate it with the other software, then we typically run the integrated software through an escalating series of tests (unit tests, integration tests, functional tests, acceptance tests, regression tests, etc.), until we finally run the integrated software in the full manner in which it was intended.
Of course, not everything is fully automated. There are usually numerous people involved, and they have manual processes to perform. We programmers look for ways to automate as many of these processes as possible, but there is always a "man/machine boundary" in the systems we work on. Often, there are many such boundaries in any particular case.
On the other hand, there may not be any significant automation at all. For example, we spoke of "production" way back when we had a room full of people performing manual labor which produced a product. So, there doesn't have to be any automation present in our "production" "environment". There is also a middle ground, where the automation involved does not include software, such as in the case of a person running a loom to weave cloth.
Also, there may not be a product, since we have adapted our language of "production" "environment" to include product-less service providers.
Likewise, the testing may not involve software, since we may be testing a non-software-driven machine (e.g., the loom) or even the people (training and evaluation).
Now we have touched on all the crucial elements of an "environment":
- there is a purpose, an
intent
, being pursued - an
intent
requires an intender, so there must be asponsor
(a person or group, but not a machine) that specifies theintent
- that
intent
is pursued through variousprocesses
that are performed by variousactors
- those
actors
may be people, they may be software executing on hardware, or they may be non-software-driven machines, so there may or may not be automation present
Now we can properly and fully define our original terms.
An
environment
consists of all theprocesses
and theiractors
that collaborate to pursue a particularintent
on behalf of itssponsor
. That means software executing on hardware, that means non-software-driven machines, and that means people performing their various duties. It is theintent
that primarily defines anenvironment
, not itsprocesses
or itsactors
.
Furthermore...
If the
intent
being pursued in a particularenvironment
is thesponsor's
ultimate goal, which usually involves producing aproduct
or providing aservice
in exchange for money, then we refer to thatenvironment
asproduction
.
Now we can go a bit further.
If the
intent
being pursued in anenvironment
is the verification ofprocesses
and theiractors
in preparation forproduction
, we call that atest
environment
.We further call it an
integration
environment
if that testing involves the initial joining together of significant individuals or groups ofprocesses
and theiractors
.If that preparation involves the "programming" of human
actors
to perform newprocesses
, or the subsequent verification (evaluation), then we call that atraining
environment
.
Armed with these distinctions and definitions, we can now understand several common scenarios.
An environment
can be mislabeled with a name that does not match its intent
, such as when a training
environment is used as test
.
An environment
can be grossly misused, such as when integration
or training
is done in production
.
An environment
can be misrepresented, such as when key processes
or actors
are left unidentified (e.g., manual reconciliations, or even by ignoring the people altogether).
An environment
can be retasked, by repurposing its processes
and actors
to a new intent
. A very successful technique for some organizations is to routinely "flip" several sets of actors
(servers hosting software) between production
, test
, training
, and integration
upon each release.
In most cases, a single actor
(person or hardware) can execute multiple processes
which can participate in multiple environments
. For example, a single computer server can host software that performs production
transactions while also hosting other software that performs test
or training
functions.
Normally, a single instance of an actor
should participate in only one environment
at a time. On very rare occasion, a single actor
can be shared across environments
if the intents
are mutually compatible. Most of the time, it is very unwise to attempt such sharing because the intents
are not really compatible. A perfect example is running a test
process
on a server that also supports production
processes
, resulting in downtime because the test
caused the entire server to fail.
Therefore, the intent
of an environment
must be construed with very wide latitude, to include concepts such as availability, reliability, performance, disaster recovery, accuracy, precision, repeatability, longevity, etc. This means that the actors
and processes
must often be construed to include things like providing power, cooling, backups, and redundancy.
Finally, note that the situation can get quite complex. For example, a desktop computer (actor
) may be tasked by the development team (sponsor
) to host their source control (process
), which the team relies upon for their primary jobs (production
). Nevertheless, the IT staff sees that same desktop computer as simply a developer workstation (development
, not production
) and treats it with contempt and nonchalance when it develops a hardware problem. But the developers are producing production
code, so aren't they also part of production
? Perspective matters.
EDIT: Production quality
A solid verification (testing
) methodology should take packaged code from development
and run it through a series of tests
(integration, TQA, functional, regression, acceptance, etc.) until it comes out the other side "stamped" for production
use. However, that makes the package production
quality, but not actually production
. The package only becomes production
when a sponsor
actually deploys it into an environment
with that ultimate level of intent
.
However, if your organization merely produces that package (its product
) for the consumption of others, then such a release comes as close to production
as that organization will experience with respect to that product
, so it is common to stretch the term production
to apply rather than clarify that it is production
quality. In reality, that organization's production
environment consists of the actors
and processes
involved in its development/release efforts that result in that product
.
I said it could get quite complex...
In simple words "Production code which is live and in use by its intended audience"