Anybody can learn how to code and get really good at it nowadays. Implementing code isn't the hardest part anymore. Trying to figure out how an application should flow for a user has crept up that list of priorities. Getting that information out of a product manager or project managers can be tricky since you're all speaking different jargon. That means someone has to be able to translate business logic into code and that someone is you.
Not every developer will have to directly talk to business managers in their career, although that doesn't change how useful it is to understand the business needs. It's one of those things you only get with experience and it is a subtle art that depends on the industry you're building an application for. Here are a few reasons you should always try to understand the business logic before you jump into the code.
It gives you a reason why things work the way they do
As you're adding features to an application, it helps to know how it currently works and how users expect it to work when with your new feature. When you know a bit about the core business behind the app it helps give you perspective on where the company is heading and then you can write the code in a way that helps support that. If you have ever seen a ridiculous task that makes no sense as to why anyone would ever want it, remember, it was a decision made to drive the business forward (hopefully).
Working off of a task list without context can make it more difficult to implement features if you don't understand what a user will do with it. Don't be afraid to ask questions about the product you're working on because the business people love that (sometimes). Learning about the business logic will not only make you a better developer, it will also make you a domain expert on the product. You will understand more about how the app works in that industry than most people in the company once you start writing code with the business needs in mind.
It tells you what kind of features or changes you can look for
There's a huge difference between the initial setup for an app that get 10,000 hits in a day and an app that get millions in a day. Knowing that a business is trying to grow will give you some insight on what to expect from the task list. After you have learned what the application does, how it works, and how the business wants it to work, you can start being proactive with your coding. When you sit in on a meeting with business managers and they talk about budgets and release cycles, you get an idea of what might be coming your way.
If they are going over metrics for user activity, you might expect a lot more feature requests or get ready for performance testing. Remember, the business needs are what drive your task lists and a huge part of your work environment. When you pay attention to what the business is doing you can be better prepared for any bombs that get dropped.
It helps you give better communication with product managers
Product managers work with developers from time to time and they can have great conversations. The product manager can teach the developers about the business and the developers can explain the tech to the product manager. When you are in an environment like this, take advantage of it! You can explain to a product manager why a certain feature should be implemented in a different way or how long a particular task will take.
They are also your resource to ask business logic questions. Maybe you know that some functionality is already working in the app and they forgot about it. When you tell them stuff like that you just saved both of you a lot of wasted time. You can even get them in on your sprint planning meetings to get feedback on user stories and get general ideas of what they are looking for when the task is finished.
It helps you understand how the core business works
Knowing about the company you work for is important because you spend a huge part of your life with them. It's always good to be aware of what direction the company is headed so you can decide if it still aligns with what you want. Learn about the way big decisions are made and learn how those flow to your work. Once you start connecting the dots of how the overall business needs are being made and how they connect to you, you'll find yourself doing the work a little easier with more purpose.
When you run into a case where you have multiple options to fix an issue, you'll know the best one to pick because you have an idea of what might come later. The details of the core business will also help you communicate better with different parts of the company as well. Having domain knowledge is another big deal when you learn about the business. You'll be able to work through the code faster because you know how everything should work and why.
This is just some of what I've learned in my developer adventures. What do you think? Do you think it's that important for developers to understand the business side of things or does it just depend on the person? Let me know in the comments!
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding
Top comments (11)
Very well written !! I always tell my team that business knowledge is more important than how to write code.
I call it “the story behind this requirement”, there is always a background about how each requirement came. If you know the background of the requirement, it will be easier for you to implement it and even suggest improvements.
Recently, Knowing the business, I was able to suggest integration of multiple applications to my product manager and delivered better products reducing the overall time of the process.
Love this, I couldn't agree more. Knowing the jargon of the software you're writing and fully understanding the context makes coding much, much easier. Just simple constructs like variable/class/function names will have been decided upon with prior domain knowledge, so just getting to grips with these (Let alone logic) will require some fundamental grasp of the lingo.
This is most of what I learned from the business analytics perspective in school. Converting business processes into a digital platform and retrieving the results is as much a human issue as it is technical. Excellent article.
Thank you, a great reminder :)!
A software developer should be a partner to product managers/business owners - someone, who's able to spar with ideas, ask challenging questions regarding the domain so both would win.
I think this explains why so many specialized software areas have absolutely terrible software. Electronic health records, dispatch systems, traffic engineering are the examples I can think of off the top of my head. You need a lot of specialized domain knowledge to write software in any of those areas, and oftentimes unless you have had direct experience in that field you won't be able to sufficiently master it. The people writing these systems have spent a lot more time mastering the domain than studying software practices, so even if it looks like garbage or crashes randomly, it's still going to keep selling.
I always collect all good information about coding as much as I can. I love to do that and your information also very good. I'm a college student and after my classes most of the time I would like to spend in coding. And yes for my assignments I take help from edubirdie just because of time shortage. I don't write my writing stuff by myself but yeah all computer work I do by myself.
This applies to user interfaces as well. The last time i made a UI, i spent a LOT of time (More than 40 hours) just asking questions and gaining understanding of how the business worked. It was a complex foreign trade business. It went well cause the CEO was happy to explain it to me. Then I realized some stuff (some things they had on their current user interface) actually made sense, but it could be improved a lot.
Awesome.... Thanks for this wonderful piece.
This should be first chapter in Programming 101.
Love it!