11

I've been a developer for a while. I'm far from the best out there. (As I sit by myself in this room, I wonder if I'm even the best in here.) However, I've come to understand my tools, and I've come to trust in my ability to reason and learn.

When starting a new job, I always believe that I can learn the codebase if it's a language I know. If it's not a language or framework that I know, I believe that I can grasp the concepts enough to learn it (and just read the documentation). This is a part of our skillset as programmers and I'm proud that I can live up to this standard.

For all of this, though - one of my major weaknesses is learning and internalizing business rules for the client I'm working for in a quick way - whether I'm a paid employee or a contractor. I'm fine with codebases, but business rules and processes for a specific business always seem to take me a while to fully understand. (As an example, this can be a tripup when rewriting enterprise applications.)

As a developer, what is the best way to assimilate business rules and processes quickly and efficiently? Is it possible without being a subject matter expert or simply having years of experience with the client, company, or business?

gnat
  • 21,442
  • 29
  • 112
  • 288
  • 3
    This is a very good question to discuss with other programmers, but unfortunately it's off-topic for this Q&A site: it's both too broad (there is a lot to say about the matter) and primarily opinion-based (different people will tell you different things, essentially what works for them... how are you going to choose the "right" answer?). – Andres F. Apr 13 '16 at 21:53

4 Answers4

4

For me, it is by reading and understanding codebases.

I say that for two key reasons:

  1. People suck. Oh, not deliberately (usually), but in business I've found that people often have subtly different understanding of the business rules. And everyone has their own mental model that in turns loses fidelity as they try to communicate it to you. But the code doesn't lie. People can think what they want about how things are supposed to work, but the code is right.

  2. Build a foundation first. So if everyone has their own mental model of what these business specific terms and processes are, how do you build yours? For me, and I expect for many programmers, I build my mental models best from code. Code has patterns. Code has abstractions. I have a lot of experience taking code and building a mental model from it. Once I have at least a vague shape of what things exist and how they relate, then I can talk to business people. Then I can ask the right questions and better fit their answers into the puzzle.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • 2
    Your approach sounds a bit chicken and egg. – Robert Harvey Apr 13 '16 at 06:11
  • @RobertHarvey Can you explain what you mean by 'chicken and egg'? – Falgantil Apr 13 '16 at 08:17
  • 3
    @BjarkeSøgaard: You write code to understand the business rules without first understanding the business rules so that you can write the appropriate code. See also [Chicken and the Egg](https://en.wikipedia.org/wiki/Chicken_or_the_egg) if you're asking what that idiom means. – Robert Harvey Apr 13 '16 at 15:54
  • To be clear, I'm focus on _reading_ code first. – Telastyn Apr 14 '16 at 01:25
  • 1
    @Telastyn Sometimes, code is incomplete or incorrect - or nonexistent. I've had to write code for undocumented business processes - either as a new feature or as a new system. Further, often, the code isn't all-encompassing when it comes to business rules - the code for an inventory system can show you *how* process works, but not necessarily *why* process is defined the way it is. I believe that knowing why things work and why they are done always leads to better solutions. –  Apr 14 '16 at 12:14
  • To build on what @lunchmeat317 had to say, although the code absolutely reflects *what it does*, that doesn't mean it works the way it *should*. I have a particular piece of software (written by someone no longer with the company) that absolutely *just doesn't* do what every user I've ever talked to thinks it does. We will be re-writing parts of it to match up with their expectations sometime soon. If for no other reason than I'm tired of explaining how the damn thing actually works. – RubberDuck Sep 18 '16 at 15:43
3

Don't be too hard on yourself. Sometimes I wonder why they even bother calling them business "rules" but I guess calling them "ways we typically do things unless there are other things that apply then we do them differently" would probably insult them. Business is messy. They juggle the needs of customers, legal agencies, accounting, regulations, vendors, employees, managers and local government. They don't always have a reason.

I think the best way is to make sure you're spending time with as many business people as you can. This can be difficult for some people in technical positions.

  1. Budget your time and be respectful of theirs, but get as much as you can.
  2. You'll need to ask questions. They don't think like programmers and break everything down and have a complete understanding how information relates to one another.
  3. Don't fake like you understand. If you knew as much as the other business people they'd make you do both jobs. See #2.
  4. Don't expect documentation. Offer a lot of praise if you ever get any.
  5. Hold off on criticism. The processes and procedures may have redundancies and other potential inn efficiencies, but there may be a reason for that. Learn why, but don't be shocked when they say, "We've always done it that way."
  6. Be courteous, kind and share your snacks. You're dealing with people. Say hello. Ask how they're doing. Ask about why they went into the industry, how long they've been with the company.

You're not some void called the programmer, you're a person. Let them know you're there to make their job easier. Unfortunately, you can be the hero or the goat. It's the nature of our business.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • I've really got to work on #5.....I'll try to remember this. –  Apr 13 '16 at 21:25
  • #5 is absolutely huge. I work in pharmacy. A question can come back with "I didn't know the computer could do that" or "Unless we follow this specifically people could _die_." In that vein, never, ever say "why don't you _just_" because "just" will often show your ignorance of the complexity of a given interaction. – Alan Shutko Sep 19 '16 at 03:10
3

I would recommend reading a book called The 5 Elements of Effective Thinking by Edward Burger and Michael P. Starbird. It's related to understanding new concepts in general but I think it applies to this situation.

Here are some interesting points from the book:

Master the basics

If you don't know the basics, you'll be building your understanding on a shaky foundation. So you need to ask those stupid-sounding questions that no one else asks.

Let errors be your guide

Sometimes it helps to ask questions that are clearly wrong so you can uncover your lack of understanding. (Ex: You mean admins have access to every document? Oh. Why?)

Teach or explain it to others

When you try to teach it to someone else you'll start uncovering where you have trouble understanding.

Hope that helps!

Venkat D.
  • 131
  • 2
0

As developer I have realized that I directly translate the business into code, data structures, possible classes, etc... I go from something abstract and often, undefined to something specific, something with "shape". I start to code immediatly and, the lack of information, lead me to frequent refactors. Every refactor make me think that there're too many gaps in my understanding of the business.

How I have started to solve this?

I force my self to read all the documents made during the functional analysis and earlier phases. I try to do It as I were the customer or the end user. I need to understand what is customer looking for with such application and requirements. But I need to stay away from the dev I'am.

Our job provide us with a great skill that customers does not have. We think in conditional structures on a way that others does not. So I start to confront requirements. Looking for contradictions or incoherences. Little bit of brain storming around what I have understood. Formulating hypothetical scenarios.

It lead me to questions and doubts. I type down everyone of them and finally I set a meeting with whoever can solve my doubts.

Summarizing I change my point of view. I try to look at the problem from another perspective. But I put some dev's skills on the process. What ends up in a good bunch of questions and doubts to be solved. Once solved, my understanding of the business is deeper.

Study > Doubts > Questions > Answers > Understanding (an repeat the cycle over and over)

Laiv
  • 14,283
  • 1
  • 31
  • 69