Function vs Process

The Yin-Yang is a well-known concept in Chinese philosophy that represents interdependence of opposite forces of nature. Ideally, these two forces will complement each-other, building a perfect harmony. Similar forces exist in business. When used in balance, these forces too can bring perfect harmony to an organization. These forces are called Function and Process.

Function is about the final result, it answers the question 'What?'. The functional approach is to focus on the end-state by defining dependencies and goals. People who prefer the functional approach can be good leaders. They excel at defining goals, but they must rely on others to find practical solutions to every-day problems. In software development, functional people can be recognized by their preference in programming style. They try to use a functional style in any language, but they tend to prefer pure functional languages like Lisp, Clojure, or F#.

Process is about methodology, it answers the question 'How?'. The procedural approach is to focus on algorithms by defining workflows and constraints. People who think in terms of processes can be good project managers. They excel at solving problems, but they need help in defining goals. As software developers, such people typically prefer the object-oriented programming. They fight complexity using encapsulation. The procedural developers have more languages to choose from: Java, C++, Pascal, C#, etc.

There are many business cases when one of these styles works much better than the other. For example, maintaining client relationships and product management are better suited for functional people. Too much process may seem to be too bureaucratic and make clients feel uncomfortable. On the other hand, program and project management are for procedural folks. We all have been on a project where people are stuck in back-to-back meetings, confused by poorly defined roles, and stepping on each other's toes. These are the signs of functional people in charge. Tasks like database modeling and writing SQL queries must be assigned to functional people. The procedural approach for such tasks may take forever and the result will be far from optimal. The same miserable result can be achieved if you put functional people in charge of process automation and optimization. This is because a function person will rely on efficiency of processes to achieve goals while a procedural person needs to have clear goals to design an optimal process.

Functional programming has recently became re-popularized. It provides very elegant and powerful tools, but if you use them on a large project, you may end up with an inefficient and unmaintainable code base. The object-oriented programming languages are perfect for large projects with many developers. However, they are not suited for handling conflicts of concurrent computing and may cause serious problems that are very difficult to detect and debug. A functional person likes brainstorming, discussions, and collaboration. A procedural person wants clearly defined scope, deadlines, and autonomy. Procedural people like to do everything themselves, while functional people prefer to delegate. Procedural management style is to define roles, responsibilities, and setup rules. Functional management style is to set goals and rely on the team members to find the best way to achieve them.

Understand this - both functional and procedural people can screw up your project pretty well. The Process and Function are not virtues, they are states of mind. People "misplaced" in such roles are essentially forced to swim against the stream. They may feel like nobody listens to them even when they know a better way to do something. People who are able to use their native style in full capacity feel empowered and respected. Process and Function are able to complement each other on all level of business hierarchy. Any organization that recognizes and embraces this particular diversity will have better chances for success.

Sergey Kucherov