Argument from Design: Our Use of Technology
Experience: Integration & Deployment
Not only do we create enterprise-level web applications, we’ve integrated our web applications with our client’s existing software, both on their server & their network of office computers. We also deploy our apps to a wide range of server configurations from locked-down shared hosts to dedicated servers.
The Traditional Blueprint Model
Traditionally, the development of a computer application involves:
- producing a specification of the application; then,
- building the application so that it conforms to the specification.
Usually a lot of time is spent on getting the specification just right. We could call this model the “blueprint model”—it’s similar to the process you would use when constructing a building. The consequences of the “blueprint” are carefully thought through, so that the final application will solve the problem for which it was designed.
The Big Problem with the Blueprint Model
This model works well when there’s a well-defined problem that the application is to solve, and when the application’s lifetime is expected to be long—a good example is a financial transaction application for a bank.
However, when changes to the application are needed, the spec is consulted (often used to beat clients over the head) and departures from it are costly. This is due, in part, to the fact that anything outside of the spec is going to have unforeseen consequences—the larger the application the greater the consequences. In short: it’s a gigantic problem to change a large application—much in the same way that it’s quite a gigantic problem to change a large building.
Why the Blueprint Model Doesn’t Work for Web Applications
Argument from Design believe that web applications require a different model. Web applications typically change a lot, for two reasons:
- the web is new and the possibilities afforded by it are not yet fully known; and,
- the technology that drives the web is subject to very fast change.
This means that both of the reasons that make the blueprint model attractive are not present. That is, we often don’t have a completely well-defined problem that the application is trying to solve, and the application’s lifetime is much smaller. Therefore, using the blueprint model for web applications is often a wasteful and costly exercise—and one that frustrates both clients and developers.
A good thing about the blueprint model is that there is a set of clear outcomes. The bad thing about the blueprint model is that it encourages a certain sort of thinking and application design that makes changing the application hard.
Agile Development
We keep what is good about the blueprint model. Where we differ is that we assume, from the start, that the application could change. Therefore, the specification becomes more of a living entity, which records the behaviour that the application is to exhibit. If changes are required, we add these to the spec.
However, those unintended consequences are still going to be there—how do we ensure that adding the the spec will not cause the application to break in unexpected ways?
Test-Driven Design
The solution is Test-Driven Design. For every item in your specification we write a series of tests that prove that the application exhibits that feature. Also, whenever we write new code, we run all the tests. This gives us a rock-solid assurance that any changes to the application won’t cause breakage in unexpected ways.