A recent post on Coding Horror on pseudocode reminded me of my work as an internal auditor. You might think itâ€™s strange that a blog post on a programming/development technique would make me think of auditing â€“ well, youâ€™re right. It is a little weird. But hear me out.
Pseudocode is called that because itâ€™s not really code. It looks similar to code but itâ€™s written in plain English rather than something the computer can understand. The point of it is to develop the logic of a program first before getting into the nitty-gritty of actually creating something workable. Youâ€™ll be better able to see and fix high-level problems at this stage than you would be when youâ€™re wading through a morass of source code.
This to me is a lot like documenting a transaction cycle from scratch. You start at a high level and just get the bare bones down on paper to understand it from that perspective. You have discussions with the staff involved at each stage and understand from their point of view the role they play. As you have these discussions youâ€™re getting deeper into the step-by-step procedures involved. Youâ€™re fleshing out the documentation and starting to identify the key controls.
Customer order received (on account) If customer exists in system If customer is below credit limit Enter order Else Return to customer account manager Else Send credit application to customer Receive complete application If customer credit history is good Set up customer in system Else Reject customer order
From there you delve a little more into the details. How are orders received? Who receives them? Who sets up the customer in the system? How is credit checked and by whom? Answering those questions will illuminate the controls and the segregation of duties within the process, and in a way you start to move from pseudocode to source code. You canâ€™t test a transaction if itâ€™s in pseudocode stage like you canâ€™t run pseudocode in the development process. Once you have a testable, documented process itâ€™s good to go.
So there you have it. There is a connection between the type of thinking required of a programmer and that of an auditor. This must be why I was able to make the transition from the Computer Science program into the Accounting program at university!