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

Have you had any experience in which a non-IT person works with a programmer during the coding process?

It's like pair programming, but one person is a non-IT person that knows a lot about the business, maybe a process engineer with math background who knows how things are calculated and can understand non-idiomatic, procedural code.

I've found that some procedural, domain-specific languages like PL/SQL are quite understandable by non-IT engineers. These persons end up being co-authors of the code and guarantee the correctness of formulas, factors, etc.

I've found this kind of pair programming quite productive, this kind of engineering-type users feel they are also "owners" and "authors" of the code and help minimize misunderstandings in the communication process. They even help design test cases.

  • Is this practice common?
  • Does it have a name?
  • Have you had any similar experiences?
share|improve this question

closed as too broad by Snowman, MichaelT, Bart van Ingen Schenau, GlenH7, Ixrec May 6 '15 at 19:26

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 10 down vote accepted

Though you are describing this as a shared coding session (I can't call it pair programming, as only one person is "driving" - in pair programming, both parties take the keyboard and write code), I would call it gathering acceptance criteria.

That is, you are validating business rules (correct calculations and processes) with the business user (though one with a very technical role, an engineer).

In this case, it translates immediately to written code (SQL), but for many other activities is will not, though there are automated acceptance test tooling for different languages and platforms (I am specifically thinking about the gherkin language and related tooling).

This practice is not as common as it should be, but is gaining more and more followers and those who follow it (getting acceptance criteria in a form that can be executed) find it invaluable as both a tool to communicate with the business and to drive development.

share|improve this answer
At least where I'm at (a small company) we have a lot of communication between the business side and the engineering side, but I feel like having one of the business guys who knows his stuff sit down and walk through code with me line by line would be a waste of company resources, especially given the state of the economy and how it drives businesses to be as lean as possible. If we had more hours in the work day it might make sense, but every hour counts. Just my input anyway. – Ampt Jun 28 '13 at 12:54
@Ampt - have you tried it? If you use executable specifications you can walk them through the specification instead of the code. – Oded Jun 28 '13 at 13:09
I have not tried it, and I'm not saying that it's wrong by any means! You just stated that it's not as common as it should be and I was giving my input on why that might be. I feel that the more communication you have between the business and development side, the better off your project can be. The quality of that communication often defines how good your project is, and by that logic, sitting down with a business person and going over code that they could understand would probably fall into the good communication category. – Ampt Jun 28 '13 at 13:33

Yes. Where I work I do the hardcore programming type stuff, while strategists work on uhm strategy. That is to say I write the programs that implement their trading models.

The key to this is sitting right next to them and understanding exactly what the ideas are, and asking lots of questions about things which may be incidental to them, but important to the execution side. For instance I'd ask about how fast a trade needs to be executed, whether that affects their model. This has a huge impact on how I'll be writing the code. In fact I tend to spray questions into the room as we're sitting there working every day.

There's a two-way feedback. If I tell them some trading scheme is not going to be easy to build, they go back and have a think about which tradeoffs can be made on the decision making side. If they decide their new strategy needs some new feature, I have a chat with them about how long it would take to build and what the potential pitfalls are.

They do code modules that encapsulate some aspect of the trading strategy from time to time, but I massage the pieces together into an architecture that allows us to keep track of all the different strategies as well as backend operational stuff. That way they don't need to know the nitty-gritty of the system.

share|improve this answer

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