Getting ready

We know about the issues we'd like to address and how we're going to learn to do so. So, now let's look at some of the non-architectural aspects of an application that you might want to think about even before starting to put pen to paper on the design. While everything we've discussed so far talks about the overarching method to shape the development of an application, the other parts of the puzzle can often be just as important.

The specification

How do you design an application without knowing what it is you're designing? This is what a specification provides. A document or series of documents that describe in exacting detail how the features that make up your software should behave. It's a continuing mistake in the software business that we don't collect the requirements of our users and clients before we start writing code. In the same way that it's irresponsible to build an application without architecting it correctly, it's irresponsible to build an application without being as certain as possible that you're creating the correct thing for a paying customer. What sort of issues can a specification avoid? Some of them are as follows:

• Missed deadlines
• Cost overruns
• Developer stress
• Customer dissatisfaction

This reads as a fairly generic list of things we don't want during our project.

More importantly for the purposes of this book, a specification allows you to have all of the information needed to create your application design. It doesn't necessarily mean our design will be right, but without a specification, you can guarantee the design will be wrong.

A good match

Part of creating both a specification and a design is understanding the customer requirements; understanding the "problem domain" that represents their business. It's really hard to write a piece of computer software for a shipping business unless you understand at least a little bit about shipping, for example the way they calculate rates in relation to cargo weight and the distance it's travelling.

In regard to Ext JS, we may be working with an external SOAP API that provides these shipping rates. Well, Ext JS supports working with SOAP (with a Sencha Complete license), but if it didn't, this would probably affect our design—we'd have to write more code to talk to the SOAP API—and therefore our timings.

We're writing a content management system, but it needs to be very closely tied with the customer's branding due to agreements with third parties. Will the Ext JS theming system allow us to incorporate the extensive customization needed for the project?

We started working on a sales portal for a new client when the Finance Director reveals that all his work outside the office is done on an iPad mini. We now have to work backwards to incorporate touchscreen support. If we'd have consulted all of the stakeholders at the right time, we'd have saved weeks of work.

These examples are somewhat contrived, but serve to highlight that application design is not only about software, but also a fusion of consulting the people involved, evaluating your resources, understanding the problem domain, and creating a software architecture. These requirements don't exist in isolation.

How we work

Consider bringing a new developer or tester in your team. How quickly can they get up and running with the latest build of your code? How can they track down the code change that resulted in a bug they're working on and then find the developer responsible for the bug? Is there a particular way in which automated tests should be created and new code should be written?

These are all highly important questions when creating a successful application because they reduce the barrier between creating and improving the existing code base and keeping the quality of the resulting code high. Joel Spolsky, of Microsoft and Fog Creek fame, wrote a blog article back in 2000 that is still highly relevant today. Titled The Joel Test: 12 Steps to Better Code, it asked twelve questions of development houses based on Joel's extensive experience working with a variety of coding teams and projects (from Microsoft Excel to Fog Creek's own Trello). The whole article's well worth a read, but we're going to take a fresh look at it with regards to Ext JS development.