Computer Science for the Web
The discipline of Computer Science is often considered distinct from web development. However, in order to develop high-quality web solutions, good coding standards and requirements gathering is vital. Applying the principles of Computer Science can sometimes become tricky, my hope with this series of blog posts is to map some of these standards directly to the domain of the web.
The building blocks of the internet -- everything from network protocols, markup language interpretation and transformation to search algorithms -- are fundamental topics of computer science. However, when it comes to building 'web applications' some software engineers and computer scientists balk, thinking web development is 'below them' - insinuating that it’s something different than 'real programming.' By the same token, many web developers tend to skip the fundamentals of computer science - claiming that they don't apply to this 'new' realm of programming, often clinging to a mantra of art over science. Both of these extremes are misguided and detrimental.
Let’s apply some of the often-forgotten computer science concepts to web development.
The main three concepts I would like to discuss are: Traceability, Testability
and Repeatability. In today’s blog I will address Traceability. The remaining topics I want to discuss in separate blog posts.
Traceability
A basic definition of and introduction to Traceability can be found at http://en.wikipedia.org/wiki/Requirements_Traceability. The basic idea of Traceability is the existence of a change log for individual requirements that allows the tracing of each from its initial creation through the implementation and testing and finally to the delivery of the functionality described.
A common pitfall in requirements gathering is the attempt to capture requirements in an unnecessarily detailed and often un-usable manner, resulting in the creation of 'waterfall'-style, 500-page books that no one understands and few ever read. Each requirement can be a simple bullet point or sentence describing the 'problem' or user-required functionality - for example 'User will add a list of related content links to each node'. Overly complicated requirements benefit no one.
Requirements for the web apps change quickly, perhaps even more quickly than those for another platform. The web is tied very closely with the View aspect in the Model View Controller pattern. Many sites are mostly for the display of information as opposed to the processing or transformation of information. Due to strong coupling of requirements and design, each requirement has a direct impact on every level of design and development. Tracking changes to each requirement allows for more efficient iterative design and development process. Development can begin while the requirements are still in flux, and as the requirements change - each incremental change can be sent to the developer/designer and implemented. This approach eliminates several rounds of comparison and helps reduce amount of thrown-away code and time in general.
As a project moves through different phases, the requirements traceability can sometimes be lost. This can become a major issue if development begins early in the process. Large portions of development and design work can occur and then have to be redone as the requirements change. With traceable requirements, each distinct change can be easily communicated between a team and implemented as soon as it occurs. Each requirement may also affect other facets of the project - from customer expectations to graphical asset development. Having reference points for changes makes communicating with 3rd parties, including the client, much more efficient and productive.
TL:DR Summary:
Writing and changing requirements in a traceable fashion can decrease duplicated and unnecessary work while increasing customer satisfaction. The process can become rigorous and may seem unnecessary at times - but when working with a team on a quickly changing set of requirements - traceability is essential to good communication and, ultimately, successful projects.
I hope to post next week discussing Testability of requirements.
Comments
Someone needed to say it
Thanks for writing this, Josh. It confirms my thoughts and makes me feel a little better knowing someone else out there shares my view of this.
Our lead developer at Factory Interactive is someone I often refer to as a "real programmer" because he's got a computer science degree and has been programming in low level languages most of his 15 year career. He's not a designer-turned-developer. He applies his learning and deep experience to tackling development problems on every project we do. I have yet to see him fail in finding a solution to problems.
I often wonder if he's bored by working with web technologies, largely because of I suspect he thinks it's all beneath him. But given that so much computing is done on the internet now, there's as much or more need for computer science fundamentals on the web as anywhere else in systems engineering.
Good post.
Follow Up
There have been several questions about the follow up blogs. I am hoping to have it done and posted by friday afternoon.
Post new comment