Programming: Practical Solution Mindset vs. Scientific Mindset

Last updated on January 6th 2013

Note: At the time I wrote the original version of this post I was not well versed with efforts of persons like Prof. David Parnas to bring a professional engineering approach to the teaching and practice of software design & development, and name that as "software engineering". So I casually used the term "engineering mindset" in the original version of the post when I wanted to refer to a practical solution approach. I have now (Jan. 5th 2013) changed the post to use "practical solution mindset" instead of "engineering mindset".

I presume that, say, with the civil engineering approach in the Western world I will get a level of guarantee of the design & construction of a building by a certified & licensed civil engineer. The engineer would have used standard principles for the design & construction which can be verified by other competent authorities. In India, I believe it is quite similar, except for the absence of licensing. So when one uses the term "engineering approach" or "engineering mindset" in the context of software, a knowledgeable about engineering reader will presume a similar application of well defined & well understood design principles and a level of guarantee of the solution.

I am a technologist/technology solution provider as against a 'computer scientist'. So I use a "practical solution mindset" as against a "scientific mindset". What do I mean by these terms? Well, in my terminology, a "practical solution mindset" applied to software focuses on how to provide a software solution which:

a) Satisfies the users in terms of functionality, efficiency and user interface quality. Note that the efficiency may not be the best possible efficiency but what is acceptable to the user.

b) Gets done with optimal resources in terms of manpower, time and money. This will typically involve use of existing software components with or without modifications. Why reinvent the wheel?

c) Provides acceptable standard of design & documentation for maintenance and enhancement of the software solution over time.

There are some more factors too like reasonable protection against technology obsolescence but the above are the critical ones.

For the "practical solution mindset" person "need to know" is an important principle. So a programmer/designer may not need to know about implementation details of, say, a collection class like vector. He simply needs to know the programming interface and the pros & cons of the vector class. He "need not know" anything whatsoever about the inner workings of the vector class. But if he does know, it may be of "insightful" help.

To explain this "practical solution mindset" to students that I taught component-based-development type of programming courses (e.g. Open Source Web Technology using Linux, Apache, MySQL, PHP, Joomla, Moodle, Al Fresco etc.), I would use the example of driving a car. You "need to know" how the user interface (driver-interface rather) of the car operates the car. The ignition, steering, accelerator, brake & gears (if manually operated gears are used) is what you "need to know". What is under the hood is "not necessary to know". But if you know how the stuff under the hood operates then you may be a better driver and if the car breaks down you may be in a position to fix it. Whereas the driver who knows nothing about what's under the hood is completely dependent on somebody else, say a mechanic, to fix the car in case of a breakdown.

But if you have limited amount of time to learn, it makes sense to first learn what you "need to know" like the driver-interface of the car. Then, if time permits and you have the inclination, you can learn the "under the hood" stuff.

The "scientific mindset" person, on the other hand, focuses on the Whys and inner-working-Hows as well as the outer-Hows. He wants to know why a vector class operates the way it does as well as its innermost working. He is quite uncomfortable with a "you don't need to know" attitude or answer. He wants a "building block by building block" learning experience. He wants to be able to answer any questions no matter what the level of detail about any software solution he provides.

I feel that such a "scientific mindset" can be a serious problem for a component-based-development software solution approach. The problem really is the available time for learning or for providing a solution. It is like the time involved to learn driving can be orders of magnitude more than it is now if a student insists on knowing everything about what's under the hood of a car before he learns how to operate the user-interface of the car.

But such a "scientific mindset" may be essential for developing the core building blocks of software like an Operating System or a Compiler or defining a new computer language or writing a systems library of components. The person working on such software would need to write, say, a new vector class from scratch with as close to best-possible-efficiency as feasible. Of course, at some point he still will not know the details. I mean, he will operate at a lower level of abstraction as against a component-based-developer. But nonetheless he too may have a "need to know" approach for lower levels of abstraction like Computer Language or Operating System Services for memory allocation or how the processor's instruction set executes the services that he requests. And it goes on & on, processor's microcode, the electronics on the processor, NAND gates, the transistor ...

However, IMHO, the lower levels of abstraction like a computer language or operating system services are very well defined and stable as compared to higher levels of abstraction like Joomla components. And so the "scientific mindset" student/software developer struggles to come to terms with developing software solutions using fast-changing and not-so-well-defined components like Joomla components (fast-changing meaning rapid new versions with older versions changing only for bug-fixes). He feels that he has just put some stuff together and even if works and satisfies users, he cannot explain all its "inner" workings and feels that it is not a "scientifically" done job.

But the real world is driven by how society's needs are satisfied quickly and at acceptable cost. The "practical solution mindset" is what delivers tremendous value-for-time-and-money to a wide range of non-mission-critical software needs of society. Component-Based-Development delivers solutions quickly and at far lower cost than reinventing-the-wheel solutions. Yes, there may be a few bugs and crashes, but since the software is not-mission-critical, users are willing to put up with a certain amount of inconvenience. [If the inconvenience becomes too much they tend to switch to some other solution]. So component-based-development model thrives and, in turn, "need to know" practical solution mindset software professionals & solution providers thrive.

The "scientific mindset" software professional has his niche mission-critical and systems software development areas where he thrives. But that is a much smaller part of the worldwide software "action".