Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have to extend a web application for a customer, there is no documentation of the current app, no analysis and even worse, there is no technical support or management. The client gives me a list of his expectations and nothing more.

What are the best practices to start such a project?

share|improve this question
up vote 8 down vote accepted

Probably the thing to do is to start thinking like an IT department. Yes, really. The idea is to avoid the risk of breaking something in production and not knowing why. Suppose for instance that you started hacking a new feature into the live, production application and something broke. Now the application is down and the customer is breathing down your neck to get it fixed. That would be a stupid way to proceed, right? So don't do that.

It's hard to imagine exactly what the environment is like, but you say "no technical support or management." So there's a web application running on a server, and that's it? Is there a test system, deployment procedures, source control, etc.? I'll assume not.

Given that, here are some ideas for how to proceed.

Get Read-Only Access, or Snapshot the Production System

Get access to the production system so that you can poke around to see how things work. Be very careful not to modify anything. If necessary, see if you can get a snapshot of the system (say, a filesystem backup), and restore it elsewhere. That way you can poke around without fear of accidentally fat-fingering a command and breaking something.

Source Control

If the source code and configuration files for the system aren't in some kind of source control system, create one and start using it. Even if you're the only one working on the system, this will help you track your changes, and if something breaks, you can roll back to the previous version.

Backups and Restores

Is the production system backed up? If it isn't start doing it. Obviously, don't try a restore to the production system. But do try a full restore to an empty system to see if you can recreate a replica of the production system.

Test System

Now you should have a system that's effectively a mirror of the production system. (Notice that I've started to use terminology like "production system" and "test system".) You can now tinker with the test system without fear of breaking the actual running application. Depending on how big a project this is, you could do development and testing on the same system. Or you might want to separate them. You might even consider a separate staging system between test and production.

(Search for "developmestuction" on if you want to read horror stories about mismanaged production environments.)

Analysis, Documentation, Development

Now that you have a test system, you can study it and write up some documentation for how it works. The goal isn't necessarily to document the whole system, but to generate enough information for yourself so that you can implement the new feature. You can also tinker with things to see how they work (or not) which will assist with the analysis and development of the new feature.

Testing Procedures

Now that you have a test system, perhaps with some new features added, how are you going to test the system? You need to make sure all the existing stuff works as well as the new features. Generate test data and automated tests if possible. If tests are manual, make sure you have a full set of actions scripted to test all the functions, e.g. create record, modify it, print a report, delete, etc.

Deployment Procedures

Now that you have all your code under source control, how do you put it into production? This also could be fully automated or a scripted set of manual actions, such as:

  1. shut down application server
  2. rsync files from staging to production
  3. restart application server
  4. smoke test (connect to web page to see if it works!)

Make sure you write down the rsync command or put it in a script or something. Getting it wrong could cause a catastrophe!


This might seem like overkill. Maybe it is. It depends on how big and how critical this system is. It can certainly be scaled down to be simpler if the risks aren't that big. But I can't overemphasize the need to think about testing and development separately from production. I've heard some amazing war stories about how somebody was tinkering with the production system and caused days of outages costing millions of dollars. I also can't overemphasize the importance of source control and deployment rigor. There are many other war stories of how somebody got something "working" on the production system, and the change never made it back into the source control system. The next time they deployed, the change was undone, things broke, and nobody could figure out why.

Anyway, good luck with this!

EDIT: clarified the first paragraph so that it's clear that it's talking about making changes directly to the production system.

