Define "production-ready"

Question

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?

Answer 1

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.

Answer 2

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).

Answer 3

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.

Answer 4

As you mentioned yourself, the suitability of a tool depends on the problem. Don't believe any categorical statement about any particular tool's production readiness. No matter what tool you choose or how much you spend on it, it's probably going to be a pain.

The best thing you can do is try to understand why a particular tool wouldn't be suitable. If you find, say, sqlite to be appealing to develop on top of, play devil's advocate and see if you can honestly convince yourself to stay away. You can also hedge your bets by developing against an abstraction, so if you're ever forced to, you could swap a simpler, cheaper tool for a bigger, more expensive alternative.

As far as determining suitability goes, think about things like:

• software costs
• hardware costs
• scalability
• stability
• openness

Finally, always value hard, empirical data over random unsubstantiated comments you find on the web. Pretty much every interesting web site out there has been built on at least some technology that I've avoided myself because I've prejudiced myself against it without really giving it a chance. The hard part isn't picking the right tools for the job, it's getting the tools you've chosen to work together properly to do the job at all.

Answer 5

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.

Answer 6

*Production ready version = ready to use; can be made available to end users

*Development version = still undergoing development; can only be made available to developers

Answer 7

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.

Answer 8

When you won't lie awake at night wondering if it has died or gone horribly wrong, and indeed when you can leave work at 5.30, have some beers, sleep all night comfortably, amble into work the next morning, and be confident that nothing bad happened.

Answer 9

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.

Answer 10

Turning code into a real product isn't as simple as it sounds. A company expecting to make money from their efforts, or a project expecting to attract and retain users, will need to bring the product to an acceptable state, sure, but they will also need to think about support, distribution, sales, and marketing.

My definition:

• Development has completed and signed off on the final product.
• Project Management has signed off on the final product.
• Test has signed off on the final project
• Documentation, especially end-user documentation, has been written and reviewed
• A product support plan has been developed and approved
• Product support people have been trained
• (A) Distribution Channel(s) has(have) been identified and contracts signed
• Sales and marketing collateral material (demos, movies, brochures, etc.) have been developed and are ready