Three Types Of Science And Engineering

Scientists attempt to understand. Engineers build. In my opinion, there are three broad types of systems that scientists and engineers work with.

Physical systems are decomposable. The whole is equal to the sum (or some known function) of its parts. Scientists and engineers working with physical systems can decompose a system, study or design its pieces, and then mathematically infer things about the system from the pieces.

Repetitive processes are repetitive :). Repetitive-process scientists can conduct experiments by changing something and running the process again, to see what happens. Repetitive-process engineers attempt to maximize output and minimize defects. Manufacturing processes and assembly lines are examples of repetitive processes.

Synergistic systems are different from the sum of their parts. Scientists and engineers cannot infer about a whole synergistic system from its pieces. And because of chaotic effects, processes involving synergistic systems are often not repeatable enough to conduct valid scientific experiments.

Examples of synergistic systems are businesses, economies, political systems, and, in my opinion, software programs and software development teams.

Knowledge gathering (scientific) approaches that seem to work for synergistic systems tend to be experience-based approaches. Best practices, lessons learned, case studies, story gathering, and pattern mining come to mind. Think of many non-controlled, non-repeatable experiments happening all over the world. How do you capture knowledge from non-controlled, non-repeatable experiments?

What about engineering approaches? How do you build a good software development team? How do you build a good program? Evolutionary approaches, with a minimum of design up front, are used by some for building synergistic systems.

Please give an example of a "Physical System" that meets the definition. (I ask because I believe there are none. There are many where the decomposition is helpful, but none where it actually works. There are always synergies.

: We are probably talking about two different things here. What I was referring to is, for example, that the weight of an airplane is equal to the sum of the weights of its parts. The drag of an airplane is equal to the sum of the drag of its parts. The lift of an airplane is equal to the sum of the lift of its parts. (Engineers often use calculus to integrate infinitely small parts, but integration is basically summation. Engineers also usually sum vectors instead of scalars, but again, it is basically summation). If you decide to add a radar dome to a plane, you can calculate on paper the added weight, the added lift, and the added drag, and see if the plane will still fly. Your paper calculation won't be entirely correct, but it will be very close - close enough to be very useful.

Same question for "Repetitive". They're just mostly repetitive.

: True. Manufacturing processes and assembly lines are just mostly repetitive.

I suggest that these are views of reality, not reality.

: Good point. Making distinctions and grouping things into categories is somewhat arbitrary and artificial. The question is, is this particular arbitrary and artificial view of reality useful? To me, at least, and today, at least, it is.

This perspective is one that rings true to me right now. I also think it is useful to recognize that synergistic systems cannot be understood by analysis of the parts.

It is however very hard to build synergistic systems in today's environments. Complexity and uncertainty are hard to deal with. I see scientists and engineers retreat into their areas of expertise. I do it myself; this is how I am measured in my job! I find businesses fragmented and not able to listen well enough to each other to even glimpse a view of the whole.

Incremental approaches certainly help. I see a need to balance a vision of the whole with understanding of an incremental part. A UserStory works better than a component. I see this as a thread in a tapestry compared with a patch in a quilt.

We need to be agile to deal with the unpredictable nature of these systems (AgileAlliance). For this reason, I prefer the term OrganicVsEvolutionary as it implies we are not always in control of unfolding circumstances.

I'm currently trying to communicate this view of reality to business stakeholders. I want to build systems, I want to be honest about what I think I'm building, and I need a budget. Hard to sell the idea that we are not really sure what the delivered system will be! Any ideas to share on how to do this? Don't do it.

What tools and approaches have you found useful in building synergistic systems?

I believe almost all software programs, and all softare development teams, are synergistic. So to me your question is the same as What tools and approaches have you found useful in building software systems and software teams?

Tools I find useful for studying such systems are: case studies, lessones learned, best practices, patterns, collecting stories, and collecting insights. One specific practice that helps me is to occasionally squish what I have collected into a fixed size list (see CollectingSeashells).

One tool I find useful for building such systems is an iterative/evolutionary/organic approach, using fixed time intervals.

These two tools, the fixed size list (for science) and the fixed time interval (for engineering) somehow add a little bit of black and white to the grey fog of non-physical-system, non-repeating-process, synergistic science and engineering.

I'm not so sure that the definitions are quite so clear cut.

In many ways software systems are decomposable and much can be learned about the whole through the study of the parts. In fact, this may be the only way to address any complex system. We also expect software systems to be very repetitive. If an input does not consistently return the same output, we consider it a bug. I think we do fail to consider the synergism in software systems and often assume that if the software does not do it, it will not happen and that we should prevent anything outside the system from handling exceptions.

I feel certain that someone more knowledgeable in the physical sciences or manufacturing would challenge the assumptions made in those areas as well.