Don t Split the Business Logic

Dont Split the Business Logic

Todays corporate programs are quite large, primarily because the typical business function being automatedsay, using Radio Frequency barcode to wand units into cartons in a distribution centeris a complex job requiring several thousands of lines of source code. It is simply easier, and perhaps more effective, for the programmer to put all of the core or mainline programming logic that implements the business function into one large program than it is to split the business logic into many fragmented pieces and programs. Thats not what they teach you in IT school, but thats the way it really works in corporate programming.

The programmer should not split one logical program of a business function into 50 parts , calling the 50 sub-programs from the main program and then having the called programs call more programs down many levels (in the call stack). If the business logic, such as validating a customer number, is truly unique to the program, then put it in the program, not in a sub-program. My mentee was faced with supporting a complex, vendor-supplied package that had up to eleven levels of called programs (in which each program calls another program, which calls another programthe process repeating eleven times). He was (understandably) mystified, even as to which program was being executed.

My answer to my mentees question What do I do now? was to show him some simple auditing techniques that helped him deal with the complexity of the programs he had to change. (Youll find those techniques in Chapter 16, Master Millions of Lines of Complex Code.) Then I showed him how to use the computers Find function to search through millions of lines of his companys production source code to find how another programmer had solved the same problem.