0

I am a software developer and several of my tasks include the development of software procedures for posting sales, purchases, manufacturing, ordering activities into general ledger (creation and correction of bookkeeping/accounting entries for general ledger). Usually I have some business style instructions what should be done and I have my own knowledge and experience. But sometimes I receive from business people tasks like "this posting (document Id provided) is not correct, please, check and correct it and check similar cases as well". And then Hell goes loose - I find document with the similar problem and then I navigate further along links and discover new cases of incorrectness, I am looking for more general and more specific cases, some manual corrections I take into account and so and so on. Sometimes I just stop and ask my colleagues to provide some more general rules which all the postings should obey (individually or collectively - as a group or chain of documents), but no one is eager to think about it. E.g. rounding issues can be very hard. Those cents seems to be insignificant, but users are very upset when they appear.

This seems to be more general problem in accounting community - e.g. Google finds practically nothing for queries formal methods in accounting, formal methods in bookkeeping.

Clearly - those rules should be produced by the business people. My question is - how can I encourage them to think more generally and more rigorously, to define not just what should be done but define formally so that all the situations are considered and defined? Or - maybe that is the problem with me (M-theory is my hobby and maybe this can lead to some distorted sense of reality, maybe)?

  • 2
    "Rules" is not the same as "formal methods" - the latter is a very specific thing, so that's probably why your google searches don't turn up anything. Accounting very much does have rules - it's basically what accounting is all about - so if your business people are responsible for accounts but not prepared to think about the rules, I... don't know what to suggest – AakashM Mar 4 at 11:18
  • 3
    The short answer is "you can't". Bean-counters, like people in many other business roles feel that "the help" (in this case SW development) is entirely subordinate to needs and whims of their job functions. Accounting practitioners certainly do think deeply about what they do, but they're not going to give you a seat at their table to discuss it with you at length unless you actually become "one of them". – teego1967 Mar 4 at 11:22
  • I know that the formal methods and formal specification are (Z, VDM, Lotos, Coq-to-Haskell code generation) and I wonder why I can not find how they are applied in accounting: e.g. one is eager to establish invariants and validity criteria (e.g. books should always be balanced) and then one is allowed to code only such procedures whose execution always satisfy those validity criteria. – TomR Mar 4 at 11:31
  • 2
    You mean you're actually developing software without having a clear set of requirements? Well, I never... – Steve Mar 4 at 12:58
4

Identifying the Problems

I see two problems here.

  1. Language - You're trying to apply your understanding of language you learned as a developer to another domain.

  2. Problem Solving - You're expecting your customer to deliver to you both a problem and its solution.

Language

The accountants are speaking Accountantese, while you speak Developerese. They both use the same words but in completely different ways. Your understanding of what formal methods means in a software context is inappropriate to apply to the way an accountant does their work, which is why you're not finding any results.

To exemplify this, you may understand that a liability is generally something bad. In the accounting world, a liability is any debt that has yet to be paid. Your salary is considered a liability from an accounting perspective, but in the software development world that may never cross your mind.

You need to learn the domain specific language for accounting and understand that when you use a certain word like "method" in an accounting sense, you're usually talking either accrual accounting or cash accounting, which describes how money is being moved between accounts.

Learning the language of your customer helps you communicate clearly and effectively without ambiguity or misunderstanding.

Problem Solving

I would suggest bringing a business analyst into the mix. They're also called systems engineers, requirement engineers, or technical analysts. They're people with communication skills to identify and describe problems by speaking directly with key stakeholders and users, then translating their findings to software developers to describe how the software should work. Different fields identify them differently, but no industry I've ever worked on has a software developer fill that role.

A skilled business analyst can assist in defining all of a project's functional and non-functional requirements, and assist in gathering the input needed for any required testing. They usually also identify any domain specific terms and provide controlled vocabularies to make sure anyone reading their documentation understands how words are being used in specific contexts.

If you can't add one to your team, I would study how a business analyst communicates and defines problems, and the steps they take to create solutions. There are many good templates freely available online that can help guide you in fully documenting what the problem is and how to move forward with a solution.

| improve this answer | |
3

The problem is, they are business people, and not software developers. They know what they are doing, but they don’t know how to tell you.

Your only chance is to sit with them, ask them to explain it, and ask the questions you need to get answered, and hope for the best. Then consider there are things that are so obvious to them that they don’t even mention them. Try to catch these things.

| improve this answer | |
  • I guess - it is called 'Cognitive Task Analysis' - but again, Google gives nothing for CTA for accounting. – TomR Mar 4 at 12:43
3

I've had similar problems. Not in accounting, but in other kinds of reporting / counting / statistics.

What I do about it:

  1. be patient with the users. Do your best to speak their language.
  2. ask them to spend time showing me what change is needed. I try to get them to show me at least two or three examples of the change.
  3. think up some edge cases.
  4. build a prototype and ask them for their time to demo it.
  5. revise as needed.

In the old days of waterfall, an analyst would write the requirements, and a programmer would implement them. You're doing both jobs. The old song says "got one foot on the platform, the other on the train." That's the truth for business programming.

| improve this answer | |
2

As someone who also works in accounting software development I can feel your pain.

Accounting is a domain which is far more complex than it seems at first glance. It follows a logic which is internally consistent but still completely incomprehensible to outsiders. Fortunately it's also a domain which puts a lot of effort into formal correctness. So if you actually do understand the domain, then the difference between "correct" and "incorrect" accounting is actually pretty clear.

What I found to be very important is to actually understand the domain. Teach yourself the language and the processes. The more you know about accounting, the better you understand what your users are actually complaining about, the easier it will be for you to tell the difference between a correct and an incorrect booking and to implement business rules which prevent users from making incorrect bookings. Fortunately, double entry book-keeping, the standard book-keeping system used by businesses all around the world, is pretty well documented. There is a lot of literature available which you can use to teach yourself the basics.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .