35

I am working on a Trading and Risk Management application and although from a C# background, I have been asked to work on SSIS packages. Now I can live with that. The pain point is that there is too much emphasis on business understanding. Trading (Energy Trading to be exact) is a HUGE area and understanding every little bit of it is overwhelming. But for the past two months I have been working on understanding the business terms - Mark To Market, Risk Metrics, Positions, PnL, Greeks, Instruments, Book Structure... every little detail (you get the point). Now IMHO, this is the job of a BA. Sure it is very important for developers to understand the business but where do you draw the line?

When I talked to my manager about this, he almost mocked me by saying that anybody can learn a technology in a week. It's the business that's harder. My long term aspiration is to remain on the technical side, probably become an architect (if possible). If I wanted to focus so much on business I would have pursued an MBA!

I want to know if I am wrong or too naive in understanding the business importance or is my frustration justified?

Mayank
  • 1,397
  • 2
  • 13
  • 19
  • 12
    Please tell your manager that Technology/Programming is not limited to EXCEL || MS Office || Same-time Connect, which anyone can learn in a week. – Ranger Feb 24 '11 at 05:57
  • I can't believe at some of the answers, I hope people down-vote the answers with vengeance. – Gaurav Feb 24 '11 at 06:46
  • @Gaurav, I hope not. I dont think heated emotions would do any good on this forum (or any forum in general). I would be interested to know your concrete objections, so feel free to comment on the answers you have issues with. – Péter Török Feb 24 '11 at 08:35
  • @Ranger LOL! You say that easy a Manager Job will be? – Gopi Feb 24 '11 at 08:39
  • I agree with most of the answers, so no need to add my own. Suffice to say, finding out how a developer interacts with business people is always an important part of any interview I conduct - it's difficult to tease out the information though. – ozz Feb 24 '11 at 08:49
  • @Peter My problem with answers is that almost everyone is saying that it is important for programmer to understand business domain, of course it is! But what I am curious about is to what extent should a developer make effort in understanding the business domain. Should he go all the way, or there is some line to be drawn. I hope someone will address this, but at this point I am not very hopeful. – Gaurav Feb 24 '11 at 09:10
  • @Gaurav, I updated my answer below to address your question. – Péter Török Feb 24 '11 at 09:31
  • I think @Peter has the right answer, I hope his answer is selected (or else the terrorist would have won against the free world) – Gaurav Feb 24 '11 at 10:20
  • 5
    Ask him to learn what you do in a week. That's a highly arrogant attitude. I'd even make a bet with him that he can't do what you can, bet for twice your salary. It might take a week for a newb to learn the syntax of a specific language's memory, operands, and conditionals... and probably a month or more to even master them. It was a long process to get where we are, but it's generally our passion so we've spread out the hardships through a lifetime. – Incognito Feb 24 '11 at 14:24
  • One of my previous employers had the idea that the IS department was to know both the business and the technology. Each had equal importance to solve the problems the business was managing. – JB King Oct 01 '12 at 20:13

9 Answers9

35

A programmer's job is translating natural language requirements into machine language implementations. You can't do that effectively if you're only fluent on one side or the other. Unless you're writing compilers or version control software, pretty much every programming job will require a significant amount of non-programming knowledge.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
  • 1
    When a programmer wasn't aware of what client speak it hard to code – Gopi Feb 24 '11 at 08:41
  • +1 @Sri Kumar true, but I think being a programming, you should still be able to figure out what it is they *need* and how you would use technology to bring about a solution. I agree, writing business solutions means coming across all kinds of businesses. – gideon Feb 24 '11 at 10:44
  • 3
    My answer would have been the same thing worded differently. If you don't understand the context of what you're creating, you're going to create it in the context YOU understand, not the one that is EXPECTED. Unless you're on a large team and you're writing XML specs and objects based on UML diagrams, it's very important. – Incognito Feb 24 '11 at 14:20
  • 1
    Even compilers and vcs have a domain, we might just be more comfortable with it. – Josh Johnson Sep 17 '13 at 19:32
25

Benjol and your manager are right, but let me elaborate:

learning the business domain is how you add value to the process and increase your value to the business

this is the difference between a code monkey programmer and a developer

Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
19

There is a saying that came from my University's Computer Science Department:

If you want to build software for Geologists, you must first understand Geology. If you want to build software for Physicists, you must first dabble in Physics. If you want to understand business, then you first must learn to talk business.

I hear people on here all the time saying that Software Development is a creative field. I believe this is true to a certain extent. It involves creativity in that one must be able to see outside the box in order to solve a series of problems.

