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?
0
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.
3
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.