I’m currently literally within the 11th hour of a gigantic coding project at work. A tool that’s to be used by hundreds of internal Xerox users as well as any number of thousands of end users. Some serious effort has been put into the design of the project. Lots of workflow considerations, lots of role based stuff,  tons of business practices and control issues to consider, and countless other requirements.

As in most big projects, there have beens lessons learned, and while I’m still nursing my wounds and still totally into make numbered lists it’s probably a good idea to make some notes for future reference:

1. Roles
When developing a roles based system, spend as much time as possible considering all the things each role can do. It might even help to do this while coming up with the overall requirements of the project, as they often coincide. For example, if an admin level user can do everything within the tool, you have to define what everything actually is. An end user might only be able to do one thing out of the list of everything, but you still need to define the list of everything.

2. What it Needs to Do

Spend a considerable amount of time designing a functional specification (again, can coincide with developing roles). If the functional spec is vague, it can completely and utterly derail development cycles, costing time, money, and possibly developer mutiny. Functional specifications must be as clear as possible, and shouldn’t say a single thing about how to create the project assets, it should simply describe exactly a function is supposed to do. It should be concise to the point that a developer can create with a high degree of accuracy exactly what is required. Involve smart people when creating the functional spec. People who know what’s technically possible, who are intimate with business processes, and even developers, usability experts, and people who will be using the tool.

3. How to Do It
Spend a considerable amount of time developing a technical specification. This almost mirrors the functional specification, except that it describes how to develop the functionality. It talks about what tools will be used, what already created assets are available, and how they’ll fit in, and how new assets will be designed. Java developers would be describing objects and classes here, CFMX developers would be describing CFCs, Perl developers: modules and such. It’s not the actual code – it’s a recipe for how to cook up the project.

4. Rinse and Repeat as Needed
Run through steps 1 – 3 several times with interested parties. Make them as clear as possible. Leave no stone unturned, and do it with the same kind of intensity as if the project were due tomorrow. Do it until you’re sick. Do it even if it means that the functional requirements have changed 10 times within the process. Do it until it changes no more. All specs must be etched in stone, at least for this version.

5. Do It
Write the code as specified. Any new specifications are to be done in the next version.

6. Test
Test the code, using the functional spec as the criteria. If something doesn’t match the functional spec, or if there is a bug, open a trouble ticket in a proper trouble ticket system.

The trouble ticket system needs priority levels, issue numbers, roles (to track who says what and allow for some moderation), threaded conversations related to the issue (so that dialog surrounding the issue can be read easily). The  trouble ticket system should be flexible enough to merge duplicated issues, but not so flexible that it turns into a chaotic mess. Technical people need to be able to be able to ask non-technical people questions, for screen shots, for specific error messages, data to test with, and more.

Testing needs to be scientific, and needs to be tested in the same environment. You can’t have testers testing on a staging server with data that differs from the development or production server.

7. Keep Control
Use a version control system. An absolute must. Before releasing an application to the staging server, a release candidate should be migrated to the staging server. Bugs found in testing beyond that should be fixed with specific releases of versions. It should always be known that Issue n was cleared up with a Release Candidate 0.89 release for example.

8. Freeze Functionality
Never introduce new functionality during testing. Never. Ever. Don’t let anyone involved in the project even think about it.

9. Use the Best
Hire the best talent you can. Drop problem developers as quickly as possible. If someone is creating rubbish code, and you’re in a rush to get a big project done, you shouldn’t be babysitting and cleaning up. Professional developers can handle intense schedules while still writing exceptional code.

10. Do a Fine Job
Enjoy doing all of the above. Release a good piece of software. Prepare for the next version.