
Understand, Design, Build: A Framework for Problem-Solving - harryzhang
https://lob.com/blog/understand-design-build-a-framework-for-problem-solving
======
thinkingkong
Reminds me of this incredible chart / graph which you can use to apply to a
lot of situations. I actively refer to this and show it to teams constantly.
The gist of it is that you require many skills and capabilities to create
alignment. Without that, you have different outcomes which we may initially
experience as frustration / failure.

[https://intenseminimalism.com/2015/a-framework-for-
thinking-...](https://intenseminimalism.com/2015/a-framework-for-thinking-
about-systems-change/)

~~~
andrenotgiant
thanks for sharing, pretty sure that is a post I will come back to often

------
heathermiller
There's a methodology of teaching programming focused on understanding and
designing programs.

It's in the book (available online for free) called How to Design Programs:
[https://www.htdp.org](https://www.htdp.org)

It introduces the notion of a "design recipe" for structuring thinking and
problem-solving for programming.

------
Spearchucker
This framework is good. And like the other frameworks in other comments here,
it's a good enough start in a small company, start up, or small department
within a larger organisation.

A better framework might be cobbled together from various disciplines. For
instance, "Understand". This part is huge. Well, bigger than those three
questions the author lists.

"Understanding" begins by stepping back to look at the environment as a whole.
Bound the situation. Assess organisational culture, the environment (immutable
aspects of a transformation/process), the organisation's technology landscape
(Active Directory?), regulatory requirements, competition, suppliers and
customers.

There's also the social system (roles, norms, values), and the political
landscape.

Then you define your objective. But before you can do that you need to know
who your client is. Sure, in SV that's often easy. Outside that bubble not so
much. Identify the client by asking some questions - whom do you need to
satisfy? Who will judge the success of the project? Who will fail if the
project fails? Who has authority for the project? Who pays for the project?
Whom do you report to?

After all that you're ready to set an objective. Vision/scope stuff. Specific,
measurable, attainable, realistic and time-boxed. Cliche'd, but when a project
goes wrong the specification is the only version of the truth a team has to
fall back on.

Setting project objectives is much bigger than I can do justice to here.
However once you have that you can start with the fun stuff. Design, build,
deploy, repeat until done.

However while you're doing the fun stuff you still have to do the unfun stuff
too - risk management, and stakeholder management. And it's stupefyingly
incredible how many people think they know how to do these things but can't
readily explain the difference between mitigation and contingency, exposure
and impact, or why you have to be nice to the CIO for your project to succeed,
even though the CTO and CEO are on your side.

I've written about all this stuff.
[https://www.wittenburg.co.uk/Entry.aspx?id=8ec91ced-b3a4-4b0...](https://www.wittenburg.co.uk/Entry.aspx?id=8ec91ced-b3a4-4b07-bf91-17f0efda1718)

~~~
dominicr
I think you've just nicely summarised why architects & project managers exist!
There's a whole level of treacle to get through before coding can start, and
that stays with the project throughout its lifespan.

The challenge I see most is getting the right level of understanding and
design freedom to the developer level, where they know why they're being asked
to do some work but without burdening them with extraneous detail or
processes.

A lot of developers get annoyed at project managers and architects but they
dislike project politics even more.

~~~
Spearchucker
" _A lot of developers get annoyed at project managers and architects..._ "

If a PM or architect is annoying developers then there's a very big problem
with the PM or architect. Like any profession you get good and bad apples.
It's why anonymous feedback from people who manage you and whom you manage is
so useful. Of course ego is prevalent the higher up the chain you go so this
is something many organizations won't do.

------
Geee
Yeah, usually the hardest problem is to define the problem, or even know that
there exists a problem that could be solved. Once you have discovered,
understood and defined your problem, solving it becomes easy.

~~~
est
That's why "vision" is important.

I've seen too many companies tries to be the "next Apple" or "Next Google". I
mean come on that's not a vision. Google's vision was to organize human
knowledge. That's a god damn good one.

------
WoodenChair
A more thorough framework to solve problems might come from being familiar
with all of the available problem solving techniques in your domain. For
instance, if your job is software development, you may want to know all of the
problem solving techniques in computer science. Now is the point that I will
be a shill for my own book: [https://www.manning.com/books/classic-computer-
science-probl...](https://www.manning.com/books/classic-computer-science-
problems-in-python)

~~~
victor106
Your book in swift with the same title is awesome as well.

~~~
WoodenChair
Thanks for the shoutout!

------
blaze33
> common misconception among new software professionals that the best
> engineers are the best at writing code

> Our job is to find and solve problems that move the business forward.

Couldn't agree more. Would also add that this "best dev==best at coding" ain't
only restricted to the young ones. Never stop asking theses "why" questions
that sometimes show us that crappy and cheap systems may work wonders ;)

------
badfrog
These are very important steps to creating something, but there's not really
anything new here.

This is basically a simplified version of the design thinking framework with
the implied "build" step at the end made explicit.

For example, the process that has been taught at Stanford for years is:
empathize, define, ideate, prototype, test. The first two steps could map to
"understand" here with the last three falling among "design" and "build"
depending on the fidelity of your prototype.

PDF link to an overview from Stanford: [https://dschool-
old.stanford.edu/sandbox/groups/designresour...](https://dschool-
old.stanford.edu/sandbox/groups/designresources/wiki/36873/attachments/74b3d/ModeGuideBOOTCAMP2010L.pdf)

------
Aegaeus10111
This is an adaptation of Design Thinking which designers have used for years.
It's found in Human centered Design, Design Sprints, Jobs To Be Done... and
others.

I've seen lots of projects fail, cost way over budget, take years longer than
projected (personal recorded: I paid a developer to write me - his estimate -
a 6 week project. 8 years later he returned my money), and/or completely miss
the target because Dev jumps right in and starts coding - not being concerned
with the "soft" stuff like business, usability, experience design, etc...

If this helps dev teams join the holistic effort to success, I'm all for it. I
entirely agree that coders need to be problem solvers but also solvers of
_relevant_ problems.

------
wa1987
Good talk on this subject:

Hammock Driven Development
[https://youtu.be/f84n5oFoZBc](https://youtu.be/f84n5oFoZBc)

------
chiefalchemist
"But our job isn’t to write code. Our job is to find and solve problems that
move the business forward. Writing great code is a necessary but insufficient
skill for doing that job."

If only more / most people understood this. Coding has a finite use. Problem
solving (and critical thinking) are universal and possible uses approach
infinity. They are the equivalent of the proverbial "learning to fish."

------
JunaidBhai
Well written content. However, I am not sure if thoroughly complete. The whole
article covers areas of shortcomings related to understanding the problem,
designing the structure and building it. But fails to address "upgrading
current solution" or "optimizing the current solutions" that suits the current
market needs.

~~~
badfrog
> However, I am not sure if thoroughly complete.

Of course a 1,000 word web article is not going to be complete. There are
dozens of books you can check out for more info, including from Tim Brown CEO
of IDEO [1] and from Columbia Business School

[1] [https://www.amazon.com/Change-Design-Transforms-
Organization...](https://www.amazon.com/Change-Design-Transforms-
Organizations-Innovation-ebook/dp/B002PEP4EG) [2]
[https://www.amazon.com/Solving-Problems-Design-Thinking-
Publ...](https://www.amazon.com/Solving-Problems-Design-Thinking-
Publishing/dp/0231163568/)

------
shay_ker
Is... is this waterfall?

~~~
badfrog
I don't know about this author's intention, but in general with design
thinking frameworks, the idea is not that each step must be followed rigidly
in order and never re-visited. It's more about calling attention to the
importance of each part of the framework. Once you know all the inputs needed
for creating a great product, you can seamlessly move back and forth among the
phases, iterating until you're arrived at the solution.

~~~
hliyan
I agree. In waterfall, you close the 'design door' behind you when you go into
implementation. There is nothing wrong with taking a phased approach as long
as you keep that door open for the inevitable changes you discover while
implementing.

In fact, that's the way it should be. There is no human endeavor that does not
benefit from an understanding of how something should be done, before it is
attempted. I'm not sure why some seem to feel that software engineering is
somehow special in this regard. I can't count the number of times we have had
people shout down attempts at serious engineering design, often by using the
term "waterfall" in a derogatory manner.

