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.

4 Answers
4

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 thedailywtf.com 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:

shut down application server

rsync files from staging to production

restart application server

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!

Summary

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.

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.
–
AadaamAug 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 FlynnAug 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 MarksAug 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.
–
AadaamAug 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 MarksAug 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.

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

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.

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.

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

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.

General

You can have good

You can have fast

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

Planning

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.

BEWARE SCOPE CREEP!

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

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

Organization

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