Indian Computer Science (CS) & Information Technology (IT) Academic Reform Activism Consolidated Blog Document


Programming: Practical Solution Mindset vs. Scientific Mindset



Download 1.98 Mb.
Page51/87
Date04.11.2016
Size1.98 Mb.
1   ...   47   48   49   50   51   52   53   54   ...   87

Programming: Practical Solution Mindset vs. Scientific Mindset


Net url: http://eklavyasai.blogspot.in/2011/10/programming-engineering-mindset-vs.html



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".



6 comments:

Rajendra S. Chittar, October 27, 2011 at 6:41 PM

I think it is not fair to break programming into any categories. The analogy of the car does not hold. I may not know how my car works - but driving it safely without harming anyone is completely my responsibility.

The ultimate aim in programming is to know the answer to the following questions: If my software works, I know why - if it doesn't, I know why.

That guarantees delivery of bug-free software optimally - within budget and without an orgy of testing.

All you need is discipline and to be able to give the answers mentioned above - at every statement that is written in a program. And so, step by single step - the whole program gets done elegantly.

Any good theory - and that of programming is certainly one - is eminently practical.



Eklavya Sai Maalik, October 27, 2011 at 10:36 PM

"Guarantees delivery of bug-free software optimally" - I think it is too idealistic and impractical a goal for most application level programming work being done today. The cost and time involved will be unacceptably high.

As I understand, for bug-free software delivery we will have to look at "Formal Verification".

For mission-critical software work, formal verification could be made mandatory. As the wiki page on Formal verification, http://en.wikipedia.org/wiki/Formal_verification, states, "At present, formal verification is used by most or all leading hardware companies, but its use in the software industry is still languishing." It further states, "Formal verification techniques prove out to be highly useful in the area of Medical science where life of a human being is at stake and accuracy of the algorithm used, for example for operating on a patient, is the most important and with in the area of aviation industry where errors are not acceptable. As of 2011, several operating systems have been formally verified: NICTA's Secure Embedded L4 microkernel, sold commercially as seL4 by OK Labs; Green Hills Software's Integrity operating system; and SYSGO's PikeOS."

It seems that Windows, Linux, iOS, Android etc. all are not formally verified. When the OS and the compilers/interpreters are not formally verified how can software written on top of them "guarantee delivery of bug-free software"?

In application software world, including the fast growing phone and tablet app. market, guaranteed bug-free software approach for all the applications may be just way too impractical. 

I think the choice should be given to the users. Let developers who have developed "guaranteed bug-free software" apply that label to their software and let them have no "use at your own risk" warranty, which is what we all say Yes to when installing all kinds of software including the Operating System on our PCs or smart phones or tablets. Other developers can develop software like it is done now and have a "use at your own risk" warranty. Let the users choose what they want. 

BTW the count for iOS and Android apps, according to a research report published on Oct. 24th 2011, is 800,000!!!! See Android Market App Downloads Jump Over iOS: ABI. I would be surprised if even one of these 800,000 apps is "guaranteed bug-free".

Rajendra S. Chittar, October 28, 2011 at 7:35 AM

A question: Take a compiler in any language - say the simplest of languages "C". How does the compiler writer verify that it compiles correctly for every C program? BY correctly - I mean - if the program has a syntax error then it correctly points out the error - if the program has no syntax error then it correctly translates it to the assembly level (i.e. faithfully reproduces its intent in the lower level language).

Is this task ever possible? How long would it take?

There is a level of formal development called "Design by Contract" that is not overly formalistic but something that works at the level of "Function Prototypes" in a C-like language. And writing correct software can be done within budget and time - and has been. It is eminently practical.



Eklavya Sai Maalik, October 28, 2011 at 1:09 PM

I think a compiler is very different from application software as the compiler is a 'fundamental' tool used by applications developers to create their applications. It would be wonderful if all compilers are guaranteed bug-free. However, I am not sure how many compilers meet that standard. I don't think any of the heavily used 'C' compilers like gcc are guaranteed bug-free. It would be wonderful if it approaches "guaranteed bug-free" standard as close as it practically can.

Here is an interesting article on compiler correctness: The Future of Compiler Correctness (dated Aug. 2010). Some interesting excerpts from it:

"Verified compilation is the gold standard. It sets a very high bar, requiring a mathematical description of the source language, a mathematical description of the target language, and a machine-checkable proof that all programs in the source language are correctly translated into object code."

