Process over programs

Software development, at heart, is the discipline of modeling business logic (or il-logic, if you will). The classic steps go something like the following:

  1. Document the existing process, such as an accounting form or communication need between entities
  2. Determine if there are any existing IT system driving the process
  3. Build a prototype or story board a solution, accounting for #1 and #2
  4. Supposing that the prototype solves the problem (or least makes thing better), go ahead and build it using whatever design/code methodology that suits the project.
  5. Deploy the system to production and commit to caring and feeding for it until doomsday or the process needs revision, whichever comes first

While this is a fine way to build software, it isn't a fine way to solve core problems. For that, I suggest we add step 1.5: evaluate the process.

Business logic -- those policies and creeping bureaucracies of life -- have a way of accumulating steps. Like evolving strands of DNA containing ancient, yet unused, instructions for living organisms, our business processes easily store redundancy and awkward instruction. If you have ever stood in one line at the Department of Motor Vehicles to register and proceeded to stand in yet another line to pay, you have personally felt the pain of poor process.

Every responsible software developer should ask pointed questions about a process. Why do we need the form printed in triplicate? Who uses each copy? When we store the whatsit field, who uses it? The answers may surprise you.

I'll protect the names of the guilty, but I've personally witnessed processes where one department would create a data export with special formatting, only for the next consumer of the data to strip the formatting. If you asked both parties, they would assume each other wanted to the extra formatting in place. After all, they both had processes in place to insert or remove it.

Another example comes from a software system that printed four copies of a document. One copy went to accounting, another to marketing, another to legal and the final into the trash. Nobody could remember why the fourth copy was produced by the software, but the responsible choice for any developer faced with this situation is to first streamline the process before replicating it.

Fans of the Agile Manifesto, of which I'm one of, should know that this view in no way conflicts with the dictum to value "individuals and interactions over processes and tools." In truth, improving a process before modeling it with code is a humane response to the needs of users. Software engineers do a disservice to everyone when they model a process without reflection.