Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In most places I have worked for, there were no formal System or Business Analysts and the programmers were expected to perform both the roles. One had to understand all the subsystems and their interdependencies inside out. Further, one was also supposed to have a thorough knowledge of the business logic of the applications and interact directly with the users to gather requirements, answer their queries etc. In my current job, for ex, I spend about 70% time doing system analysis and only 30% time programming.

I consider myself a good programmer but struggle with developing a good understanding of the business rules of a complex application. Often, this creates a handicap because while I can write efficient algorithms and thread-safe code, I lose out to guys who may be average programmers but have a much better understanding of the business processes.

So I want to know - How much business and systems knowledge should a programmer have ? - How does one go about getting this knowledge in an immensely complex software system (e.g. trading applications) with several interdependent business processes but poorly documented business rules.

share|improve this question

12 Answers 12

up vote 24 down vote accepted

How much business and systems knowledge should a programmer have ?

As much as is needed to solve the problems of your clients. In some cases, it may be minimal. However in many cases, like the one you describe, it is a lot. As @Rachel noted, the better you understand the domain, the more valuable you are to your employer/clients.

How does one go about getting this knowledge in an immensely complex software system (e.g. trading applications) with several interdependent business processes but poorly documented business rules.

There is no royal road here - it can be a long and tedious journey:

  • read code,
  • write unit tests to understand and document its behaviour,
  • ask for clarifications from team members / users / business analysts as much as you can, both about new and existing features if you feel you lack the background to understand what they are talking about,
  • ask for recommended readings on the domain when applicable (most of the large enterprise domains like finance even have lots of general study material available, but if not that, your company may still have an internal collection of docs/papers),
  • analyse bugs to understand what went wrong - not just the code, but the expected vs real behaviour of the system in this specific scenario.

Note also that these domains are not entirely independent. If you learn a thing or two about e.g. banking, you may be able to reuse bits of it in a gas trading or autorent company next time. But more importantly, embracing and internalizing the customer oriented approach is what pays off. Employers and clients do greatly value that you are willing to go that extra step (or mile) to solve their problems. So it may even help you get your next job.

share|improve this answer
+1: "There is no royal road here" – S.Lott Mar 8 '11 at 14:14
++ for writing characterization tests. You understand the system better and leave behind executable documentation of what you learned. – RubberDuck May 7 at 22:16

Expected: None

Desired: A lot

A programmer who understands the business analytics of a company or industry is much more valuable to that company than an amazing programmer who only knows how to code what he is told.

My suggestion would be to learn whatever you can about the industry you are programming for. It will increase your value to employers in that industry and is a great selling point when you are looking for another job.

share|improve this answer
Thanks Rachel. My problem is, I do understand the industry and domain but don't understand how the granular business rules are "implemented" by the system. A lot of "what if" queries from business users require an in depth knowledge of the system and how it behaves. I realize that there is no easy way to master these but hoping to get some tips. – Rahul Mar 8 '11 at 13:47
@Rahul Sometimes thats part of the job. The fact you're trying to learn is a good start. The more you know, the more valuable you become to your current employers and to future employers within the industry. – Rachel Mar 8 '11 at 13:53
I wouldn't say that doing no analysis is "expected". I would say that doing no analysis is "tolerated" by many companies. Some, however, don't tolerate the "pure technician" approach and absolutely require serious business analysis from everyone involved. – S.Lott Mar 8 '11 at 15:15
@BillThor: I don't see any difference between "programmer" and "developer"; I can't understand your comment. Can you clarify this distinction? – S.Lott Mar 8 '11 at 16:34
@S.Lott: A programmer takes specifications and turns them into code. They wouldn't be expected to generate requirement or specifications. From a developer, I expect a wider range of skills including requirements gathering and specifications generation. A developer should be able to handle a project on their own, or at least with minimal help. From a hiring perspective one intermediate (put your language here) programmer should more or less the same as another; developers should not be as interchangeable. – BillThor Mar 8 '11 at 17:56

You are probably working in a in house IT developer shop. It is a different wold there. Companies with in house developers don't want the best programmer they want a programmer that will add the value they want to the company right now if not yesterday. They don't want to think about the business rules because they expect the developer to know them it's why they pay you. Now is this fair, no but it's how most in house IT shops work. This is because what you do doesn't add in a visible way to the bottom line. You are service to the company.

I have found it to be a deferent in software shops. There are usually people that write up how the software should work long before the design is brought to the developers to code up. Some developers may help in this process but it's not all of the developers. This being said a developer that can understand the needs of the business will usually do better then the guy that can't.

share|improve this answer

Depends upon the company and the group you are working with. If you are working in a well organized software development organization then you can expect that very little system and business analysis will be expected of you beyond what might be needed to clarify your current task. If you are the sole developer or working with a small group of developers then you can expect to do a lot of it because the company is unlikely to hirer a dedicated individual for work that they see as part of software development.

share|improve this answer

As the lowest common denominator, I agree with @Rachel that there shouldn't be an expectation that a programmer have sufficient business knowledge so as to be able to write up the requirement. However, we live in a fickle world full of maddening expectations, and often a developer who can translate the incompatibilities and driving forces between the business needs and the technological capabilities (maybe feasibilities is a better word) will be the expectation.

While it shouldn't be an expectation it often is. There are many occasions where a skilled developer will lose out to a lesser skilled developer because the people making the decisions can't determine those levels of competence. Who is to say programmer A is more technically proficient than programmer B when manager C with an economics degree is making the choice?