"Although high-road (verified compilation) topics have been studied by the research community for many years, only one verified compiler has ever been produced that I would call useful: CompCert, from INRIA."

"Although vendors test compilers before releasing them, the kind of testing that matters most is testing through usage: does the compiler, during a multi-year development cycle, show itself to be free of crashes and to reliably produce correct object code? Of course, the important thing is not to have a correct compiler — these do not exist — but rather to have a good idea of the situations in which it is wrong."

"To summarize: we are creating life-critical systems using tools that demonstrably contain silent wrong code bugs. We are comfortable doing so because we test these systems heavily, because this methodology has worked in the past, and because we don’t have a better alternative."

-- end excerpts --

The entire article is about compilers used for safety-critical or otherwise-critical systems (mostly embedded, it seems). And here too, as of last year, the article states that verified compilers are not used.

So, it is no surprise that for non-mission-critical applications development "verified software" or "guaranteed bug free software" is, as of now, quite unknown.

Read up Wiki Design By Contract. Sounds interesting. But seems to be limited to contract details for methods of classes. Proof of correctness of the code that goes into the method does not seem to be covered.

You wrote, "And writing correct software can be done within budget and time - and has been. It is eminently practical." I have almost zero exposure to the area of "Proven Correct Software Development". But if what you have written is true, why do we not see "proven correct software" being provided, at least, by software majors like GNU, Microsoft, Oracle, IBM etc.? If the majors are not able to do it there must be some practical issues as mentioned in "The Future of Compiler Correctness" blog post. Can you provide examples of "correct software" which is widely used and is being offered by major software companies?

If somebody comes up with some breakthroughs in future that enables everybody to easily develop "guaranteed bug free software" within acceptable time that would be truly wonderful.

Rajendra S. Chittar, October 28, 2011 at 1:31 PM

The work we did when we put our patent to use in TechM - 2 projects - a highly optimising compiler for C, and autoconversion of Pro*Pascal to Pro*C. This was a project for a Defense application and the concerned department (one of the most stringent in the world) took our compiler on a 4-month test ride at their cost but found no bugs. In the Pro* conversion - one million lines of auto-converted code passed the most stringent tests within 2 weeks.

Our strategy - as per our patent - was to build up a language from its building blocks which are handfully finite. And then each is specified and written according to design-by-contract. Once these are verified to be true - then any programming constructs which is a composition of these blocks, is correct by design.

Unfortunately, being patent-protected and also protected by strong NDA - as both were mission-critical - these details could not be published. You will have to take them on trust - or leave it there.

The practical issues for me are excuses. One need not go the whole-hog of formal methods - even rigourous arguments in favour of program construction will do. Design-by-Contract is what we have used - and used it practically to great results for quite a while now.

Eklavya Sai Maalik, October 28, 2011 at 10:44 PM

It is very good that you have direct experience of using Design-By-Contract to construct verifiable software. Wonderful!

I browsed a little to see whether it is popular. 

Design-By-Contract by Google (Sep. 2011). The article states,
"Design by Contract received a lot of attention when it was initially released, but it has never become a significant approach in most languages (the most obvious exception is Eiffel, which was built around Design by Contract).

Several libraries have been introduced for using DbC in Java, but none ever gained mass acceptance. However, a new library called Contracts for Java has been introduced by Google. With Google's weight behind it, perhaps this implementation will finally bring Design by Contract to the attention of the general Java community. "

Apparently it did not really get adopted by significant number of developers - perhaps there are some issues with it - or maybe developers just don't like it. You cannot force things down developers' throats - these features have to be sold to them.

Maybe Google's "Contracts for Java" will do the trick of attracting developers. Let's Wait and Watch.

Microsoft's support for DbC (article date July 2011). So MS is also providing it. Question once again is whether developers will want to use it.

I am reminded of usage of Assertions in VC++ projects a decade ago - Wiki Assertion. MFC (Microsoft Foundation Classes) code used it quite heavily. Developers could use it if they wanted. But it was not extensively used in any of the VC++ projects that I was involved in. Note that some of these projects had code written by pretty capable guys from the West. Why was it not used? I really don't know - Maybe it was too much of a hassle to have so many assertions all over the code. And you could have a bug if your Assertion itself is incorrect.

As I am not into DbC I do not want to hazard any guesses as to why it has not clicked with most developers so far.

Monday, October 24, 2011




Download 1.98 Mb.

Share with your friends:
1   ...   47   48   49   50   51   52   53   54   ...   87




The database is protected by copyright ©sckool.org 2020
send message

    Main page