Takeaways on Responsive Design
Join the DZone community and get the full member experience.
Join For FreeI recently have attended a great talk from from Kent Beck who is the
thought leader in Extreme Programming, Test-Driven-Development and Code
refactoring. This talk "Responsive Design" outline a set of key
principles of how to create a design that is "malleable" so it can
respond quickly to future changes.
Anticipating Changes
I
don't think one can design a system without knowing the context of the
problem. You have to know what problem your solution is trying to
solve. Of course, you may not know the detail of every aspects, or you
may know that certain parts of the requirements may undergoing some
drastic changes. In these areas where changes are anticipated, you need
to build in more flexibilities into your design.
In my opinion,
knowing what you know well and what you don't know is important. Good
designers usually have good instinct in sensing between the "known" and
"unknown" and adjust the flexibility of his design along the way as
more information is gathered.
As more information is gathered,
the dynamics of "change anticipation" also evolves. Certain parts of
your system has reduced its anticipated changes due to less unknowns so
now you can trade off some flexibility for efficiency or simplicity. On
the other hand, you may discover that certain parts of the system has
increased its anticipated changes and so even more flexibility is
needed.
Safe Steps
If
the system is already in production, making changes in the architecture
is harder because there are other systems that may already depend on
it. And any changes on it may break those other systems. "Safe Steps"
is about how we can design the changes to existing system with minimal
impact to those other systems that depends on it.
Design for Evolution
One
important aspect when design a system is not just by looking at what
the end result should be, but also look at what the evolution path of
the system should look like. The key idea is that a time dimension is
introduced here and the overall cost and risk should be summed along
the time dimension.
In other words, it is not about whether you
have designed a solution that finally meet the business requirement.
What is important is how your solution bring value to the business as
it evolves over time. A good design is a live animal that can breath
and evolve together with your business.
Kent also talk about 4 key design approaches under different conditions
1. Leap
"Leap"
is a brave approach where you go ahead to design and implement the new
system. When complete, swap out the existing components with the new
one. This approach requires a very good understanding of the
functionality of system you want to build, how the existing system and
how other systems depends on the existing system.
"Leap" can be
a very effective approach if the system is very self-contained with
clearly defined responsibilities. But in general, this approach is
somewhat high-risk and is an exception rather than a norm for large
enterprise applications.
2. Parallel
"Parallel"
takes a "wrap and replace" approach. The new system is designed to run
in parallel with existing system so that migration can be conducted
gradually in a risk-containing manner. If there is any problem happens
during the migration, the whole system can be switched back to the
original system immediately so the risk is contained.
After 100%
client has been migrated to the new system for some period of time, the
old system can be shutdown without even the clients notice it.
"Parallel"
approach still requires you to have a clear understanding of what you
want to build. But it relax you from knowing the dependencies of
existing system. Of course, the design may be more complicated because
it needs to run in parallel with the existing system and has to deal
with things like data consistency and synchronization issues.
"Parallel" is a predominant approach that I've seen people used in reality.
3. Stepping Stone
"Stepping
Stone" is very useful when you don't exactly know your destination, but
you know that there are some intermediate steps that you have to do. In
this approach, the designer focus in those intermediate steps that will
lead to the final destination.
"Stepping Stone" requires the
designer to have a "scope of variability" in mind about the final
solution and then identify some common ground across the perceived
variability. Knowing what you don't know is important to define the
"stepping stone".
This approach is also very useful to design
the evolution path of the system. Since you need to look at how the
"stepping stone" will provide value to the existing systems while it
evolves.
4. Simplification
"Simplification"
is the about how you can simplify your intermediate design by breaking
down the requirement into multiple phases. I personally don't think the
designer has the flexibility to change the ultimate requirement but she
definitely can break down the ultimate requirement into multiple phases
so she can control the evolution path of her design. In other words, by
simplifying the requirement in each phase, she can pick the challenges
that she want to tackle in different phases.
"Simplification" is
also an important skill for experienced designers. The only way to
tackle any complex system beyond a human's brain power is to break the
original complexity down into simpler systems and tackle them in
incremental steps.
"Simplication" is also an important
abstraction skills where experience designer can generalize a specific
problem case into a generic problem pattern where a generic solution
can be found (e.g. design pattern), and then customize a specific
solution from the design pattern.
Opinions expressed by DZone contributors are their own.
Comments