Techniques for balancing design and development planning
As engineers, we divide our work between designing solutions and building them. In this post, I'll focus on deciding how much time and effort should go into design work that happens before any execution (coding).
Iterative Design Process
I'm a big believer in the "Iterative Design Process" which means instead of working in distinctive stages, one after another, you advance in tiny adjustments to the design as you identify challenges, get feedback, or come up with innovative new ideas.
But here comes the question, how would the team know it's time for prototyping?
Albert Einstein
So how do you determine the amount of time that will go into design? Will it be 10%, maybe 90% (like our dear Albert)?
When using agile methodology, this becomes a critical decision for software architects. Should you start iterating or wait for a complete solution?
The knowns and unknowns framework
Donald Rumsfeld
In this framework, there are four levels of knowledge. These levels can help us measure how close we are to finishing our design and moving to implementation.
- Known knowns : Things you're aware of and understand Example: Developing SAML Single Sign-on
- Known unknowns : Things you're aware of but don't understand Example: Integrating the SAML Single Sign-on with the exiting authentication flow
- Unknown knowns : Things you're not aware of but understand Example: Additional requirement of Two-factor authentication (that you know how to develop)
- Unknown unknowns : Things you're neither cognizant of nor understand Example: There is a security bug in the Single Sign-on library you are familiar with and planning on using
We can work a lot on the first two levels in our upfront design. The last two will require implementation work, which can be the real deal or a PoC.
Heuristics
A heuristic, or heuristic technique, is any approach to problem solving or self-discovery that employs a practical method that is not guaranteed to be optimal, perfect, or rational, but is nevertheless sufficient for reaching an immediate, short-term goal or approximation. — https://en.wikipedia.org/wiki/Heuristic
We will start by defining our cost function :
How much time spent + level of risk.
Let's go over the desired expectation. We want a strategy that will allow us to decide when to stop designing and start implementation while optimizing the cost function.
Heuristic #1: There are enough "Known knowns."
Do you have minimal knowledge to bring value?
Your project might be massive; therefore, there are many requirements, and it might be that some of them can be delivered without the others. In the "Iterative Design Process," we want to get back feedback as fast as possible. That's why, if you have something you can ship with low risk, do it.
We want to balance the business value and the design maturity.
Pay attention to the level of risk. While you do want to iterate, you do not want to break the core components of your system.
Heuristic #2: There are no more "Known unknowns."
Did you solve all your "open points"?
It's very recommended to start any project with some risk assessment. During the evaluation, the team should surface up any open points. It could be a module you didn't touch for a long time or a new technology required for the project.
A good heuristic that it's time to move on is when you have got one or more solutions for each one of your open point points.
Heuristic #3: There are too many "Known unknowns."
You can't focus as you have too many "open points."
There are so many open points you don't know where to start. This might be a good indication that you need more info. A prototype can focus your efforts. You will probably need to return to the design table again, but this time with much more information (and fewer open points).
Heuristic #4: You stop learning new things
Do you keep discussing the same open point over and over?
So you did find solutions for all your "open points," but you can't decide on one particular point. There are multiple solutions, but the team keeps arguing which one is the best. You have a few discussions, but nothing sticks. It's time to code.
If the risk is reasonable, you might consider starting with one of the solutions and having a close follow-up. If the risk is higher, you can consider starting with multiple solutions and evaluating them iteratively.
Heuristic #5: F_alling_ down the rabbit hole
Things start getting too complicated and abstract
Yes, we are here to solve complex problems, and yes, some solutions require some pretty deep thinking but try asking yourself, Does my project need that level of complexity?
Engineers love solving problems. That's why we often invent new ones (Imaginary Problems Are the Root of Bad Software). If you notice the design starts questioning areas that are hardly related to your goal, it's time for a PoC or prototype to keep your feet on the ground.
Final words
Remember that these are heuristics; hence they do not provide 100% accurate decisions. Your role is to use them wisely as a kick-starter and evaluate your specific situation with your team.
You will never find the optimal ratio of design/build, but you can train yourself and your team to have a better feeling when it is time to switch.
Good luck with your next project :)
Top comments (0)