In order to define what is considered “good” design, I chose to replicate the in-class exercise. In order to understand what might be considered good design I will try to answer this question.
What is bad design?
This question stumped me for awhile as I keep running into circumstances where a “bad” design could be valued aesthetically or functionally. Next, I tried to search for what other people considered “good” design. I felt that this was important because while I may not agree nor come to the same conclusions other theorist’s definitions of “good” design could reveal new avenues of thought. The Good Design Awards offer an interesting but unfortunately limited outlook of good design. Its copy hints at an underlying aspect of valued design. “Good” design and profitability seem to go hand-in-hand. On the other hand, I appreciate Ian Sommerville’s outline of “good” code design.
- Maintainability
- Dependability
- Efficiency
- Usability
His definition of good code structure relies on each term’s malleability and simplicity. This allows him to describe in depth the requirements while not weighing a coder down with convoluted rules.
Throughout my search to understand the quality and values of design I found that these terms lacked nuance and vital information regarding a designs nature. Despite our prolific use of “good” and “bad” to characterize design, I believe there is no such thing. Bad design is the result of inadequately compiled design concepts while good design successfully merges both concept and components. This idea answers both “What is bad design?” and “What is good design” simultaneously. If we sequester ourselves within the realm of “good” and “bad” we rob ourselves of valuable insight a “bad” design might provide or the limitations a “good” design have. It can be recognized that any definition or design rule set can be mutually contradictory therefore, why not employ different (possibly better) modes of characterization?
def main():
try:
print('Hello World')
except:
print('Error')
main()
This block of code meets all of Sommerville’s requirement. It’s structure within the function allows it to be maintained and easily accessible (able to be called easily). The try and except format gives it a high level of dependability due to the user being able to know when things go right and when things go wrong. The only element that it may lack is efficiency. Its simple task does not require an entire function nor does it really need to prepare for the possibility of error. However, these aspects of the code highlight a larger idea within the concept of design. All five requirements are rarely achieved to their fullest degree. Good design requires trade-offs above all else.