Why do we design in the first place?

A question before almost anything.

“WHY?” I love asking “why” about almost anything because its answer always reveals the intent behind the subject and what problem we are really trying to solve. this provides a deeper understanding of the nature of the subject and lays foundation of thinking on my own and maybe finding new or better ways of resolution.

The question “Why?” here sometimes manifests in other forms like “Does it worth the trouble?” or “why should i learn all this design stuff?” or “why don’t we just code it”.

While most software engineers know it’s important to do design but it’s justified also considered healthy to do this cost benefit analysis before doing effort, specially significant ones like software design.

“Why do we need software design?” It’s a simple question but not as easy to answer, to answer this question a some thinking and knowledge needs to be in place first.

The nature of software development

back to the basics, we need some solid facts to base our case on, and what is better than science!

laws of software evolution

laws of software evolution refer to a series of laws that Lehman and Belady formulated starting in 1974.

To put it in simple terms:

• software will change or it becomes dissatisfactory unless effort is done to control the change.
• software complexity will increase unless effort is done to reduce it.
• adding more human resources at a software project will not change the speed of delivery.
• all associated personnels (developer in our case) must maintain mastery of the system under development or they get overwhelmed.
• A software system will continue to grow.
• the quality of the system will appear to be declining unless it is rigorously adapted to environment changes.

Check Lehman’s laws of software evolution For further reading.

Economics

software projects fail, and when they do that’s due to process, team structure, skill level or maybe bad system design.

A bad software design can cripple development to the extent that adding a single feature can be very painful that it can take months of development.

Martin Fowler has a great article “Design Stamina Hypothesis” on this exact subject.

As you can notice the main theme here is that entropy in a software systems is very costly and dangerous and entropy will make its way to your system unless effort is done to prevent it, therefore “system maintainability is most vital quality of your system” or in other words “Entropy Is The Enemy!”.

Once you reach this realization your approaches towards development will change, you no longer want just to write code to deliver a feature, but more you are writing code that others can expect and easily understand, you are developing for sustainability not just for delivery!

How does software design help?

To answer this question we first need to know what design is.

What is software design?

The word design is used to refer to the cognitive activities of setting a plan and maybe executing this plan.

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. — wikipedia

To simplify the definition a bit more, software design is the process planning how to develop a software within a set of constraints like (language, architecture, libraries …etc).

And If “Entropy Is The Enemy!” and design is planning, then one of the main software design goals is the planning of how to fight entropy in software.

What constitutes a good design?

according to our findings so far a good design might constitute many things but one of the main goals of a good design is that it’s maintainable.

Tl;dr

Maintainability is one of the major concerns for most software design principles, patterns and best practices.

SOLID principles

• S: Single-responsibility Principle
• O: Open-closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

All are aimed to developing a maintainable system, one that can be managed for as little entropy as possible!

Design patterns

having a PATTERN (almost universally known in the realm of OOP) makes it easier for everyone to quickly understand therefore easier to maintain it.

DRY

Don’t repeat yourself, aims at code reusability to have single point of change for each functionality your system provides to reduce the effort you are doing to maintain your system in the future.

YAGNI

You Aren’t Going To Need It, aims to not introduce any new code unless necessary to your system as you will have to maintain it too.

KISS

Keep It Simple, Stupid, which means that unnecessary complexity should be avoided (because it will make it harder for other to understand the system therefore to maintain it).

Boy scout rule

“Always leave the campground cleaner than you found it” and by cleaner here means generally easier for other to understand the system and work with it.

Conclusion

Entropy is very costly and dangerous to a software system and it will make its way to your system unless effort is done to prevent it.

to protect your system against entropy you need to plan how to construct it, therefore one of the most important aspects of Software Design is planning against entropy and complexity, therefore you are a good designer if your design is easier to understand and maintain.

further writing on the following topics are in progress follow me to get them when they are out:

• how much design is good?
• what is considered a justification for a certain design?