I’ve hopefully painted a picture In my prior two blogs that software development is more than just “code and ship.” There is background work required to staff a given software project, and requirements must be clearly articulated and understood by those who will be writing and testing the software before any actual coding can begin. Now that we’ve gotten this far, is it time to code?
We’re close, but not yet! There is this little thing called “design.”
A couple of blogs ago, I listed some always-present project goals:
1. Deliver well-considered, fully-functional features that delight our customers.
2. Deliver against the shortest possible schedule.
3. Keep defects to an absolute minimum, with no critical defects by ship date.
4. Deliver software that will be maintainable into the foreseeable future.
5. Stay flexible during “project x” in case we need to move people around to meet other needs or shift feature priorities mid-stream.
For the purposes of this discussion, we’re concerned about the ones in bold.
“Deliver well-considered, fully-functional features that delight our customers” is one major challenge in and of itself! This covers two main areas: a) the user interface that will be used to interact with the software and, b) the underlying business rules to operate on the data, ultimately storing that data for future use.
I won’t go into the gory details here, but good software design separates software in various layers, typically keeping a very distinct separation between the user interface, business logic, and data storage/access. A major benefit of this approach speaks to item #4 above – maintainable software. Code related to providing a really cool user experience is kept separate from code that implements specific business functionality, keeping everything in nice, neat compartments.
If this wasn’t done and changes needed to be made in the future, someone would have to shift through all the areas of code to determine where a particular business rule was located or to find out just where in the world the database was being updated – and the larger the lines of code, the more excruciating the exercise! In addition, code that is not compartmentalized is what is referred to as spaghetti code; code that is so intertwined it is extremely difficult work on. It is both difficult to assess the impact of any change, and even harder to make a change without breaking something else.
The net result in compartmentalizing software is a code base that can be revised more efficiently and effectively over time. The full spectrum of an application – from the user interface to business process to data storage – is covered in the design phase of a project.
Software design for applications that are geared towards the business world takes more than an understanding of the business problem. Solving increasingly complex business problems drives development teams towards new technologies, often times because there is something available to leverage. So how do teams that aren’t domain experts in the problems that they are solving, who are also working with ever-changing technology, reduce risk to a project while ensuring that they meet increasingly complex business needs? In a word: Prototyping.
Prototyping is a great tool for working the kinks out. User interface prototyping helps teams interact with business users to work out the details of how information will be presented and how users will manipulate the data and drive the underlying business processing. One low-cost – but still very effective – method of user interface prototyping is the “paper prototype.”
Paper prototyping is just what it sounds like; the screens are drawn out on paper, with notes to provide an understanding of the visual elements being represented. Paper prototypes are great, as they provide the necessary visual ingredient that business users need and help to finalize the requirements. I’ve seen plenty of projects where users, now that they can see how the business problem is being met, request changes – either because the team got the details wrong or because it was difficult for the business users to visualize the system while the requirements were being written down.
Believe me; given a choice, I’d prefer to make changes on paper! This is far easier and less costly than later, after software has been written and tested. The same goes for another type of prototyping, software prototypes.
Software prototypes are test applications used to construct a model of the end system, typically with only a subset of the features of the target system. The goals of a software prototype are to experiment and learn. Why? Because technology is tricky, and small-scale prototypes help developers understand both the benefits and limitations of new technologies so that this understanding can be incorporated into the final design. Without this experimentation, assumptions will be made, which impose an additional risk to the project. While this is coding in a literal sense, it should be viewed as experimental, and not code that is in final form for use in a production system.
One final component – in place at AMS Services since we’ve adopted the Agile development model – is the creation of validations. Validations are the test cases that will be used to confirm that the software does what the user expects it to do. An Agile team works collaboratively with the customer team (business users) to write the validations. These validations become the measure of whether the software is doing what it is supposed to do, without room for interpretation.
Are we ready to code yet? A staffed team, armed with an understanding of the requirements, prototypes to confirm the requirements and to answer any technological concerns, with a design in place and validations written, is finally ready to code. Next time, I’ll cover actual coding.