What is "Production Code" ?

Replies are listed 'Best First'.
Don't confound "production code" and "production quality code" (Re: What is "Production Code" ?) by mr_mischief (Monsignor) on May 14, 2007 at 06:55 UTC
It should be clear that "production code" is code that's actually in production. "Production quality code" is code that's ready for a production environment. "Production quality code" may or may not actually be in production at the moment, but it's of a quality that it could safely be in production. "Production code" is what's currently deployed in production and handling live users and their data. It may or may not be ready for production, and it may not even safely handle data. Ideally, no code becomes "production code" until it is also "production quality code". Unfortunately, we don't live in an ideal world and sometimes code that's not "production quality code" indeed becomes "production code". Now, go ahead and discuss what makes code "production quality code" or how one tells which code is production quality and which isn't. Just please remember that what makes code "production quality code" and what makes it "production code" are two very different things which hopefully overlap. BTW, in many smaller development environments, the "All functionality is specified to an appropriate amount of detail" checkpoint by itself would be like the first Matrix -- a wonderful dream that's noticeably too good to be true. All too often I get requests like, "As much like (eBay\|Craigslist\|MySpace\|YouTube\|Google) as possible for $1500", upon which the prospective client refuses to expand. Christopher E. Stith	[reply]
Re: Don't confound "production code" and "production quality code" (Re: What is "Production Code" ?) by Anonymous Monk on Aug 25, 2013 at 13:23 UTC
your idea is not clear	[reply]
Re^2: Don't confound "production code" and "production quality code" (Re: What is "Production Code" ?) by Anonymous Monk on Aug 26, 2013 at 11:12 UTC
your idea is not clear ... in the way that it doesn't explain this but confuses that with the other and compares these unlike things together so ... There, I fixed it for you :) Obviously , Don't confound "production code" and "production quality code" (Re: What is "Production Code" ?) is very clear in the idea it expresses -- driving an automobile (code in production) doesn't assume/imply you're driving a honda/mercedes... and not a wreck with wooden frame/body/wheels, no tires, no no steering wheel	[reply]
Re: What is "Production Code" ? by Polonius (Friar) on May 14, 2007 at 08:14 UTC
Empirical evidence suggests that a number of software companies work to a single criterion: When the amount of flak the project manager is getting over late delivery exceeds the amount of flak he expects over the bugs remaining in the software, then the software is ready for deployment. Polonius	[reply]
Re: What is "Production Code" ? by jhourcle (Prior) on May 14, 2007 at 14:37 UTC
I have only one qualification for production code: Is someone going to complain if I take it down? If the answer to that is yes, it's production. Often times, I point someone to one of my test servers, and they decide to send links to other people, suggesting it's available to use ... typically without informing me. Once I know they've done so, I can set up redirection and such back to a legitimate server. (if they send the URL to someone external, I typically find out, because there's the question of why they can't get past the firewall, but one of my test servers needs to have external access due to what's being tested on it, so 99% of my headaches come from that one) ... As for the questions you ask -- the only checklist I have is 'signed off by the relevant stakeholders'. (and that includes the programmers). Some of the stuff I write is a whole 50-60 lines of code, and needs to be up within a day ... we don't go through heavy development on it, it's just that the stakeholders know there's a different level of work that went into it as compared to the larger systems we've deployed.	[reply]
Re^2: What is "Production Code" ? by simon.proctor (Vicar) on May 15, 2007 at 13:30 UTC
I'd agree with this one. Though I would, personally qualify it a bit: Is someone going to complain if it goes down Is someone going to complain when it changes Is it going to lose me/the company money if it goes belly up Am I going to be expected to support or help support it	[reply]
Re: What is "Production Code" ? by varian (Chaplain) on May 14, 2007 at 07:49 UTC
thezip, that's a nice list. I would add requirements to explicitly deal with persistent production data and data structures such as procedures to convert/upgrade data and plans and procedures to revert back to the original data structures and data when needed. The impact of code on database data cannot be underestimated. In addition it makes sense to add an automated install procedure to the requirements list. Not so much for convenience but most importantly to ensure that all installation steps will be executed as a formal pre-documented and logged sequence. this makes the process repeatable and fit for later analysis should that be needed.	[reply]
Re: What is "Production Code" ? by samizdat (Vicar) on May 14, 2007 at 15:00 UTC
That's a good start, thezip. I'd like to focus on the process a bit. First off, a project must have an adequate requirements specification. The most deadly danger to production quality code comes from allowing fungible requirements, also known as "marketing really neeeds this in the release," waaaay toooo late. Second, and this is dramatically more important as teams grow, make absolutely sure all design documents and API's interlock completely and fulfill all required specifications. This is the most crucial step of all, and must precede schedule definition. I think that's where we programmers let planners screw us: we let them create schedules BEFORE we have our design interlock and reviews. Finally, insist on source control and rigid code review requirements. Again, the larger the team, the more delay caused by uncaught bugs breaking the build. One could use a number of descriptions for what constitutes well-crafted code depending on what methodology one follows and what the end product is. My deterministic driver code is going to be a lot leaner than an object oriented GUI would be, but I can follow good data separation practices by building data isolation into my meta-data, headers and build structures. No matter what language, methodology, or end product, you can and should spend the time to craft good self-documenting code. I side with BrowserUK in that the variable names, the declarations, and control structures you choose make a huge difference in the understandability and readability of your code. Variable names such as `$invoice_table_index` are a lot easier to keep track of than `$ii`. Proper use of named constants makes a huge difference in understanding data structure indices. When sorting, for example, `$a[AGE] <=> $b[AGE]` is clear. Similarly, `if ( $invoice_table_index < MAX_TABLE_INDEX ) { ... }` is easily followed. It's important to lay out your control structures and loops consistently, and it helps to use subroutines to minimize code in the top few levels of branching structures to maintain clarity. I like to define error conditions and recursive termination clauses first, and then build the main-line path. In cases where my code needs to be too tight for layers of subroutines, using macros performs the same code-hiding purpose without sacrificing speed. It is up to me to structure my files such that the macros are as readily available for perusal as subroutines, of course. There is always the caveat that even the best code is opaque to a "programmer" (quotes intended) who can't be bothered to study code before whacking. Don Wilde "There's more than one level to any answer."	[reply] [d/l] [select]
Re: What is "Production Code" ? by wjw (Priest) on May 15, 2007 at 04:30 UTC
This is a good subject for a meditation. I think that the answers to the questions you pose depend on the environment that one is producing code in. Backing off just a bit, what does production quality mean? To my way of thinking, production quality "anything" means that the process for generating whatever it is you are producing is clearly defined. What the process consists of may vary from place to place, but when your product hits production, it had better have had a pre-defined process to flow through. This may be tangential, but I will toss it out there anyway. "Production" is a strange term for me when it comes to software. In the solid world of widgets where I come from, a given product may spend anywhere from three months to ten years in "development". The development phase determines things like the materials that are going to be used, the equipment which will be needed to process those materials, methods of quality control... etc... . When you get to "Production", what you have is a clearly defined process which is intended to produce the product(widget), usually in some comparatively large number, with high yields and at least some margin of profitability. Software on the other hand, spends most of its time in "development". After which it is deployed once, then bug fixed and maintained, and updated. A massive development effort for a single one-time product. Ok, maybe that is mostly just semantics, but not entirely. When software hits "production", it is in the end users hands, not the manufacturers hands. In overly simplistic terms, other than the maintenance, the life cycle is complete. Generally, we only make one! That is weird to me because it is the development that we have to develop processes for. Back to the matter at hand..., (sorry for the divergence). A good deployment means that: All testing is complete per the afore-mentioned process The environment that is being deployed to is well defined It is known how the deployable unit(s) is/are expected to impact the environment. The right people are on hand at deployment time. Communication channels have been established between those people Backout plan is reasonable. What constitutes the need for a backout and who makes that call has been established ... lots more oh yeah, did I mention that there are checks in place to document that the development process has been followed? On the other hand a good deployment can also mean that I scp'ed the script to the user, and he/she uses it from now until they retire. It is all process. ...the majority is always wrong, and always the last to know about it... The Spice must flow... ..by my will, and by will alone.. I set my mind in motion	[reply]
Re: What is "Production Code" ? by Errto (Vicar) on May 15, 2007 at 23:40 UTC
I agree with much of this, but I should add that there's a difference between Production and Production. That is, whether a certain application or system is "live" is important, but you have to consider the impact of the system as well. In my corner of the corporate world, we define certain systems and processes as business critical if a failure in them could: result in loss of revenue harm a relationship with a customer expose us to legal liability or pose a threat to environment, health, and safety Some systems meet these criteria and some don't. The ones that do have stricter rules for deployments: deploys occur only at certain times, they are handled by an operations team separate from the development team, written instructions are required, a rollback plan is required, QA has to sign off on the thing working in the stage environment, etc. Less-critical systems follow less-stringent rules.	[reply]
Re: What is "Production Code" ? by Anonymous Monk on May 19, 2007 at 00:02 UTC
I would like to offer an unusual response to this post, if I might. I'm not a PERL programmer, but I have programmed in PERL, lately I've been dotNET programming, but before that I was doing Flash like a madman. Woe is me. What I do I still refer to in antiquated terms: interactive multimedia. Perhaps this shows my age. I've been in this biz since, well, I don't want to say how long. Let's just say I have gray hair. So, to answer your questions. Question #1: What characteristics does production quality code possess? Unfortunately, that is not quantifiable, any more than the question �What qualities does a bestseller book possess?� Good code must be in the right place at the right time. It need not be elegant, it need not be absolutely right, it just needs to be right at the right time. That's a crap shoot. Some code, like the code for windows, was accomplished by many great minds funded by a great deal of money. Committees can accomplish something, given enough time and money. If an analogy were to be given, it is this: great newspapers have great reporters working in concert with great editors. But, newspapers are not considered �bestsellers.� They might be �production quality,� but they are not riveting bestsellers. Then there is is work of the individual. The �bestseller� that captures the imagination, stuns the public, grabs the wallet of everyone involved. That usually comes from a solution to an overarching problem. In the case of coding, it isn't the coding itself. It is as if the person doing to the code understood a basic problem, worked out a coding solution, and bridged the gap between the problem and its solution in a user-friendly manner. Once the problem is solved, it must get out into the wide world. Then, if it is good, if it is right, if it is the right moment, lightning will strike. Question #2: If there were a checklist.... Well, if there were a checklist for baking bread, it would be grocery-store bread. A good baker takes the bread out of the oven when it is right, there is no real checklist involved. Checklists are for assembly lines. Question #3: What are the characteristics of a good deployment? Take a lesson from AVID, which wrote the video editing software. They couldn't control the quality of the software on the end-user's equipment, so they only sold their software at first on machines that you purchased from them. That way they could guarantee it would work. The model worked for them, it has worked (in some respects) for Apple. This is a good lesson. Don't deploy good software on bad machines or machines cluttered with software you can't control. If your software solves real-world problems that cost real-world money big time and must be deployed in real-world environments that are restricted by real-world paranoid IT people who have firewalls under their control that will restrict everything and anything that goes on in the computing environment, then your software must, must delineate the firewall requirements and filtering requirements. If you must filter, they must understand you are filtering. You must be in your own environment with easy access to the machines in which you exercise control in order for your software to work. The minute you must bridge a firewall or security issue, you are in trouble. If this happens, oh, my. Make sure you had a contract and that they paid you in advance for the work. You cannot, repeat, cannot control their IT departments. Even the president of their company cannot control them, as they are creatures unto themselves, usually composed of third-tier programmers who don't know the difference between an integer and a function. Well, just my comments.... Those are my thoughts. Hope they help. RobW	[reply]

What is "Production Code" ?

Design

Implementation

Deployment


We don't bite newbies here... much
	PerlMonks