Can we conclude about writing perfect software ? With no bugs !

Lets answer the question "Why cannot we write perfect software ?". We all are periled by this notion of generating digital junk in the form of software code which is always riddled with bugs of one form or the other. I think its important to appreciate the fact that "humans cannot write perfect code". And lets not take my word for it and provide a proof for it

Theorem 1: "Humans cannot write always perfect code"
To prove this ->

• a. I will explain the "Emperical model of probability".
• b. Derive some "Results from the emperical model".
• c. Explain "Converse of -> Results from the emperical model" (converse of conclusion drawn from step b).
• d. Proof Theorem 1 form step a,b,c. (mostly c)
  
• e. Answers to critics for the above reasoning.

a. Emperical model of probability.

Ever wondered why is probability studied ? Is probability an study and analysis of a random processes/experiments ? Study of anything that is random is by defination - futile. For example if you are randomly going to be picked up for security screening at an airport then, any study about ways to avoid the security screening is quite dumb. Also another iniutivie example is "knowing that the probability of a getting a heads in a coin toss, does not help u any in winning any coin toss".

Well probability existed as field of mathematics and is quite successful at it. So something is flawed in the conclusions drawn in above paragraph. To understand the flaw we need to understand the emperical model of probability. Well to conclude that "probabilty is a study of random experiments" it was totally wrong.


Probability is the study of "long term stability of outcomes of an random experiments". And it turns out that this long term stability is quite deterministic and not random. What is long term stability of results ? It means taking a 1000000gazillion experiment of coin tosses and then measuring how many of them resulted in heads will tend close to the result 1/2. I use the words "tends close to the result 1/2 or 0.5". As it turns outs results tend more and more closer to .5 as the number of experiments increases from 100000gazzillion to 100000trazillions so on and so forth.

Good ! so now we know what is probability all about and for the record - it does not help u win any lottery tickets or coin tosses. Sadly but true most of what i was taught about probability had all about winning lottery tickets, card decks and tosses.
( Just proves that explaination of any mathematical model is worthless if its not backed up by an emperical model).


b. Results form the empirical model.
------------------------------------------
The take home point from the above paragraph is.

b.1. Probability is not analysing something random.
b.2. For probability to make "MORE" sense you need and infinitely countable runs of the random experiment.
b.2.1 The conditions in the experiments have to be deterministic and same on all run. (otherwise it makes no sense).

I will use the converse of b.2 and b.2.1 to prove our theorem 1.


c. Converse or Results from the emperical model.
---------------------------------------------------------
b.2. For probability to make "MORE" sense you need and infinitely countable runs of the random experiment.
b.2.1 The conditions in the experiments have to be deterministic and same on all run. (otherwise it makes no sense).

Converse of 2.1:

c.1 If you are getting predicatable (converging results) from the gazzilion runs of random experiments. It means that the conditions under which the experiment are stable and deterministic.

(Well think about it-> its quite inutitive dont bring anything complex into mind). This ends the backdrop required for the proof.


d. Proof Theorem 1 form step a,b,c.
-----------------------------------------
Now lets try to model the emperical model of software development.


Software D.E.V.E.L.O.P.M.E.N.T.
The "development" part in software development is a random experiment. You for example cannot control many aspects of the development process like.

d.1. The algorithmic understanding level of the programmer.
d.2. The understanding of the programming model used to implement an algorithm.
d.3. Sometime solutions are based on random algorithms.
I could go on and on and on

So it means that even gazillion runs of a software development process cannot provide help for a probabilistic measure of software quality. (This is based on C.1. We fail C.1 so we fail B.2 and B.2.1). So we cannot have probablistic measures of software quality because the outcomes are based on random experiments with random experiment settings. So atleast we cannot conclude about the probability of writing bug free code.

Hence proved.




e. Answer to critics for the above reasoning.
-------------------------------------------- ------
Always nice to BLAST AWAY SIMPLE critiques against a proof.

Q. Are u dumb to write such a proof ?
A. I cannot conclude on me being dumb. So i cannot answer :). Its all about what u think. Unfortunately interpretation of all sciences become quite subjective after graduation ;).

Q. Well my "hello world" runs perfectly and so hell with your proof ?
A. You for one reason don't appreciate the number of lines of code you executed to get u r moronic "Hello world" up and running.


Starting from
1. Helloworld.cpp
2. Compiler.cpp Linker.cpp Assembler.cpp
3. Loader.cpp
4. XYZ.cpp
5. Microcode.vhdl
6. Solarflares.god

So u see your helloworld is just a simple pimple on the arse of the universe. Most of the components involved in getting your helloworld up and running have one essential property. The property of having infinately countable test runs starting from compiler.cpp to solarflares.god. So its not quite an arguement.

Please read "Reflections of trusting trust - Ken Thompson (its a 3 page blaster)" To see how you helloworld can fail. That with a perspective on security though.

