Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been curious about this for a while. What exactly is meant by "production-ready" or its variants? Most recently I was looking for information about sqlite and found this thread, where many people suggest sqlite isn't ready for production.

I know the difference between development/testing and production; my definition of production is anything that is provided to the customer or will be used by non-programmers.

However, there seem to be many items that aren't defined as production-ready. But in reality, they may be perfectly suited and people just have a predujice against them, e.g. sqlite, python, non-MS products, etc.

Small office vs. enterprise? Single user vs. multi-user? Client vs. server? Where do you draw the line?

share

migration rejected from stackoverflow.com Oct 28 '13 at 9:21

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, GlenH7, MichaelT, BЈовић, Kilian Foth Oct 28 '13 at 9:21

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
"It works on my machine."? –  Rook Mar 25 '11 at 1:25
comments disabled on deleted / locked posts

6 Answers

Depends on who you are.

Programmer's definition of "production-ready":

  • it runs
  • it satisfies the project requirements
  • its design was well thought out
  • it's stable
  • it's maintainable
  • it's scalable
  • it's documented

Management's definition of "production-ready":

  • it runs
  • it'll turn a profit

Sorry to rehash this old question, but I happened across it and just couldn't resist.

share
locked by Community Oct 28 '13 at 9:21
    
A big thing I would add to this list is.. when something breaks the system provides enough information that you can figure it out. –  ShaneC Mar 25 '11 at 15:26
    
And not to forget, the ops peoples definition: Monitoring present, well documented and easy update path, release plan, security, performance, automation, ... Some might put it under your points "project requirements" and "maintainable", but most of the time, the perspective of ops people is missing. (Only applies to software which is run through ops people) –  Christian Apr 4 '11 at 6:35
    
Found this today, and I am tempted to change that answer by deleting the "it runs" part from the management paragraph ;-) –  Doc Brown Aug 23 '13 at 20:05
comments disabled on deleted / locked posts

General, "X is not production ready" means that there are issues with missing features, stability, and/or scalability, so that it's usable for less demanding scenarios but may fail for large scale deployments (Enterprise and Internet level deployments).

share
locked by Community Oct 28 '13 at 9:21
comments disabled on deleted / locked posts

SQLite isn't to be used for production databases because it's explicitly designed without many of the features that are considered "required". For example, locks affect the entire database, there are no foreign keys, and until SQLite3 there weren't even any data types.

More generally, it means that a system that works fine for a very small number of users (1-5) in development will crash and burn when exposed to heavier loads.


I should mention that this depends on the environment an application is used in, as well. Going back to the SQLite example, it's perfect for in-production use if there's only one client. Mac OS X uses SQLite extensively through the CoreData framework -- I believe it handles things like the user's iTunes music database and iMail mailbox. Just don't try to use it like a real client-server database.

share
locked by Community Oct 28 '13 at 9:21
comments disabled on deleted / locked posts

As you suggest in the latter part of the question, "Production Ready" is not necessarily a definition of size of deployments, but rather is it fit for it's intended use and requirements. For example for a single-user client app, the SQLite might be production ready. The intended market will most often determine whether an app or system is production ready in its use of the app or system.

share
locked by Community Oct 28 '13 at 9:21
comments disabled on deleted / locked posts

Our internal definition of a build that we will ship to production is very simple ...

  • No Severity 1 issues are outstanding; and,
  • No Severity 2 issues are outstanding that are not marked "Known Shippable"

The KS decision is made by me and one other person.

share
locked by Community Oct 28 '13 at 9:21
comments disabled on deleted / locked posts

There are a lot of definitions that can be used for "production ready".

My own personal ones are listed below - and they are all somewhat practical, and very dependent on the context - in some contexts the same exact solution can be considered "production ready" while in another context that same solution will - sometimes literally - be "production ready over my dead body".

The definitions below all assume that "production" has a context of "some serious outcome depends on successful running of he product".

  • In other words, software running your "best orchids to grow in Nevada" free forum earning you $3/month in AdSense revenue falls way outside of production" context, while Space Shuttle firmware is firmly in that context.

  • Everything else in on a scale, with some things a bit gray (e.g., some software doing academic research - on one hand there's no obvious production impact if it breaks in a generic situation; on the other hand multi-trillion-dollar political decisions are being made by governments on the basis of some specific research).

2 definitions I can come up with now are:

  1. Can be used for purposes which, when things break, imply material losses, under a standard risk analysis.

    This doesn't mean a guarantee of lack of breakage/bugs - no software can do that - but a reasonable level of certainty in the stability for the intended purpose.

    E.g. the benefit of using this solution outweighs the magnitude of potential losses from the breakage multiplied by the probability it will break.

    Hence, Java's infamous "not for use in nuclear power plants" disclaimer.

  2. Can be reasonably expected to have passed Due Diligence by your peers.

    E.g, if, in case of a lawsuit, a set of N random experts from your given field is asked "given these details, was this production ready?", you're reasonably sure that most such experts would agree with you that it was ready, based on the investigative and working efforts you could have reasonably made under the circumstances. If you failed to write more than 10% test cases, you fail Due Diligence. If your program failed due to a previously unknown bug in gcc compiler, you probably didn't fail unless your software was running something life-important that warranted a level of scrutiny needed to have caught even that bug.

share
locked by Community Oct 28 '13 at 9:21
comments disabled on deleted / locked posts