The best data modelers resemble good lawyers; at least, one occasionally hears such complaints from business people. Data modelers parse statements and break down ideas to an extra fine level of granularity, driving to the heart of a matter by exposing the primal concepts and dependencies. Similarly, the best developers work like the best detectives. People often think that good developers structure modules and components in an efficient manner; and while they do, that particular outcome results more from a symptom than a cause. Regardless of how structured things appear, the best developers investigate the inner workings of their artifacts, determining what works as expected and what still appears suspect. In performing such investigations, they often find and correct delicate issues long before exposing such errors to anyone other than the developers themselves.

All developers bear responsibility for understanding the processes they develop. Generically speaking, virtually every process takes one or more objects in one state and transmutes them into other states and/or other objects, instantiating each object as a collection of data items and values. Therefore, in comprehending the defined functions, a developer must acquaint herself with the data coming in and the data going out, which means that a developer must understand the expected results of the processing. A developer who truly understands a process must, almost by default, truly understand the data as well. This understanding allows for anticipating the expected results and discriminating between proper test cases. The aware developer recognizes accurate output after processing completes. While unclear understanding can sometimes occur, the developer should continue asking questions directed to achieve clear acuity, regardless of the perceived annoyance this approach may provoke from others. A natural part of the job involves rooting through the requirements and source data when executing development work. Because of the greater complexity occasionally encountered within some processes, people at times may experience a slower learning curve while attempting to completely understand the subtle state changes of all the data involved. Additionally, people often dismiss the profound difficulties of interpersonal communication. However, “good” developers should have the skills to determine when a process works correctly or not, and to discern this issue on their own, in most circumstances.

A developer should have a level of comfort regarding the successful functioning of a process, before turning code and results over to others for testing. Unfortunately, this does not mean that a post-developer testing cycle should never encounter errors. But it does mean that most often the errors encountered should come from communication issues and not raw programming miscues. If a developer misunderstands requirements, then only external testing most often can identify such problems. Or, if the user community has misstated their objective or requirements, formal acceptance testing will help uncover such issues. But developers should not assume that the existence of an external tester usurps the need for understanding what the product does, nor should use of external testers default as an excuse for slipshod craftsmanship. Knowing the process should allow developers to understand the processes’ data expectations. Such understanding provides for recognizing correct or incorrect results. If developers find themselves unable to determine whether or not a process works, they need to continue probing for knowledge.

Certainly, individuals assimilate knowledge at different speeds and adapt differently to tasks that vary greatly in degrees of difficulty. Not every developer will achieve an “up-to-speed” standing on absolutely everything all the time, but every developer should actively pursue the attainment of such a condition. Developers either should already know, or strive to know, the processes they develop and maintain. The structured appearance of the developed modules mentioned earlier serves as one of the results of developers creating work in a fashion that allows them to control, test, and debug issues successfully. When overwhelmed by encumbering workloads, simple self-preservation encourages abdication of the objective “to understand all.” Even as a defensive measure, developers who assume this just-do-as-told-without-comprehension attitude ultimately doom themselves to less than “best-of-breed” status within their profession.

About the Author:

Todd Schraml is senior data architect and manager of ETL at Innovative Health Strategies, Inc. He can be reached at tschraml@ihsiq.com.