What it doesn't mean is that you can just sit down and oh so creatively build whatever it is you want to. This isn't Art class, it's Engineering, and your customers and stakeholders are going to expect you to create something that solves their problems, not something that is just "cool".

In order to solve a problem, you must first understand the problem. You need to get into your users' heads and understand how they think.

Whether you're building software for finance, marketing, sales, geology, physics, or whatever field the software supports, you must become a part of that field.

It is for this very reason that, in addition to my Computer Science degree, I also earned a Business degree; it has made a huge impact on my ability to communicate potential solutions and deliver successful products.

If you want to learn more about what I would look for when hiring a business software engineer, check out this Business Engineer Job Advertisement Sample that I wrote as an answer to another question.

Community
  • 1
jmort253
  • 9,317
  • 2
  • 35
  • 63
  • 2
    +1 - **Your customers and stakeholders are going to expect you to create something that solves their problems, not something that is just "cool".** – Karthik Sreenivasan Jan 23 '12 at 07:15
  • "If you want to build software for Geologists..." love that statement. Which university? would like to be able to cite it! – Raj Rao Jun 04 '19 at 22:34
  • 1
    @RajRao Unfortunately, I paraphrased, and I don't remember exactly who I learned that from. It was either Dr. Ruben Gamboa (http://www.uwyo.edu/cosc/cosc-directory/ruben/index.html) or Dr. William Spears (https://uwyo.academia.edu/WilliamSpears) of University of Wyoming, Laramie, Wyoming, USA. – jmort253 Jun 05 '19 at 11:51
14

You might survive without much domain knowledge or customer contact as a low level coder, but a software architect is somebody who is very familiar with the domain and actively communicates with all stakeholders.

vegai
  • 693
  • 3
  • 8
  • 2
    +1 - It's very naive to think that one can be a successful architect without understanding the domain. If I could, I'd +1 you again for mentioning communication. Too many people neglect communication development in their careers. – jmort253 Feb 24 '11 at 07:39
12

In my opinion, you are wrong and too naive.

As your manager said (slightly flippantly), anybody can learn a technology in a week. The only thing that is going to mark you out and make you useful to your company is your business knowledge. And the harder it is, the more you'll be worth.

Obviously, if you find that this particular business is mind-numbingly dull, you can look for something different. But if your idea of paradise is hacking together little php websites, beware: there will be thousands of script kiddies who are doing that too.

Seriously, "I'm just a coder, don't confuse me with the facts" just won't cut it.

Benjol
  • 3,747
  • 5
  • 33
  • 41
  • 1
    I agree with this. If you want to code in a vacuum go back to academia or get a job with a research branch at some big corp such as IBM, MS, or Google. For most of us, the reality is that we must understand the business, especially if the goal is to become an architect which is fundamentally a combination of strong developer and strong BA. – Curtis Batt Feb 24 '11 at 05:53
  • @Benjol Thanks for your reply. I too understand the importance of business. Its the reason these technologies exist. Trust me, I get this big time. My point is that a dev should have the bigger picture and focus on nitty gritties of the module he is working on. Is it wrong in saying that its very difficult to understand the details of the **entire** business? – Mayank Feb 24 '11 at 06:05
  • 1
    @Mayank, imho, it is indeed very difficult to understand the details of the entire business, and it's something that you should really only expect to do naturally over time. Each element of the system(s) that you work on should naturally involve learning more about the business. That's how things have worked when I have worked in industries with heavy domain knowledge. – Carson63000 Feb 24 '11 at 06:14
  • 2
    @Mayank, No, it is not wrong to say it's very difficult. When I arrived in my current job, my new colleagues told me it would take 6 months just to get my head round the *code*. Now I'm approaching 4 years and still learning new things about the business... – Benjol Feb 24 '11 at 06:29
  • 1
    +1000 if I could. IMHO, the tech is the easy/fun part. – ozz Feb 24 '11 at 08:48
  • 1
    No he is not being Naive. Further his manager is a *bleeping* idiot, and should be paddled on a regular basis. – Gaurav Feb 24 '11 at 09:13
9

I work in Energy Trading as well. Business Knowledge is 90% of the job. You can't get around that - it's a complicated business.

If you don't at least understand the basics of trading, and the markets you're working in, you're going to struggle no matter how good a coder you are.

I work with some BA's who just can't get the requirements right. I need to rely on my own analytical skills and understanding of business knowledge to get the job done.

I think if you're working for a shop that sells Energy Trading software, your experience may differ - but in Corporate IT energy trading the focus is squarely on understanding the market and how software can provide solutions to the business's problems first.

The actual technologies used and implementation comes a distant second.

