Have you ever been in a situation where you produced some code without understanding the whole context of what you were doing? And later realised the implementation that you created was not inline with the direction the business was steering? Well here is a thought on why it is really important to know the WHAT and the WHY to master the HOW

Business Knowledge

We don't need to know everything

BUT it is important that we understand what the company we work for does. Not only the work we will deliver will be better in quality but it is also likely to improve maintainability and flexibility when the business will ask for new features.

And it's not as hard as it could seem at first sight. Of course our job is first to understand the code base and architecture to be efficient in making any change, but it is essential that we understand the business basics, and a bit more when needed.

Knowing what the company does or sell is the first intro that we will have to the company usually even during a job interview. Once we are sure of what the company creates or sell we will have a good idea of its product(s), that's the WHAT. This knowledge will enable us to find out competitors and potentially find out what our business is trying to do better or differently than them, that's the WHY.

This knowledge will give us basic understanding of the business mission, its goal. Now do we, as developer, want to know everything about the strategy of the company or the financial details of all operations? Not really...

Get useful knowledge

It is true we don't need extensive knowledge of all the business details. But here is the trick, sometimes it is important to know more than what is given in a ticket or a project description. Often developers are perceived as machines to build code and whatever is thrown our way will be done, sometimes good, sometimes buggy, but often done without discussion. Now if you have the chance to have a great lead and a product manager who know how to do his/her job, we sometimes feel like all the specifications have already been discussed and that there is nothing else to be done. But this is not always true.

This is when it is important to understand our business well. Understand all the implications of the project. If it is a product we never worked on before, let's understand who it is for, how it is used, what impact it will have on our business. The thought process or the questions generated by figuring this out will sometimes (if not often) lead to an implementation plan different than the one you would have had.

What does this mean for your code

Coding with a goal in mind

Having the large picture in mind will have two nice effects. On one side it will make you avoid dirty hacks when a new feature comes along that would have been easily implemented if the architecture was more flexible. On the other hand it will enable you to see edge cases or isolated cases that should not require extensive over-engineering and loose of focus on some other important matters.

Understanding hacks and edge cases

And that's why we should always consider wether or not it is worth it to refactor a piece of code that needs a new feature or if a hack will do because this piece of code is being deprecated by the business or because another project has this refactor in its scope.

Sometimes the dirty hack is OK, it needs to be documented well, explaining the what and why of it, but it's OK because we understand that its lifespan is not worth the effort.

Avoid infinite feedback loops

Finally, the main benefit of understanding the business well is to win a lot of time in feedback loops.

Instead of developing the feature and then wait for the business to validate, ask for change and you implementing these changes over and over, you want to take steps to prevent this.

First, starting by asking all the necessary questions will help you and your stakeholder realise what you may have missed during the definition of the project, and you'll be sure that you understand each other and have the same vision.

Then, when you're developing the feature and testing it, you'll know what it should do and how it should feel like rather than having to wait for business feedback to realise.

TL;DR

Ask a lot of question, make sure you understand not only what you work on but also who you work for and why you do it. It will save you a lot of time and improve the quality of the work you deliver!