loading...

Is Why more important than How?

alediaferia profile image Alessandro Diaferia ・1 min read

As developers, we're often eager to start coding the solution. The problem is, sometimes, we start with the solution in mind, but we're not clear as to what the problem is.

I often see myself wondering what's the cleanest way of implementing what I have in mind: but I soon realize I'm focusing so much on the implementation details that I've almost forgotten why it is that I want to implement a certain functionality.

When I focus too much on the implementation, the purpose of the functionality starts to become less concrete and I almost forget what the value I wanted to deliver to my users was.

I've seen this happen in many situations. User stories specified starting with the How rather than the Why. They, deliberately or inadvertently, mandate a specific implementation. But, in doing so, I think they dramatically reduce the possibilities of really delivering something valuable to the user.

Try start with the Why, instead. Why do you want to build this feature? What is it that you want your users to be able to achieve? By doing this exercise I often find that the implementation that was originally suggested wasn't really the best way to help the user achieve the intended outcome.

What's your take on this philosophical matter?

Also, if you want to hear more philosophical questions from me, follow me on Twitter

Posted on by:

alediaferia profile

Alessandro Diaferia

@alediaferia

I'm a Software Engineer based in Dublin. I love crafting software and experimenting with languages and technologies. I'm a #DevOps advocate and continuous improvement pursuer.

Discussion

pic
Editor guide
 

Why is the most important. In 6 months nobody cares about the how. If it was made you can see what it does. But not why is does this. In software development the how is automatically recorder. The why, unless explicitly given attention, will be lost.
If you spend more time on the why, you either have to record it, or it will better stick in your memory.
At some point during the how you might find out it's not going to work this way. If you don't have a good grasp on why you were doing it, then it will take more time to figure out a different how.

 

I think you made a great point here. The how is automatically recorded by the implementation and that is the only useful way of tracking it and make sure it stays relevant. On the contrary, the why is hardly recorded and is harder to keep track of. Keeping track of the why might help deciding whether the current how is no longer relevant or not effective at delivering the originally intended value.
Thank you for your take on this 🙇