Brent Welch's Talk "My code is better than yours" .. ..

I took up Advanced Storage systems at CMU. Yes the one that is taught by Garth and Greg. The class concluded with a talk by Brent Welch from Panasas. The talk was centered on his experiences around writing Quality good code. I am so ashamed to have slept through half of the class (because I was preparing for a demo to Rob Ross another cool guy from ANL late night). Friends say that I make it quite obvious when I sleep in class (head down and doze, the only saving grace is I do not snore). Hmm to the point, So Brent did talk about a lot of things which I probably did not register as I was asleep, but here are some of the bits and pieces that I registered and I felt were pretty good.

Brent made it quite obvious he was a serious programmer. I mean dead serious. I just could smell it from his talk. I think he is a dude programmer. I have met only a few dude programmers that are real dudes (YOUVRAAJ KELKAR, KIRAN JOSHI and BORISLAV MARINOV). I mean let’s face it everybody else is just about average tapping of theirs ways to glory polluting the already polluted universe of spaghetti code. Btw there is a difference in being a big mouth jibroni ass and talk about everything from Turing machine to WSDL, but a few actually do write code.

Here is what Brent said, which I quite believe in.

1. If you cannot set the tab to (4)spaces (or whatever the convention is for a project)in your code, he would think what kind of dumb ass you are. This is what I personally feel when some dumb ass tries to make a ruckus about HIS programming style and doesn't want to change it in the greater interest of the project.

2. This one is something very new very nice absolutely amazing.

Brent once asked an XYZ programmer who is fond of rewriting code (quite like me) - What is the time required to understand somebody else's code. The programmers answer was, "Time required to rewrite the code?" That is so true, given a smart programmers versified code it’s quite a task to understand his frame of mind that resulted in the code. Quite like an artist’s painting only he fully understands it.

3. Writing quality code is underestimated!

Again, so true every TOM DICK AND HARRY wants to code/pollute. Pollute Pollute Pollute and pollute more. Half of them are just not that passionate - they are just in for a good time. There are basically only 2 types of programmers ones that are passionate and the others that are not. There is not much grading criteria for you if you are not passionate. Hiring people who are not passionate can ruin a team as they bring down the morale of a great team down in more than 1 way. At times when I did have a chance to knock of people who are not passionate about the project - I personally did take delicate care to see that they are out!!!!

4. He believes that "His good is better than everybody else's code"

I buy his argument completely. I usually think the same that my piece of code is better than the rest of the shit floating in SVN/CVS land. How can 2 programmers live in harmony with such an attitude? The point is not that he/me find appreciating somebody else's code too condescending. What it means that the programmer has a lot a respect and responsibility for his code. He would take it personally if somebody passes a unfavorable comment about his code. I think this sense of responsibility and the urge to maintain once repute is what makes quality code deliverable. Its a standard you set for yourself increasing it every time when you learn the best practices of the trade.

Hmm from unfavorable comments I remember how I lambasted one of my colleagues for a frivolous comment he made. Back in old days I did work in Windows User land for Unitrends and this very cool friend of mine worked on Xiotech a kernel mode kick ass project (WTF we all know it was good). He said "Kya be tu kya chavanni ka code likhta user mode me ?" (What code worth 25 cents do you write in user land?). OK …………………… THATS IT what followed was a 1/2 hour tirade as to how dumb fcuck shit piece he, his life and his code was. The comment hit me bad, I know it when I feel it it’s that suffocating feeling that I get in my neck. He could not understand what just happened and was just dazed. ... I wasn't. If I get an opportunity again it will fcuk the shit out of him again for his comment. I mean nobody comments on what I do for a living literally. May be I have grown up now and I won't react the way i did back them, but i'm sure i would react in some way.

My rule is quite simple, your code my friend is the best …. just don't compare it with my code or comment on my code. If you are hell bent on a comparison I simply have 2 word for you "CODE IT !!!" or else talk to my hand. And for the ones who I feel are really better than me (I know its dumb to create a false illusion of being better when you know you are not) I make their praise pretty obvious !o!

P.S no one is a born dude. There is no short cut to being a dude. Except Nikola Tesla everybody follows the power law when acquiring skills.

Debug This !!

:D this is a strange one. May be a the freakiest ones. Every once in a while I have a deluge of work to be completed in the as usual minuscules of time :(. This time it was and FSCK program for the EXT2 file system. Cool ha !! . Its a dumb programs that tries for fix a corrupted file systems nothing much to say about it. Good experience to write one,nothing great about it not as great as my new idea !

In these high wrought and worked up days I'm often visited by my old dear friend ACIDITY. Its business as usual for me when it comes to severe acidity. Wake up, know the exact place below the ribs where it pains,drink water , and ... throw up. Well something really worse happened today where i did threw up again again but none alleviated the pain :(. So i slept in between these 4 hours 4 times and with FSCK on my mind these are the thoughts I get in my dreams.


1. "May be my liver has gone in an infinite loop producing Bile, i need to just fix that variable and all will be fine". hmm this one is very sad, just shows my attachment to the debugger windbag or gdb doesn't matter.

2. "My intestines are a big disk and the part that is paining is the corrupted block of the volume/file system may be i should attach my self to the debugger and see the values of the corrupted block/intestine and do an clear bl".

The thoughts about FSCK and the pain were so badly amalgamated that I clearly remember waking up at regular intervals and explaining it to myself
Faraz-> "Ext2 fSck and acidity are two different problems. Both have no relation to each other and you cannot insert your body in a debugger and diagnose it. Get over it and try to sleep.!!


Very sad !! This is what life gets like at CMU !! No girls, No flying and no dropping even in your dreams :P

Well to think about wouldn't it be great if we can make a debugger for our doctors ;). (There are were sweet doctors at UPITT here)
->Just attach the patient and do a
->bt (backtrace) for everything on the stack.
No more baap ka naam ?, maa ka naam?, kal kya khaya tha ? kyu khaya tha ?.
->print heartbeat; //to print the hearbeat
->break bile>1000 // hmm hmm not cool i know, this a demo na Baba. Real implementation won't stop the running patient
fix the thing
->step
->step n
->continue.
-> WOW!! i am a doctor now !!!

I think these things do exist but they are just not seen as a debugger. I think its doable in a lifetime and another would be needed for testing it :D

LETS PUT THESE DOC'S OUT OF BUSINESS, I will debug myself using my debugger.

Well after 4 hours of an ordeal and hundreds of call to/fro back home, the day was saved by Pudin Hara. From now on, something which i will try to implement is not stay awake for more than 2 days on a stretch (I have kind of developed it over time and the MAX is 5 days without a 'second' of sleep). On the 5th day the experience is quite worth sharing. Some other time. But the best part of the 5 day run is the experience of hearing/understanding what you yourself say with a lag of some time, and crying/singing voices being poured into your ears out of no where. Missing frames , almost like the MATRiX stuff. (Do not do it !)

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.