Argument from Design: Our Use of Technology

Not only do we create enterprise-level web applications, we’ve integrated them with our client’s existing software, both on their server & their network of office computers. We also deploy our web applications to a wide range of server configurations, from locked-down shared hosts to dedicated servers.

So whether you’re looking for tight integration or your own server (or both!), rest assured we’ve been there & done that.

Traditionally, the development of a computer application involves producing a specification of the application & then building the application so that it conforms to it. This is the “blueprint model” because it’s similar to the process you would use when constructing a building.

Usually a lot of time is spent on getting the spec just right. All sorts of consequences are carefully thought through in the blueprint so that the final application will solve the problem for which it was designed.

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, this comes at a cost. When changes to the application are needed, the spec is consulted and departures from it are costly. In part this is because 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.

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.

So the reasons that make the blueprint model attractive are not present here! 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. It encourages a type of thinking and design that creates barriers to evolving the application.

So how do we escape this predicament?

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 spec 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. This is Agile Development. As the application grows, so does the spec, because they’re intimately tied together.

Those unintended consequences are still going to be there, however. How do we ensure that adding the the spec will not cause the application to break in unexpected ways?

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. And when we write new code, we run all the tests.

The effect of this approach is that we’ll know immediately if the new code breaks the old & if it has, where. This gives us a rock-solid assurance that any changes to the application won’t cause breakage in unexpected ways.

Together, then, the evolving specs of Agile Development and the constantly running tests of Test-Driven Design form a revolutionary way to develop web applications. We more closely mirror what you do & how you do it—and you can be assured that it’ll work, even when you want to add new features to your site.