Now that you're writing the next great application that will earn your business billions of dollars
''(and save the universe from certain doom  ;-)''
how do you design the application to run gracefully in production, without a Herculean effort by the ''(already overworked)'' system administration staff?

I would imagine that the developers on an ExtremeProgramming project would have little trouble with this, as they go into production early, and are likely to be closely involved in production support for the life of the project.

But many large organizations actively discourage such sensible strategies,
preferring their standard "throw it over the wall and run away" methodology of delivering an app
-- with a single round of BigBangTesting, and a signoff.

-----

For those who must work without the benefit of reasonable production feedback, here are some tips for MakingApplicationsAdministratable:

	* Write files to a configurable working directory.  Writing log, export, and data files to the same directory as the executable can be bad, because it's easier to manage disk space if volatile data (like logs) is on a different logical partition than static unchanging data (like executable code).  Backup strategies can be more efficient if one can avoid making a backup every day of files (like programs) that remain unchanged for months (or years!).

	* Process, report, and log errors in a consistent manner.

----

Traditionally (or in local tradition, anyway), the only thing that trumps YouArentGonnaNeedIt is OnceAndOnlyOnce. On a ReducedVisibilityProject, add to the list of things you ARE gonna need practices like the above that reduce the need for visibility.

And also add visibility.

For example, deep in the biz rules layer of some obtuse program that does something obscure, write a reusable that dumps a biz object into an HTML file. Then show it off like this:

    system ("start " + strFileName);
That (on a monopolistic system) will raise the user's favorite Web browser with your file displayed in it.

When the person you intended to read it (the customer for the feature you are working on) complains, review it with them. Then just say, "Oops, I was gonna leave that on until it completed its mission, so I'll turn it off now."

--PhlIp

''Isn't this an example of violating YouArentGonnaNeedIt?  Where was the story card for "displaying this business object in a web page?"''

Depends... did they (the developers) need it during development?  Could be considered to be like asking "Where's the story card for the second unit test on object ''foo''?"  

Upon seconds reading, I realize I misread that (oops).  It could still be an appropriate response under different circumstances, of course