Imagine a tree growing in your garden; visualise the branches of the tree, the way they grow in many different directions. Consider the height of the tree and how it looks silhouetted against the clouds. Now imagine building a tree house in that tree. In your mind, your tree suddenly has branches that are thick enough to support the house; it has a branch that forks out of the trunk where you can conveniently place it and the tree is tall enough for the house to need a rope ladder. Lucky for your tree house project, your tree was constructed in your mind and it could undergo significant, easy change in order for the project to proceed.
In the real world it’s not that simple. Things need to be planned. You can’t build a tree house in any tree.
Now imagine that the tree house is a new requirement in an application and the tree is the original piece of software. If the tree wasn’t ‘designed’ for a tree house, then you’ve got a problem on your hands. There are many ‘tree houses’ that have been built in pine trees; supported only by gum poles and rope. So, what’s the point? Systems that have grown organically out of a single requirement often fail due to the original system not being built for the task it has to now execute.
A Good Design is Important.
There are many aspects to software design and many varying methodologies. My intention is not to discuss the pros and cons of these varying methods or to recommend a specific one. It is just to emphasise the important part of design is not which methodology you choose; just that you choose one.
You might be surprised to find that a great many applications start their life has a collection of "hacks". By hacks, I mean pieces of code that have been forced to work together using creative methods and techniques. Interestingly, the developers who write the code are usually not bad programmers; on the contrary, they are normally exceptionally talented. The problem is, without adequate planning, decisions made at the beginning of the project often have unforeseen consequences. These can include an unwieldy UI, poor performance, over-sized data files, overly complex processing and un-maintainable code.
An answer to these unforeseen consequences is, as you may have guessed, to create a good design. A good design needs to take all the facets of the system into consideration; these facets include (but are not limited to)
- User Requirements
- Information and Process Flows
- User Interface prototypes
- Internal Data Structures
- External Data Dependencies
- Location of the user and the delivery method
Why then do many developers only look at a small part of the design process (if at all)? Most of the time, they are of the belief that they will be able to deliver the application faster without going through the design phase.
The problem is that they are right; well at least for the first few phases of the project. Most good programmers can create a basic system without spending much time thinking about it holistically. The easily understood requirements can be put together in a relatively short amount of time and non-technical stakeholders will perceive that the project is progressing well. The problems start as the application grows. Assumptions that were made in ignorance at the beginning of the project hamper progress, and workarounds are put in place. Later in the project, these workarounds further hamper progress. It is a downward spiral into the abyss of an un-maintainable system. The old adage that the first 80% of the system takes 20% of the time to complete and the last 20% of the system takes 80% of the time to complete applies.
So just remember, it’s easy to build a pine tree; but almost impossible to put a tree house in a pine tree.
No comments:
Post a Comment