Simplicity !! in Software Engineering.

I have always learnt more than what is taught at academic institutes. This is mostly due to the fact I analyse whats being taught in extreme detail. This excruciating analysis usually means that I do not complete the entire syllabus, but that's the way it is. My analysis usually stops when I have understood the very simple fact on which the academic conclusion/lesson was based. As an example I took a sentence from a software engineering class which states

"Software should be simple"

Is it end of the lesson? Has everything been learnt ? No I don't think so!!!

The key questions left to be answered are

1. Whats the definition of simple ?

2. How do you measure simplicity ?

3. What are the parameters to the measuring function ?

3. How do you apply the concept in real life ?

4. Are there any patterns associated with the application of the concept ? (Patterns, patterns, pattern how much do I love to identify them)

Hmm, now if I pose these questions to people who claim to understand "simplicity" I will get 100s and 100s of variations in answers. Which one is correct ?. Thus I tend to conclude that real knowledge is tested when there are no correct answers and right answers are based on circumstances in which the concepts are applied.

OK, enough of the ramble and scramble. Here is what I learnt today at Carnegie Mellon that is worth sharing. Its a very sweet and simple definition of "Simplicity" itself

Simplicity: Its the art of maximizing the amount of work not to be done to do the "thing right".

Now can we answer the questions about simplicity ? I am quite sure that the above definition puts the practice of keeping thing simple in the right perspective ;). The questions posed about simplicity are now well answered, and this is what is truly learnt because, this will eventually helps us in application of the concept.

Cheers,

Faraz.

P.S: I'm dumb at times. I risk stating the very obvious for the smart people. But, hey this surely helps other dumb people like me. Me being dumb helps me constantly evolve into a smarter being.

Food for thought (Courtesy Wikipedia:Simplicity):

"Simplicity means the achievement of maximum effect with minimum means." — Koichi Kawana, architect of botanical gardens

"Things should be made as simple as possible, but not simpler." — Albert Einstein (1879–1955) "Simple things should be simple. Complex things should be possible." — Alan Kay

"You can always recognize truth by its beauty and simplicity." — Richard Feynman (1918–1988) "

Our lives are frittered away by detail; simplify, simplify." — Henry David Thoreau (1817–1862) "Simplicity is the ultimate sophistication." — Leonardo da Vinci (1452–1519)

"If you can't describe it simply, you can't use it simply." — Anon

"Simplicity of character is the natural result of profound thought." — William Hazlitt

StrStr as an Interview question.

StrStr happens to be the favorite question for some interviewers. I have a senior colleague who is especially fond of this question. He had a hard time getting people from X country answer that correctly. So he decided, to gauge the difficulty of the strstr question by using my answer as a benchmark (Don’t know how wise this decision was?).

He started out by explaining the question to me. And then i started thinking about this. I knew about this question but never had the patience to find an answer. So i decided to think :), n2 algorithms are BAD so I did not even discuss the search the needle in the haystack solution.

Eventually after he putting almost all the words into my mouth I/we got the variant of the KMP strstr algorithm. And then to test if I really understood the solution (this is imp now because I did not design it :)) he just asked me to build another failure table as used in the KMP algorithm which takes the number of matches before a character failure and gives the skip count. And then I got that while waiting for my bus.

Conclusions are.

1. "Efficient" StrStr is not a simple algo to design.

2. There is much to think about it.

3. Once you get it, it easy. BUT... it can always be further optimized.

4. Its not a good interview question for a telephonic interviews. The reason being on the extremely smarts can do w/o hints, i think the person being interviewed should be given hints. Hints are not conveyed effectively over the phone. :)

5. It will fairly gauge the thinking abilities of the person being interviewed.

Tips for the "being interviewed".

1. If you know the answer be honest say that u already know the answer.

2. Don’t get overwhelmed, the direction to start working is not that intuitive. The starting is important.

3. As for all thinking questions you have to convey to the interviewer the fact that u r actually thinking. So think aloud getting the answer doesn't matter as long as you are able to think.

Google Stemming and Other features.

This summary is not available. Please click here to view the post.

Where's the bug ?

int HypAcceptAndPrint2Dates() {
__time64_t merge_lower_time;
__time64_t merge_upper_time;

printf("\nMerge files greater than:");
status = getTimeFromUser(&merge_lower_time);
if (status != ERROR_SUCCESS) {
printf("\nInvalid Date");
return -1;
}

printf("\nMerge files less than:");
status = getTimeFromUser(&merge_upper_time);
if (status != ERROR_SUCCESS) {
printf("\nInvalid Date");
return -1;
}

printf("\n Attempting merge between time Range \n %S %S", _localtime64(&merge_lower_time)?_wasctime(_localtime64(&merge_lower_time)):L"Time Config Error.", _localtime64(&merge_upper_time)?_wasctime(_localtime64(&merge_upper_time)):L"Time Config Error.");
return 0;
}