The guy above who made the Excel comment doesn't know how apt his comment is. Traders often build their own little trading apps in Excel/VBA (that's all they know) and then IT ends up inheriting these messes of programs.

I'd love to rebuild some of these apps in a "proper" language, but that's just not always a priority.

asgeo1
  • 440
  • 5
  • 8
  • 1
    +1 For "complicated business" :) I have worked in banking domain before this and found it much more interesting and easier. Also, like you pointed out everything is done in Excel! – Mayank Feb 24 '11 at 08:12
6

If you're developing for a business, you will end up having a clearer and more detailed idea of the business rules than anyone else in the company. This isn't necessarily because you're smarter then everyone, it comes because it's the only way you can do the job.

Your reaction might be "But what do the business analysts do?"

The business analysts sit in long meetings with the customers trying to get requirements out of them that are clear enough for a developer to work with. I look at the way they have to deal with customers, and feel grateful that I don't have to do that.

Andrew Shepherd
  • 1,589
  • 1
  • 9
  • 13
6

I like to draw analogies between software development and architecture. Both are applied arts. Both require elaborate modeling inside one's mind. The aspect that applies to this question is that writing software without business knowledge is like designing a building without understanding the inhabitants' lifestyle and needs. I think many of us has seen (or even lived/worked in) buildings which may look beautiful and modern and whatnot from the outside, just aren't usable from the inside. (In the worst case, they aren't even nice :-((( )

Update

Gaurav's comment:

what I am curious about is to what extent should a developer make effort in understanding the business domain. Should he go all the way, or there is some line to be drawn.

I don't think you can draw a line anywhere in general. Unless there are parts of the app/domain you don't need to touch (thus understand) ever. Which is IMHO very rare in real life, over the long term. Any part of an app which is in active use will get bug reports and feature requests. Domains change too, as corresponding legislation, tax rules, policies, habits - in short, the real world - change. This must be followed in the software too.

But even without external requests for changes, unit testing and refactoring legacy code requires understanding the relevant domain areas as well. Otherwise you just "freeze" the current behaviour of the app, without knowing whether or not it is actually correct.

Update2

what if [...] developer frequently changes the business domain he is working on?

That of course means that a large part of the investment (of your time and your employer's money) to gain your business knowledge is lost :-( If you know it is going to happen, of course it may not be worth digging too deep into a specific domain. Note however that domains are not totally different, there are fundamentals which can be reused between different domains. And most importantly, the domain driven design approach you gain is reusable.

Community
  • 1
Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • 1
    @Peter Thanks for updating the answer. I have a further question. I assume that this answer, as well as others, assume that developer will stick to one business domain, what if that is not the case that is when developer frequently changes the business domain he is working on. I am not sure about the rest of world, but this is very common in India. For eg. just last year I switched from CAX domain to Marketing domain, and can well switch over to other domain. – Gaurav Feb 24 '11 at 09:41
  • 2
    @Gaurav, that of course means that a large part of the investment (of your time and your employer's money) to gain your business knowledge is lost :-( If you know it is going to happen, of course it may not be worth digging too deep into a specific domain. Note however that domains are not *totally* different, there are fundamentals which can be reused between different domains. And most importantly, the domain driven design *approach* you gain is reusable. – Péter Török Feb 24 '11 at 10:10
  • @Peter Thanks again. I would up-vote your answer, but apparently you can only up-vote it once (stupid rules). One more if it isnt too much of a bother can you incorporate your comment in your answer. – Gaurav Feb 24 '11 at 10:21
  • @Gaurav, done, glad I could help :-) – Péter Török Feb 24 '11 at 10:26
  • And the reason for the downvote is ...? – Péter Török Feb 24 '11 at 11:06
  • It wasn't me, someone having a bad day most probably. – Gaurav Feb 24 '11 at 12:22
  • @Gaurav Great Question from the answer! +1 for that. – Karthik Sreenivasan Jan 23 '12 at 07:24
  • @PéterTörök - Great answer. "That of course means that a large part of the investment (of your time and your employer's money) to gain your business knowledge is lost." Thanks. – Karthik Sreenivasan Jan 23 '12 at 07:25
2

I've been working in the banking sector for over ten years developing trading applications and agree that it's important for developers to understand the business well. But time and time again, during interview processes, if the person doesn't have good knowledge of the business, they don't get through the door.

This has led to a substantial number of critical applications and systems being developed by these people with strong business knowledge but weak to mid level technical skills. These systems always end up being designed badly which constantly crash, riddled with bugs, don't scale, almost impossible to fix without breaking something, and that's if the project doesn't end up getting cancelled due to insufficient technical skill to actually get it into production.

Martin Cooper
  • 31
  • 1
  • 1
  • 3