It also boils down to a touch of laziness. If you don't know the business and someone else does, they won't have to teach that person the business part of it. It's already your responsibility to make sure you have the technological know-how, but now they have to train you on the business as well. That just creates more work for them, so it's simpler to use prior business knowledge as a preliminary discriminating factor.

share|improve this answer

It depends.

The questions about what a developer must or must not do are frequent. Some will ask if HTML and CSS code must be written by a developer or a designer or a dedicated person, others will wonder if a developer must know and write SQL queries or let this task to a database administrator or an SQL developer.

In general, bigger and better is a company, more there are dedicated persons. This is because a single human can't be perfect in everything, from SQL to CSS. An excellent C# developer can write awful SQL queries, or a highly qualified designer may not know what are CSS sprites.

On the opposite, when a small company can hire only one or two developers, they are expecting to give all the work to those people, since they care more about cost than about quality.

Here, the situation is the same. A company which can afford spending thousands of dollars to hire a dedicated business analyst or a person who will write technical requirements from the not-so-technical wishes of a customer, doesn't need to ask the developer to do this work. On the other hand, when a small company wants a product but don't have too much money, what they will do is to go and see a software developer, show her what they want, and expect that the product will be done from an unclear explanation of a need which can be even unclear to the customer herself.

In all cases, there are domains when it's totally stupid to believe that any developer will be able to understand the business processes and the elements which are specific to the domain. If you are creating a software for a health facility, you can't afford spending five to eight years learning what their personnel know. If you are writing some component for finances, don't bother trying to understand above the minimum required to implement and test the algorithm.

For example, when I worked in the past on a software product which included some calculations for the investment sector, all I requested were the mathematical formulas for the calculations. I didn't care a lot where those calculations will be used, since in all cases, not only I'm not smart enough to understand those things, but also because I find those things totally boring.

share|improve this answer

As stated by @Rob Z, it depends on the company. some companies have separate positions for analysts, and in some companies there is no clear distinction.

From my experience with both type of companies, it's highly desirable that there will be a significant overlapping - either programmers with good business understanding, or analysts with good technological \ software understanding.

share|improve this answer

As mentioned by @Rachel, programmer should know about (Business) Analisys, not just sitting and coding. There is a lot of Analyst / Programmer separation, these days, but, a certain degree of knowing each other functions is required.

I have been in projects where the (Business) Analyst arrives and gives a U.M.L. document to the programmers and say "Do this", but some programmers say "U.M.L., Use Cases, what is that ?".

share|improve this answer

Business analysis is one of the knowledge areas under the Software Engineering Body of Knowledge performing that role is within the scope of our jobs. Programming code is just one of many things we should be proficient at as software engineers.

share|improve this answer

Business analysis and programming are two very different but related skill sets. I have worked with many people who were extremely good at one but not the other.

Understanding the business helps programmers identify specifications errors. But it isn't something I expect. Likewise understanding the current system helps the programmer fit their work into the system.

Agile techniques and in-house development shops tend to be more demanding of developers, and require a broader understanding. In a project lacking business analysts, I would expect the developers to have sufficient business analysis skills for the project. The level required would depend on the skill sets of the users involved.

IT tends to attract people who are more comfortable dealing with machines and concepts than people and relationships. However projects like yours require a mix of both.

Spend some time learning business and systems analysis techniques. As you become better at these skills you find they will take less time. You will also find yourself better able to compete with developers with a wider range of skills.

share|improve this answer

There are a lot of good answers out there. @Erin make a particularly salient point about in-house development. One point I would like to make is that sometimes the business people don't really know what they want, or what limitations they are bumping up against. This is where a Business Analyst provides genuine value. They serve as a bridge between what the programmers can deliver, and what the business needs truly are, not just what they are perceived to be.

The problem with in-house development is that Business Analysts generally don't exist, so programmers are often called on to fill that role. Let me give you a couple of real life examples...

At one medical company I worked at I had the Executive Director walk into my office. Upon walking into my office, he stopped and paused for a long time with a deeply thoughtful look on his face. Then with a sigh, he stated, "You know how we do reports...?". I responded "yes?" His next comment before walking out again was, "we should do something different." The bottom line was that he wanted more value from the reports, but he didn't know what. It took some considerable back and forth conversations to get at what he was hoping for. It could easily be said it wasn't the programmers job to present solutions, but sometimes you don't have a choice.

In my current job I work for a global networking company. In this case there are a lot of very technical people, people who really understand their job and the limitations. The problem I'm presented with as a person building diagnostics and discovery tools, is that much of what they present is over my head. This requires me to try and understand the business processes so that what I produce gives accurate and complete results. Daily I have to learn something new in order just to keep up with them.

Learning about the ins and outs of DWDM systems is a far cry from writing medical billing software and understanding HL7, yet often we are expected to understand what it is that our software does. Not just how it does it. Unless you always exist in an environment where someone that does understand the business processes feeds you what you need to program, then sooner or later you'll have to understand the processes yourself.

share|improve this answer

Learn to draw dataflow diagrams. They are a great way to translate from business-ese to pseudo-code and project plans.

I've based a good part of my career on doing just that. Business people love it.

DFDs can be used to model essentially anything that can be called a system, right down to the electrons.

All you have to do is start drawing and keep at it. Drawing DFDs will train you in everything you need to know about how to do it and why it's valuable.

Get out a piece of paper and get started.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.