Merge files greater than:
Specify an Time Stamp:
Enter year [1900-3000]:2000
Enter month [0,11]:0
Enter day [1,31]:1
Enter hour [0,23]:0
Enter minute [0,59]:0
Enter seconds [0,59]:0

Merge files less than:
Specify an Time Stamp:
Enter year [1900-3000]:2005
Enter month [0,11]:0
Enter day [1,31]:1
Enter hour [0,23]:0
Enter minute [0,59]:0
Enter seconds [0,59]:0

Attempting merge on c: between time Range
Sat Jan 01 00:00:00 2000
Sat Jan 01 00:00:00 2000


//



int HypAcceptAndPrint2Dates() {
__time64_t merge_lower_time;
__time64_t merge_upper_time;

printf("\nMerge files greater than:");
status = getTimeFromUser(&merge_lower_time);
if (status != ERROR_SUCCESS) {
wprintf(L"\nInvalid Date");
return -1;
}

printf("\nMerge files less than:");
status = getTimeFromUser(&merge_upper_time);
if (status != ERROR_SUCCESS) {
wprintf(L"\nInvalid Date");
return -1;
}

printf("\n Attempting merge between time Range \n %S ", _localtime64(&merge_lower_time)?_wasctime(_localtime64(&merge_lower_time)):L"Time Config Error.");
printf("%S",_localtime64(&merge_upper_time)?_wasctime(_localtime64(&merge_upper_time)):L"Time ConfigError.");

}





Merge files greater than:
Specify an Time Stamp:
Enter year [1900-3000]:2000
Enter month [0,11]:0
Enter day [1,31]:1
Enter hour [0,23]:0
Enter minute [0,59]:0
Enter seconds [0,59]:0

Merge files less than:
Specify an Time Stamp:
Enter year [1900-3000]:2005
Enter month [0,11]:0
Enter day [1,31]:1
Enter hour [0,23]:0
Enter minute [0,59]:0
Enter seconds [0,59]:0

Attempting merge on c: between time Range
Sat Jan 01 00:00:00 2000
Sat Jan 01 00:00:00 2005


Conclusion:
Exceprt From MSDN which did not read, WHY because i thougt printing time is a trivial thing.

asctime uses a single, statically allocated buffer to hold the return string. Each call to this function destroys the result of the previous call.

I/O Namespace differences between NT and Linux.

Everything is a file cool!
But what about the IO namespace

Logging of some activity on to a given volume in the standard task required for most of volume level activity monitors. So we had a problem at hand, which goes as such.

At configuration time a volume+dir name will be provided to you and you will always write your log files on to that given volume. Now if the volume was to be give as c:\logdir. And some smart fellow now mounts another volume at the mount point c:\logdir your log file will now go to the newly mounted volume rather than going on to the originally configured volume.

Linux team had no simple solution to the problem. The windows team had a very simple solution that being of not accessing the journal directory via the mount point and instead using the volume identifier for the original volume. So the original underlying volume could always be accessed as
\\?\Volume{8400c6bf-7662-11d9-ab4c-806e6f6e6963}\logdir\log

This path will always log to the same volume. i.e the volume with the unique identifier Volume{8400c6bf-7662-11d9-ab4c-806e6f6e6963}

Instead C:\logdir\log.txt could go onto a totally different volume if logdir was a mount point for it. Bottom line is, Windows provides a way to access the files on a volume without going thru the mount point crossing process.

This was a very sentimental issue for me, because I always believed that everything that can be done in NT could be also easily done in Linux. But, this time it was not possible at all. It's against the UNIX semantics to the underlying volume at a given mount point. But Linux’s inability still needs to be justified by some rationale

Clearly UNIX was not designed to trouble us implementing this feature, neither was NT designed with considerations to our interests. I had to conclude on why was the feature present on one OS and not on the other.

The final conclusion is in Linux the device name space contained in the file system name space i.e. your device files are hosted on the file system as special nodes. viz /dev/sda1 is a special node on the root file system.

Its exactly the opposite way on NT i.e the file system namespace is contained within the Device Name space i.e. your file t1 resides on \\Device\HardiskVolume0\t1.txt so to access a file you go through a device and this is the only reason you can access the underlying volume in NT which is not achievable in Linux.

Think about it! In Linux /dev/sda1/f1.txt can never point to file on the volume /dev/sda1
On windows you can \device\sda1\f1.txt to point a file on hypothetical volume \device\sda1\.

And vice versa
in windows c:\com1 can never point to the device com1 (Can be done :)).
And in Linux this can be achieved simply by a device special node /dev/com1

This for me is the second most important difference between NT and UNIX second only to the synchronous VS asynchronous IO model. I think there has to be a way to arrange the IO namespace in such a way that it does have both features of the NT and the UNIX IO namespace. Until someone finds it everything will be just a file.