In part one of this blog we discussed predevelopment documents and the value such diligence adds to the overall product. Developing this documentation will improve every aspect of the project, including customer satisfaction, code stability, time management, and overall quality of work. With a clear project direction, developing a technical roadmap becomes a much more possible and manageable task.
The traditional processes and frameworks of building websites differs little from any software development. In both cases, the project needs to be divided first into layers and then into units. These are units of work which need to be built. Units have dependencies upon each other and varying levels of difficulty or complexity. Both of these factors are considered when writing an action plan. The standard of software logical layers is the classic model, view and controller. MVC refers to the data store, interface code and application code. Typically a team would begin at the database layer.
Armed with the pre-development documents discussed above, it is important get the database schema on paper. Getting your design onto paper opens up communication between developers, expresses problematic areas and at the very least adds to a team's growing collection of site documentation. This is a great example of measure twice, cut once. The database schema is literally the brain of the website.
Application code is at the minimum the adaptor sitting on top of the database retrieving from and updating it. Application layer is where business logic gets enforced. Server resource consideration and effectiveness are factors at this layer. Designing this layer is defining the technical architecture of the project. The level of documentation sophistication varies greatly here. There is a coding syntax, called UML, which can be employed to define this layer. In practice, UML is little more than diagramming. Typical diagrams are simply boxes and arrows with brief description of what's happening on those little arrows. An example might be: user clicks order button, check is user, check stock level, verify no holds, add order to queue, update stock, etc. No detail is too small to document. Next, the development team overlay these diagrams with the literal class names or functions required to accomplish the actions laid out.
As this process is continued, the mosaic of the software finally begins to emerge. In a sense, this step is taking the user case flows made earlier and upgrading them to a new level of complexity and relevance. Just as the user case flow allows a team to discover issues with features or usability, this analysis will expose issues in programming that are better dealt with here than later in the thick of coding with the danger of dark side of the moon syndrome. That is to say, once a programmer has gone so far in programming only to discover a problem. They might be tempted to add more code to mask the problem rather than delete existing code. If the same developer has gone into programming mode with a clear strategy, such issues would have all ready been circumvented typically resulting in more concise and effective code.
Even once programming has begun documentation should continue, now in the form of logging. Proper logging is basically making notes. Each time a unit is completed the developer would log a note stating so and any complications encountered. These logs will become invaluable in the final development stages. Project managers can review the logs and check items off their feature list. Reviewing the amount of time each unit required will aid immensely when assessing future project risk. Often, documentation produced at this stage is kept internal to be reused in future projects. However, if the client is large and technical enough, the application design too might be a welcome addition to the overall site documentation.
In any successfully managed project should be an abundance of documentation. Some of these documents will be highly sophisticated polished products unto themselves while others might not be much more than rough notes. Regardless, they are evidence of professional diligence. At each iteration along the way we stated on paper what we intended to do, discussed the strategy with the contributors, and then did exactly what we stated. The secret to creating a quality strategy and unlocking its value is communication.