https://intenseminimalism.com/2015/a-framework-for-thinking-...
It's in the book (available online for free) called How to Design Programs: https://www.htdp.org
It introduces the notion of a "design recipe" for structuring thinking and problem-solving for programming.
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...
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.
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.
Social skills, communication skills is just as important as solving practical problems. This skill can be trained and often underrated.
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.
> 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 ;)
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...
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.
Hammock Driven Development https://youtu.be/f84n5oFoZBc
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."
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... [2] https://www.amazon.com/Solving-Problems-Design-Thinking-Publ...
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.
As someone else said, the individual phases can be huge, which is why in large projects the first step is often to break down large business needs into more manageable chunks, each of which can be worked on seperately, either linelarly or by multiple teams. In a healthy process as the work progresses it is used to reevaluate previous decisons & designs. So basically agile.