Effective Software design

Effective Software design
It’s not about principles, techniques or patterns.
Being effective means that you are successful in producing a desired or intended result.
- It means doing something that brings you closer to an intended goal.
- This implies that when you have done something with a certain outcome in mind, you should also be able to assess if you are any closer to that desired outcome.
This implies that when you have done something with a certain outcome in mind, you should also be able to assess if you are any closer to that desired outcome.
many developers just don’t know
- They saw an opportunity for the pattern or design
- But did they really improve the code? Does the change have any impact on the desired outcome? Who knows.
- Did they think why it should be used, and evaluate if it was needed

What do you need to be effective?

you need to know what software design is and what you want to get from it
software design is a process.
- it is an ongoing process
- you continuously look for ways to structure the code solution in such a way that the future maintenance costs are kept as low as possible.
- by enabling change in the solution and you do this every single time you have to touch the code.
software design is a toolbox of best practices, patterns and techniques which can be used to enable change in code
is to understand.
- understanding of the most basic concepts in software design.
- understand what it means to ‘enable change’.
  - any developer can relatively quickly find where change needs to happen in the code base
  - the changes have a low chance of breaking the code or creating unwanted side effects
    (for instance introducing bugs or the ripple effect where one change in the code ripples throughout the code base).
  - change is isolated as much as possible. We should be able to predict which code parts need changing.
    Because each module has a particular role,
    a particular function
    because these modules are isolated (as far as they can be totally isolated)
    change will not spread uncontrollably
  - t will still cost a lot to maintain the code or the application.
    Because change will still spread.
    It will because you cannot have software modules that are completely isolated
- with every change you have to do, you need to make design decisions again and see if the result will still enable change while fulfilling the needs of the stakeholders.
- there is no best way to structure your code
  - depends on the domain you are working in and the stakeholders that are interested in the solution
  - depends on the current technology available

Context

Context defines your design
Depending on context, your design will be different
Changes in context, will change design
Context includes
- people (level, exp, knowledge, numbers)
- tech (availability)
- deadlines
- economic/money
- features
The context you are working in is formed by the domain you are working in and what your stakeholders need and how they want it.
- Your design should first of all meet the needs of the stakeholders
- what stakeholders want or need is going to collide with your goal of enabling change.
  - where the needs of stakeholders and the goal of enabling change cross each other, that is where trade offs are born.
- Problem with coders
  - Believe that software designs principles, techniques and patterns are fundamental truths or dogma’s that need to be obied.
    It's not they are tools, and need to know when to use for the benefit of the stakeholder
  - Rather than it is the product produced that is the most important, what the users/stakeholders want
Software design it’s more what you’d call guidelines than actual rules

Change

change will always happen, if you can handle change then you will be left behind
The main aim of software design is to enable to change, to make change easier
- Has a cost - takes time, is hard to do, adds complexity
- Trade off against other important design (ie maintainability, readability, performance etc)
We need to understand what the reasons are for change or where change is coming from.
- Otherwise, we won't know what form the change will take
- which leads to how to design or implement this
Problem with change, we dont know what will change, we cannot predict the future
- We can only have an educated guess (based on prior experience, statistics)
- Only certainty is change will happen
- If we design for the wrong change, can lead to wasted time, and hard to change places that really needed the change
- The use of the scientific method is integral in software design
  - Allows to get fast feedback from experiments, to find out what is important, what does change often or slowly
Where change comes from
- Stakeholders (majority of times) - new features, remove features, fixing bugs
- regulation/security - regulations, laws, software updates, certificates
- internal - merging with recently acquired software bases, using newly procured services, top down initiatives

Complexity

Has two sides
- the complexity of your solution
- the complexity of the problem for which you are making a solution
  - Not talked about much
  - includes:
    The complexity of the domain
    the complexity of the stakeholders
    More of them and especially if they have competing agendas, will lead to different variations
in our interest to keep the code solution simple, because we want to enable change.

Evolution

due to constant change (the world, the tech, the people/stakeholders etc)
This translates into more different needs and more possible variations.
- And your job is to build software that can still enable change with all of this in mind
everything evolves and the complexity of the application evolves along.
- Evolution changes the context you work in.
So what seemed important in your design last year might possibly no longer be important and vice versa
Your design must be able to handle constant change in an evolutionary style
- instead of doing a redesign (which has a lot of cost to it)

Guide

There is no silver bullet, not dependent on techniques, patterns etc
- These things are irrelavent and waste time discussing
Follow this:
- You need to understand what software design is and what we want to accomplish with it. Understand what the goal is and also what it concretely means.
- You need to understand context, to acknowledge it, recognize it and of course understand it. It is only by understanding the current context that you are able to make decent trade offs
- You need to understand where change is coming from
- You need to understand complexity and take it into account.
- You need to understand the evolution of the context we work in.
AND START APPLYING IT

What do you need to be effective?

Context

Change

Complexity

Evolution

Guide

Links