share|improve this answer
The idea is to avoid the risk of breaking something and not knowing why - this is a bad advice: this is what makes code grow like spaghetti. You have to create an environment where there's OK to break something and you have meaningful feedback (sometimes even at the cost of some angry minutes from the users), otherwise you'll ruin the source code in days. Perhaps ask some users to use a test version, as the users are the main source of how the thing is supposed to work, the only problem that they can only tell you this when it doesn't work that way. – Aadaam Aug 14 '12 at 21:19
@Aadaam - I think the key here is the "and not knowing why". Yes, you need to be able to break things in a test environment--and you need to be able to determine WHY they broke--before you push it into production. – Matthew Flynn Aug 14 '12 at 21:34
@Aadaam -- by "breaking something" I meant the kind of breakage where users connect and get a stack trace thrown into their browser page. There's no opportunity for feedback here; it just needs to be fixed. Now if you're talking about changing the user interface or something, then Matthew Flynn has the right idea of doing user testing on a test system. It's unclear whether the OP has an environment where "some angry minutes" are tolerable. In some places this is fine, in others it's unacceptable. – Stuart Marks Aug 14 '12 at 21:44
See, I did complete refactors on Alexa Top100 website... and it's an e-commerce site (hotel bookings), so it was important not to break, but I had to refactor a few thousand lines as noone else dared to touch it, when it was only 200, so they only added their stuff when change was needed...Oh, the code was in Italian, I don't speak Italian. The fully refactored (not rewritten!), English, MVC code went into production a week later, and it does still run. Oh, and it was in PHP, forget Eclipse's analysis. Courage and knowledge can help code quality. – Aadaam Aug 14 '12 at 22:04
Good for you! Now, you made your changes in a test environment, not the production environment, right? And if everything crashed and burned after putting it into production, you could have rolled it back to the previous version, right? I was cautioning the OP against making changes directly to the production system since (and I'm guessing a bit) it seems that the OP's environment isn't well controlled. Aggressive changes and cleanup are good, but with a safety net in place. – Stuart Marks Aug 14 '12 at 22:50

In addition to information given by @Stuart Marks, you need to clearly define your responsibilities and your customer responsibilities. For example, your customer should allow for time to test your work and they should make payments according to some agreed schedule. Maybe the customer has to pay for hosting fees and other project related fees. Also, you should negotiation with the customer when and how to close the requirements window. You can't build one page then keep on changing it until the customer is happy. Figure out a way where you can tell the customer that this requirement does not belong to this release.

I invite you document the requirements, even in a simple document and read it with the customer to confirm the requirements. Make sure the customer understands what you will not do and what you plan to do. Most importantly tell them the cost and expected time frame. Include the risks you may face because of the current shape of the application.

Although not so nice, one has to identify what courses of action should be taken in case you and your customer don't agree, this includes resorting to arbitration, penalties, etc.

In short don't make assumptions and don't make your customer make assumptions also, specially about high level issues. Make every thing clear from the get go.

share|improve this answer

Depending on the scope of your project there are several points that need to be taken into account:

  1. First thing first, planning. You should discuss with client your needs of application analysis and production support that probably you are going to implement. Setting up clear goals and expectations with client will ensure that there is no assumptions on what you are supposed to deliver.
  2. Create development and deployment environments to support this application (Dev, QA, Staging, Production). By now, you should be having Dev and Prod, however do not underestimate importance of QA and Staging environments.
  3. Set a time to create technical documentation of the project and convince the client that it is in there best interest. (There is always say that, what will happen if bus will run over me, one day?)
share|improve this answer

Fast-Tracking, Rapid Application Deployment, Rapid Deployment and many other euphemisms started appearing on the project management scene a few times ago. One can't really argue with their objective - speed up projects and therefore reduce cost.


  1. You can have good

  2. You can have fast

  3. You can have cheap

But you're not likely to get all three, so Pick the Two that are most important to this project!

  • Define project correctly, and do a Postmortem at each major milestone and after completion


  • Without a plan, your project will be impossible to control

  • People who must execute a plan should be involved in its preparation

  • Use a Project Notebook to fully document a project - proper and accurate documentation is an important aspect of project management best practices

  • Project plan should be signed off by all stakeholders in a meeting. Use a Change Order form, signed by affected stakeholders, to record significant changes to the project.


  • Mission statement should be developed for larger projects before goals and objectives are established.

  • Satisfying the customer(s) of a project must be a primary concern.

  • Objectives should be written out and placed in project notebook

  • Objectives should contain actual calendar deadlines rather than being specified as "within x months"

Estimating Time and Cost

  • Padding is legitimate to reduce risk, but should be done above the board

  • An estimate is not a fact

  • Reduce time available for a person to work on a project to allow for meetings, breaks and other interruptions

  • Use chart-of-accounts to track labor costs.

  • Record time daily to ensure accuracy.

  • Gantt chart is most useful to see who is responsible for which tasks.


  • Scheduling considers both duration of tasks and sequences in which work must be done.

  • Break work down only to level needed to develop an estimate sufficiently accurate for intended use.

    Don't plan in more detail than you can manage.

  • Bar chart = Gantt Chart

    Note: Bar charts do not usually show interrelationships of work, thus do not permit easy analysis of impact on a project if one activity slips

  • Software can show how vacations and holidays will extend working times in order to assess their impact


  • You must consider your own Organization Structure when planning and staffing your project.

  • Hierarchical structure has serious disadvantages for running multi-discipline projects.

  • Matrix is almost synonymous with project management because of its advantage in dealing with many disciplines.

  • Success in matrix requires very good interpersonal skills on the part of all managers

Project Manager

  • Look for a leader, not just a manager. People skills are important.

  • Negotiating skills and flexibility will be important attributes. No project ever goes exactly according to plan and the PM has to negotiate the adjustments.

  • Problems "go with the territory" and must be resolved. Avoiding conflict and technical problems only lets them fester and build.

  • Communication skills are critical. PM will often have to bridge a gap between technical and non-technical stakeholders. And credibility is always at stake

  • PM really has to be "everybody's friend...and nobody's friend" in order to lead the project to the desired conclusion.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.