We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Open-source software: Blaming the unknown, or a constructive approach to technology

00:00

Formal Metadata

Title
Open-source software: Blaming the unknown, or a constructive approach to technology
Title of Series
Number of Parts
97
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
◦NOTE: THIS IS NOT A TALK ABOUT MYSQL - IT'S ABOUT GENERAL ATTITUDE TOWARDS NEW TECHNOLOGIES - I have presented this talk at two open source events where it was received enthusiastically *** If you don't know them, they will hurt you. No matter how expert you are, there are holes in your knowledge, and when things go wrong you usually blame what you know the least. So the culprit could be that database, the regular expression engine, the XML parser, the thread engine. What if the problem is between the chair and the keyboard instead? This talk will give you some general insight on the art of software development, encouraging users to rant less and improve their own practice. The most popular open source database in the world * NOTE that this talk is not about MySQL *
Open sourceGoodness of fitIrrational numberComputer animation
Computer animation
Multiplication signAuthorizationComputer animation
ParsingInterface (computing)DatabaseRegulärer Ausdruck <Textverarbeitung>Multiplication signRegulärer Ausdruck <Textverarbeitung>DatabaseComputer animation
Formal languageGoodness of fitComputer animationLecture/Conference
File formatMultiplication signMusical ensembleAsynchronous Transfer ModeComputer animation
InformationComputer animationPanel painting
Metropolitan area networkComputer animationLecture/Conference
Metropolitan area networkNoise (electronics)Lecture/Conference
Phase transitionAuthorizationGoodness of fitComputer animationLecture/Conference
Computer animationLecture/ConferenceMeeting/Interview
Traffic reportingFeedbackSoftware bugLecture/ConferenceMeeting/InterviewComputer animation
Software bugTraffic reportingComputer animationLecture/Conference
Software bugComputer animationLecture/Conference
Software bugComputer animationLecture/Conference
Software bugTraffic reportingComputer animationLecture/Conference
Set (mathematics)PermianComputer animationLecture/Conference
Web serviceMetropolitan area networkType theoryService (economics)Computer animationLecture/Conference
Type theoryFormal languageIdentical particlesNoise (electronics)Sign (mathematics)Computer animationLecture/Conference
Similarity (geometry)WebsiteData miningFacebookComputer animationLecture/Conference
DatabaseFile systemJava appletDatabase transactionComputer animationLecture/Conference
Java appletWindowDigital rights managementDistribution (mathematics)SpacetimeComputer animationLecture/Conference
ConsistencyComputer animation
ConsistencyGoodness of fitComputer animation
Computer iconComputer iconComputer animation
Regulärer Ausdruck <Textverarbeitung>System administratorComputer animation
SpreadsheetFunction (mathematics)DatabaseSpreadsheetDatabaseLine (geometry)Basis <Mathematik>Computer animation
Computer animation
Keyboard shortcutKeyboard shortcutMultiplication signComputer animation
Euclidean vectorComputer programmingComplex (psychology)Error messageMultiplication signComputer programmingCartesian coordinate systemError messageConnectivity (graph theory)Complex (psychology)Computer animationLecture/ConferenceProgram flowchart
Rule of inferenceComplex (psychology)Expert systemRule of inferenceCartesian coordinate systemComplex (psychology)Expert systemOperator (mathematics)Computer animationLecture/Conference
Process (computing)Library (computing)Physical systemJava appletData miningFormal languageOperating systemLibrary (computing)Regulärer Ausdruck <Textverarbeitung>Bookmark (World Wide Web)Rule of inferenceComputer programmingPrime idealProcess (computing)Computer animation
Computer programmingRule of inferenceUniform resource locatorComputer animation
DatabaseExistenceSoftware bugCodeCausalityError messageCartesian coordinate systemInstance (computer science)Computer animation
Computer animation
Computer animation
Computer animationLecture/Conference
Vulnerability (computing)BitError messageVulnerability (computing)Computer animation
Computer animation
Computer animation
TwitterComputer animation
Computer animation
Transcript: English(auto-generated)
Thank you. Good afternoon everyone. We are talking about something irrational. The way that we choose technology. Sometimes the way we choose or we don't choose technology is not rational.
And especially we are talking about the unknown. Something that scares us. Something that we are not comfortable with. Something that we don't want to admit to ourselves that is scary. So one thing from somebody who, better than me, can talk about this.
Emmanuel Rosen, the author of The Anatomy of Buzz says that most of the criticism comes from people who don't know what they are talking about. And let's see. Most of the time we say I couldn't do something like that. It doesn't work because the database, the regular explanation or the XML or whatever didn't work.
You must be familiar with this and I'm going to tell you how this thing works with a few stories. So the first story about cannot, don't or want is about Mozart.
You know Mozart sucks. Do you? Or maybe not. Anyway, if it does or does not is for the same reason that Perl or PHP, MySQL, databases, languages suck. So let's see. First of all, the rumor.
Whenever you have a new thing there will be somebody who tells you something good, something bad about that. So it starts this way. You know the emperor at the time of Mozart was the most important critic in the empire. He didn't know anything about music, by the way, but since he was the emperor it was quite an important one.
And so one day while making breakfast in front of all the dignitaries he asks, how good is it this Mozart? And whenever you ask something like that somebody will tell you, it's remarkable, Majesty, I heard an extraordinary opera of his last month.
So there must be somebody who has done some research and provides some information. So the opera was Idomeneo, King of Crete and immediately there is somebody else who didn't like it. So he said that was a tiresome piece and then we have some flame here.
Yes, a young man trying to impress beyond his abilities, too much spice, too many notes. So far the emperor says, okay, let's hear this Mozart, but he has the inner conviction.
So he knows that something is wrong with this Mozart. And when finally the concert ends and he is satisfied, he starts by giving some positive feedback to the author.
So he says, a good effort, yes, extraordinary, very good. And Mozart is pleased in the beginning, hearing these things is new. So Mozart asks, did you like it? And suddenly the emperor converts the feedback into a bug report.
He says, yeah, it was very good, but now and then, just now and then, how can I know a touch? And then Mozart starts to panic, what do you mean? And the emperor tries to find a repeatable bug report and asks somebody for suggestion.
How would you once say, director, you remember that guy who didn't like Mozart in the first place? So the director says, too many notes, and remember the rumor comes back, exactly. And he says, like it was his idea, that were too many notes.
Mozart, of course, when you find a bug report, the support guys will not agree with you and immediately will have to argue back and down. And finally the emperor starts doing some documentation of his bug by asking impossible things to the CTO.
And the CTO says, of course, majesty, you are right. And in the end Mozart has to downgrade the bug report to a feature request.
So the emperor says, just cut a few notes and it will be perfect. And Mozart says, which few notes did you have in mind? Okay, but this is the story. Does it sound familiar? Now let's try the same story with a different set.
How good is it, this Perl? And of course somebody who has seen it, remarkable majesty, I saw a most extraordinary web service created by Perl. Gherman distributed service. And immediately somebody says, oh, a write-only type of language, I know it.
Write-only, most complicated language, indistinguishable from line noise. Too much compact, too many punctuation signs. Or maybe you have seen this one.
How good is this MySQL? Yeah, you know, this guy knows everything, so it's remarkable majesty, a friend of mine has a very popular website powered by MySQL, Facebook, a social network, that, a toy database, I've seen that too.
A toy, you know the flame. A miserable file system with SQL trying to impress beyond the skills. Not transactions, no, not a mission critical database. So you can do it more, Java, Linux, Python, Windows 7. And you will find somebody who is not, who doesn't agree on that.
So too many distributions, too many white spaces, too much hidden DRM. Maybe it's right, but maybe not. And so on. Let me tell you another story. When I was 13 years old, my French professor told me that you can't learn English.
There are too many consonants that can be pronounced by somebody in the south of Europe. Now you may agree that although I have a horrible Italian accent,
I am speaking something that sounds like English. So this was 20 years later that finally I recognized that my French professor not only didn't speak English, he didn't speak even French. So I realized that maybe his advice was not sound. So I decided to learn English and I found out that the problem is not too many consonants,
it's too many vowels. But this is a different story. I'm Italian, so for me the only coffee that is worth mentioning is espresso. American coffee was an abomination that was advised not to touch at all.
But if you go to America and you find somebody who makes good coffee, it's quite good. Or when back in the 80s they told me that Mac is something that should not be used by real geeks because icons are for sissies. Now if you see here, I have a Mac. So after a while I realized that that was not a good example as well.
For many years they told me this and I was using C for system administration. It was really stupid until finally I tried it and it worked. So you have heard stories like that databases don't work,
or you don't need databases, a spreadsheet is what you need. Databases are just a few PHP lines, or you should not use VI because it sucks, or Emacs because it sucks, or MySQL because it sucks, or PostgreSQL because it sucks. Enough.
Sometimes the problem is near to you. Sometimes the problem exists between keyboard and chair. So it happened to me many times. You have seen that. Once upon a time I didn't make any mistakes. Then I grew up and I found them.
So what happens when you have a complex program? You have a complex program full of many components. These components could be JavaScript, Ajax, CSS, PHP, and so on. So what happens? You have an error in your complex application. What do you do?
Now the rule of complex applications says that you always blame what you don't understand. So you are an HTML expert, then you can blame Ajax, PHP, SQL, and you are a PHP expert, everything else can be blamed. SQL expert, PHP is a fault of course.
Or if you want more things to blame, you can blame the operating system, XML processing library, the regular expressions, these are a favorite of mine, or actually of many people. You can blame the language, you can blame the weather, especially in Belgium.
You can blame abduction by aliens, and if you are Italian, you have a special thing to blame, you can blame your Prime Minister, Gaffs. So there is the first rule of programming, which you can find in this URL, and the first rule says that it is always your fault.
Now, the second rule says there is no second rule. As an example, you have a problem in your application, and you blame what you don't understand. For instance, let's blame MySQL. Then you keep looking for non-existent MySQL bugs, actually you file a bug and you scream at the support people,
and of course you fail to look at the real code that was in your code, and you waste hours, days, maybe weeks and months not to find the real error. So remember, it's always your fault.
But okay, this is the problem. So what can you do? First of all, you need to be curious, and then you need to be brave. So once you understand that you are at fault, you need to do something.
So curiosity is what takes you to the next step. Curiosity is the foundation of innovation. There is no science or technology without curiosity. What else? You need bravery, because being curious is not enough.
You really need to try it on your own. Really. You must go in front of the bull, take the bull by the horns and do something. So how do we assess the problem? First of all, don't blame anything else. Assume that you are wrong,
and then the error is going to be easier to find. So the things that you should do is find your weakness, and get curious about this weakness. You can explore it a little bit more and find some things about that.
Learn how to exploit this weakness and make it into a strength. And then, finally, you can fix the problem. So once you are facing the unknown, you know, this is pretty scary.
The unknown scares everybody, so don't assume that you can't deal with that. Sometimes the unknown is less frightening than you thought. So this is a duck. It looks like a dinosaur, yeah? That is a duck. So that's it.
I shared with you some personal experience, and I hope you will find some good thoughts for improving your own career. Thanks.