With every software development effort comes the question on how much time and budget to spend (or invest) in the solution design phase. It is always a battle between reducing design time to get started with real coding and producing something that the client can see and measure (spending) to how much of a system you will have in terms of keeping up with unexpected requirements and stay current with business changes.
So let’s take a look at the characteristics of a great design and see if we can make an assessment on importance and value.
Cope With Changes
It is often the case that a project progress does not go as planned and that is mainly because changes happen to ideas as a team progresses with implementation. New ideas are born and others are dropped as business requirements meet the new systems. A good design will have the ability to break down complex tasks into smaller reusable building blocks, one that can distill common units of functionality and combine them together to make complex units of processing. Easier said than done, but at the heart of it is a flexible service style core that allows reusability and easy constructions of these processing units. To cope with changes a system needs to be flexible in its design so if you like, new units can be plugged in, and old ones can be removed. Each time there is a change in the requirements, the system core stays as is, but the assembly of the smaller building blocks is changed. If you look at it more as a framework than a system you start to realize the design is allowing the maximum room for maneuvers within the core system walls. A great design will have a framework in mind on the outset and a detailed implementation from the inside, building capabilities to fit any future usage.
Reducing Maintenance Costs
One of the benefits of a good design is the ease of maintenance. Your code base supports good coding standards and therefore better testability (the ability to test the code on each and every level), maintaining the code becomes routine, and testing it becomes standard practice. Each change in requirements is followed by improvement to the code base and the tests to prove it is still working as expected (automated tests like unit test, acceptance testing, etc). Lets imagine the other option, a poor design is hard to maintain, each change adds complexity and breaks the mold, therefore it introduces a lot of specialized code that is good for just one process exception, it also means it is hard to test it, because each exception has something different about it so it requires a change in the test strategy or even become untestable all together. Bad designed systems do not follow best practices and don’t have testing in mind, it can become difficult to test them properly and therefore may require more man power to manually (cannot rely on automated tests) test them on each and every change.
Bad designs are complex and alot of internal assumptions are made that are never documented. The people that design these systems have a powerful position, as vital information is held inside their heads. They are essentially securing their position or role, as a company would be reluctant to let any of these resources walk out the door as this can damage project progress and even set a project back for some time until development can be resumed and get back on track. A great design is well structured that even without documentation any developer can follow, enhance and extend. A good design is easy to document and share (as an idea) inside a team and organization. Any loss of a resource can be easily filled and the progress past maintained.
The SDK challenge (Software Development Kit)
Many systems promote an SDK options that allow customers to create their own extensions and customization to the core system. This is a great place to be as complex process exceptions are unique to each customer and not shared inside the core product. Great design allows adding and removing functionalities as the customer base grows and there are more varied demands for functionalities. If your system is well designed, creating an SDK will not be a great effort, thinking about this feature ahead of time will dictate a lot of the way the system is designed, thinking about it too late and it will require a huge refactoring effort on changing the core product design, sometimes in expense of making another bad design decisions (hacks).
As you can see, good design is not only critical for the system or program that is being developed but it can have an impact on project timelines, customer experience and project and maintenance costs.
What do you see as key to good design?