I’ve recently been victim to a number of software roll outs that were being managed by other people. Each of these experiences brought a single question to mind…What are they thinking? Either they stopped teaching best practices at the university, or I have had the distinct pleasure of witnessing projects that followed some unique system of development designed to screw everything up. In either case these recent experiences have compelled me to elaborate on what I feel are the cardinal rules for software/web development practices.
Before we begin let’s set down some definitions and standard for language.
First and foremost, the client. Say what you will, the client is who pays the bills. Your client is the customer, and the customer is always right. What seems to be lost on most developers is that the client doesn’t have to be the person writing your check. If you work as an internal developer your client is the business, and that business’s goals. If you do not meet your client’s goals, you have failed. Period. There are no excuses. What other purpose do we have as developers if we do not meet, let alone exceed, the expectations of our client?
Second the goals of the project. Your client comes to you and says I want an application/web site/widget to do XYZ. What you need to learn to do is read into and understand WHY. If you don’t get the client to explain to you why they want this project developed, what is purpose is how can you expect to meet their expectations? In asking this question you may even get the client to realize…Why are we asking to build this? All clients know that something isn’t working, that it isn’t right, it doesn’t look good. Very few can tell you why, or how to fix it. It is up to you to determine what the need is, and the best way to match that need. That is the true art in development.
Now that we have some baseline concepts outlined we can discuss the actual development process. I have always worked under the belief that you test before you publish. Now this is a gross simplification of the larger set of rules, but it is a simple guiding principle that should go without saying. Let’s elaborate on what I believe to be the cardinal rules. I think the best way to handle this precious, and seemingly forgotten knowledge is to break it out into phases.
Phase 1: Proposal
All successful projects begin with a a clear statement of work. The statement of work may start out as a request for proposal from a client or as an actual statement of work. Either way the client’s expectations are outlined and presented. Now is the time to ask questions about what they hope to accomplish, what direction they see the work taking, etc. If you don’t start asking the right questions before the project starts you will end up in a real mess later. Once you have a clearly defined goal of what they want to accomplish you can move forward. Also try to get the client to send you links to sites they like, examples of photos they love, and any references to styles that they envision for their project. The other key point to the initial proposal is stipulating your expectations and understanding of the requirements and getting everything down on paper. The completion of this phase ends with a signed contract for both parties. This contract sets the scope for the project, the boundaries of how many mock ups, how many pages, any special coding, unusual aspects, or project details that you foresee getting messy. For an in-house client this may just be a well written spec for the project.
Phase 2: Mock Ups
Once you know what they want you need to begin showing them examples of how you interpret their goal. With web sites I accomplish this with mock ups. These are flat, draft quality images that represent key pages in the project. For example working on a site redesign I will provide a client with about five almost publishable mock ups. All of them need a few tweaks here and there to make them truly publishable, but they give a real sense of what a final site will look like. Don’t show anything that you can’t produce. If the mock up looks unprofessional, so do you, so don’t show anything you wouldn’t want in your own portfolio. Now you enter the really gray area of the project. The client reviews these mock ups and gives feedback. Either they’ll love them, hate them and know why, or hate them and not know why. The latter is the worst. It points out that the client probably isn’t really sure what they want, but they have some idea in their head that they haven’t expressed. Try to drag out that idea now, because otherwise you’ll never stop producing comps, or you will lose the client. Neither is a good option. Once the list is narrowed to one, or two mocks, try to refine them until the client is satisfied. Remember that you specified how many mock ups you were going to produce so don’t go crazy and gently remind your client if they keep asking for more.
Phase 3: Prototype
Now that you have the appearance locked in, you get to make it work. This is your first pass at making a live working site in the style that you mocked up for the client. Keep it clean, comment your code, make it generic, follow standards, use CSS. As long as you keep everything coded cleanly you should be able to set up a framework for the whole site with the first page. If you follow standards you will save yourself work in the end by not having to clean anything up. Using standards also creates less code, smaller pages, better SEO. Commenting your code makes it easier for you to keep track of where you are, and gives your client a good site that anyone should be able to edit. Using CSS gives you a powerful tool for maintaining appearance across the whole site. You’ll see why in a bit.
Last but not least TEST IT! If you don’t test your own work you are only prolonging the inevitable, and potentially making yourself look incompetent. This is where most developers fall down in their duty. If you don’t hammer on your prototype and find the bugs your client will. Then when you have to take extra time to fix them you look even more inept. Once you get the prototype working to your satisfaction it’s time to move to the next phase.
Phase 4: Alpha Testing
Now your client gets to review your work, change text, add functionality, decide on how the rollovers will look, and generally tear into your hard work. Remember, better now than later, so get it all out now. Set the site up on a different, non-public server. Probably your own site behind a password, or in a hidden directory. Give them some time to really hammer on the prototype. My contracts always specify that the big changes have to happen in Alpha. Once they are done they’ll hand you back your brutalized creation in the form of a laundry list of changes. Now you need to make their changes and personally test again before the next phase. This is a great time to tell a story of how not to do it…
This is an example of something I witnessed being perpetrated by other developers, I was working on the web based training course for this new enterprise software roll out. Everything worked in the prototype and they did some limited testing and called it ready for release. The old application was shut down, and the new application rolled out. Now they opened the application to a larger audience and got lots of feedback. Here is where they really screwed up. Instead of making changes in the prototype they made changes to the production site. When they broke it, as it frequently happens with complex sites, they were stuck because they had already launched the application. Now if they had tweaked the prototype, tested it until they got it working, then migrated it to production, the client could have continued to work in production until the changes were migrated. Now they have two steaming piles of useless application that no one can use. Bad developer, no caffeine. Bad manager, no promotion, no bonus. Bad company, loss of productivity, loss of revenue, waste of time. Additionally they had training that was paid for and deployed that no one could use because the application was broken. Double oops.
Phase 5: Beta Test
Once all the Alpha changes are incorporated you hand it back to the client for their final review. This is the spit and polish phase. Last minute text corrections, photo changes, and minor tweaks to functionality. Here is where CSS and standards starts to really show it’s merit. Even if your client wants to make a site wide color change CSS makes this easy. I wouldn’t advertise this as an option to the client, but know that even if they were to ask, you didn’t paint yourself into a corner because CSS is a global appearance changer. Change the style sheet, change the whole site. Why would you ever want to rely on search and destroy tools, when you can use CSS? Once again review your changes, test your site and publish it again to the test server. Do not publish the site without your clients final approval.
Phase 6: Publish
Once your client approves the site you can move it onto the production server. I usually try to write in a long term maintenance item into my contracts, not necessarily to make residual income, but to cover the client in the event that they want to make changes, or tweak the site after they get some feedback from their customers.
The process is simple and methodical. It is designed to mitigate risks and protect you and your clients. If you cut corners someone will end up having to pay for it, and now one will be happy. I hope this Insight will be helpful.