adiherzog
commented
7 years ago Just some thoughts when reading the title and the description:
Is this related to Simon Sinek's "Start With Why"?
I think it should at least have a reference to it, because that's what many people could think you are talking about. And it should probably also consider other authors with a similar message, for example "Impact Mapping" or even the old school "Inception phase" à la RUP, or tracability from features to user goals / business goals. In the end it's all about building things that matter... to someone with money... ;-). Y-Combinator says "Make something people want.".
I think the "why" question became more and more important in software engineering the more it turned into an industry and therefore the developers became more and more detached from the people that actually use the software (with outsourcing being an extreme case of this). I imagine that in the early days the programmer was usually also the one getting the use of the program. E.g. the accounting department programmed some accounting routines. Then later there was a programming department in the company that still knew the business quite well (and therefore the why). Then came consultants, that have to ask why a lot because their business is mainly software and not much the business the customer does. Then in the end came outsourced consultants, which did not only require more of the why questions but also made it harder to ask them. This in turn spawned a whole sub-industry of people finding new ways how to ask why in the best way ;-) I just made this up, but doesn't it have some truth in it?
On the other extreme of what I just described, it's quite easy to understand the why if the software you are writing is something you are also a user of. This makes it quite easy to understand the purpose of things like a search engine, a social network or a generic spreadsheet application. That's why I think writing generic or common sense software is in general a much easier task and can not simply be compared to writing bespoke software for a very specific need that even the business itself might not fully understand.
Another aspect I find important here: as a programmer at heart we often want to build a tool for everything. That's just what we do, what we know and what we are (hopefully) good at. But tools is not what our customers are looking for. Our customers are looking for solutions for their problems, and this solution might involve building a tool or not. Instead it might be better solved with changing a process, with buying and integrating some existing software, or maybe we should start with a prototype to find out whether the tool we want to build is actually the right one.
Loosely related talk by Paul Watzlawick: When the solution is the problem (https://www.youtube.com/watch?v=7etsh4HwG78). He tells a few stories that illustrate how having a certain solution in mind or having a certain mental model can be restricting in finding the right solution.
I guess the Stars to Road model is also somehow related to this: http://starstoroad.com/blog/
May I propose some additional questions to treat?
- How do I decide that I have enough understanding of the "why" so that I can invest more time into the "what" and "how"? (this just reminds me that Michael Qvortrup often uses these terms when discussing software architecture...)
- I have the suspicion that once you are a few months or a year into a project you might start getting "why-blindness". Maybe you are still working towards the original why, but what if the why changes or was actually wrong and nobody notices or wants to notice because that would question the work already done. I know that an agile mindset should help here, but I don't think it makes one immune against such problems. So how can I not just start with the why, but also maintain the connection to the right "why" throughout the project?
As I said, just some thoughts that came to my mind. Use them as you wish for the article. Or if you like, we can also sit together over a coffee to elaborate more on our ideas and maybe even write the article together.
peitor
mdf88
abeggchr
Content: