What exactly is software design? What constitutes as software? When does the design stage start, when does it end? These are all pertinent questions to ask when considering what software design is. How you think about software design is undoubtedly going to affect how you approach software development and ultimately the product produced at the end.
Design is one of those sketchy areas where everybody agrees on the idea but not necessarily the form it comes in. After all, there are plenty of different design and development models around. At some stage or another somebody has questioned the current model to give rise to a new one. One that they think better suits or better encapsulates their understanding of what software design, software development, software testing is and what it can and should or should not be applied to.
The waterfall model for example, restricts design or each phase of work to a concrete stage of the software life cycle model yet prototyping models begin a new design (and consequently new following stages) on each prototype (throw away prototyping).
Having a clear understanding of how you perceive design is a powerful concept that is often overlooked. Why? Many programmers don’t necessarily know why they design something the way they do, they just do it; conditioned over years of performing something the same way possibly. They learn the concepts of object-oriented-design and then apply them to problems often with no rhyme or reason. So you leant that inheritance is important for code re-use and design patterns enforce structure and order. You learnt all the situations they work great in. But did you bother to learn the situations they don’t work so well in? Interfaces are great for object substitution and polymorphic use, but did you really need to have an interface for an area of the system that isn’t likely to change, or couldn’t?
Knowing how and why you look at software design the way you do allows you to be more mindful of when you are making mistakes, or likely to make one.
- Identify your understanding of software design
- Ask yourself, what is good software design?
- Ask yourself, what is bad software design?
- How did you end up at your design decisions?
- Understand your choices
Work out what design means to you and what influences your design choices. Remember this every time you sit down at the drawing board.
What do you believe to be good software design? Maybe you think it’s a design that is simple or light weight. Or maybe it’s something that is flexible; It’ll support a multitude of features in the future with little re-write needed. Maybe it is just something that is consistent, predictable and allows you to solve a problem systematically (software design patterns). None of these are bad things but whatever your choice is, it is going to affect how you design a system. If you think a good design is one that is always minimalistic than you are likely to under-engineer a solution. Fine on small projects, but on something larger you may fall into the trap of avoiding a potentially better (albeit more complex) solution. If you always design with flexibility in mind then chances are you’ve approached simple problems before and automatically applied overly complex designs when the simplest thing would do.
What do you try and avoid most when designing around a problem specification? Change, uncertainty or something else entirely. These are important to look out for because they are nearly always present (there are things you can do to minimise them but I’m not going to cover that here). If you try and avoid change for example than you might automatically opt for simpler designs because you expect the design to not change. Inevitably the client changes their mind, or the specifications change and you’re stuck in a hard place as now your design is forced to deal with change.
Think about what lead you to your design choices. Was it contributing factors from your current project specification? Was it time, budget or resources available? If your project is on a time constraint (nearly all projects are), then maybe your pressed to look for a simpler design. You don’t have time to engineer a larger more robust solution.
In the end understanding your choices is the best thing to do. You often can’t change the time restrictions you have, but knowing you consciously factored that restriction into your design will better prepare your judgment and decisions. If you were to suddenly get more time to complete the project in would you finish the project early and leave your design the way it is, or would you then re-evaluate your choices? Understanding how and why you do anything is the primary method for improvement.