Cover photo
Laurent Bossavit
724 followers|54,998 views


Laurent Bossavit

Shared publicly  - 
Interview de Katia Aresti, développeuse, MongoDB master et coorganisatrice du workshop sur MongoDB à Devoxx France
 ·  Translate
Add a comment...

Laurent Bossavit

Shared publicly  - 
ICYMI, my piece on "The Making of Software Engineering Myths" is up on Model View Culture:
David Skoog's profile photoRafael Ferreira's profile photochristophe grosjean's profile photoDzenan Ridjanovic's profile photo
Some of the said leprechaums are even older than computers.

I remember (may be falsely, didn't checked) a version of the cost or error correction in newspapers depending of the publication stage (initial writing, proofreading, layout, printing, at resellers),.it was said to be ten times harder/costlier after each stage.

Actually, considering the statement, it appears much less obvious in computer programming context (and of course will depend of the kind of software and the kind of bug... looks not much trouble to fix a typo on a website)
Add a comment...

Laurent Bossavit

Shared publicly  - 
Today I've got a bee in my bonnet about claims of the general form, "a modern car contains approximately 100 million lines of code".

Let's apply James Bach's heuristic "Uh? Really? So?".

First, are we even clear on what that means?

Presumably we are not talking literally about source code. It's possible that a tiny portion of a car's embedded systems run on scripting languages, but that's not likely making up a great number.

So what we really mean has to be something like, "the software inside a car is generated by compiling about 100 million lines of source". (Let's set aside temporarily the fact that "lines of code" is a terrible, horrible, no good way of measuring software.)

By "inside a car", we really mean "the car's own systems". If I bring my laptop inside the car, that doesn't really matter, does it?

But then, what of something like a car's GPS system? Does that really count as "software inside the car", given that we can equally well bring in a standalone GPS gadget, and that in the latter case this is the same situation as my taking a laptop onboard?

Presumably people generally mean "the embedded systems that drive a car's essential functions are generated from about 100 million lines of source code".

How do we count duplicates? Reputedly a modern car contains up to 100 individual Electronic Control Units, but there is a lot of symmetry there; the left rearview mirror and the right may each have a separate ECU, but driven by exactly the same code.

So let's settle on " the embedded systems that drive a car's essential functions are generated from about 100 million distinct lines of source code".

Maybe at this point we could segue into "Really?". Has someone actually measured all this?

I've tried actually fact-checking some of the references. Maybe I'm not looking hard enough, but so far I'm not finding anything more convincing than off-the-cuff ballpark estimates.

For pacemakers, the most commonly cited estimate is "80,000". (Try Googling that.) As far as I can tell, this is all second-hand reporting from one paper which does cite a source, but this source is "personal communication from John Doe".

I did find one paper which discusses the size of pacemaker software, and their actual count was less than 10,000 lines of code. (I'm tempted to formulate a Law of Software Engineering Uncertainty: everything you read about software development tends to be off by at least one order of magnitude.)

But wait, are we counting the lines of code of standard libraries that are incorporated into the manufacturer's custom software? Or only the software developed by the manufacturer?

This isn't going back to the Uh? question, it's actually moving on to the So?.

Even if we grant that a "typical" car "contains" some number N of lines of code, what are we to conclude from that?

Usually the claim is made to underscore the difficulty of properly testing that software, usually alongside a reminder of the risk to human life, often with a view to persuading you that "formal testing" is a great idea not just for cars' embedded software but for everyone.

For what purpose we are counting lines of code (or any other metric of software size)?

If it is to estimate the complexity of testing, or even in general of managing, that much software, it clearly makes a difference who wrote the software. The manufacturer can't do much about the software it gets from various vendors, and is going to have radically different policies depending on the nature of that software: a floating-point library does not require the same kind of testing as an embedded Linux distribution or a graphical windowing system.

Then there's the obvious: "lines of code" means close to nothing. Depending on whether any given line is generated code, or code in a scripting language, or code in a statically typed language, or a line in an XML configuration file, and so on has important consequences on how hard it is to test and manage.

What we're really after here is some measure of "total cognitive effort required to make changes to a given piece of software with a specified risk of introducing a defect".

(This may be one of the Hard Problems of the discipline, one that we have barely made a dent in, because the profession by and large refuses to acknowledge the role of human psychology in this question.)

In the context of discussing whether a modern car could kill people by incorrectly handling the linkage between the accelerator pedal and the engine throttle, this is a relevant question, but it has little to do with "the total size of software in your car", and everything to do with what functions of a car are now under software control and what linkages exist between ECUs responsible for these functions.

All of these complexities are glossed over when people glibly repeat what they've read or heard about how much software there is in a car or a pacemaker. The linked "infographic" will give you an idea of how such misinformation spreads.

This is why I think a statement like "your car contains N lines of code" is informative, but mostly about the speaker's (lack of) programming literacy.
Laurent Bossavit's profile photoColin McMillen's profile photoNat Makarevitch's profile photoAnthony Zana's profile photo
+Daniel Egnor - thanks, if nothing else I've learned things about automotive networks from this discussion that I didn't know before (and which are more concrete and interesting than WAGs about numbers of line of code), and then some Googling led me to this fascinating blog:

Point about "security attack surface" well made and well taken, AND it's clear that this is a different concept (and differently measured) than "total cognitive complexity". "Programming literacy" includes being able to tell why these are different concepts and how the difference matters; even though I'm not a security expert I know enough to tell the difference.
Add a comment...

Laurent Bossavit

Shared publicly  - 
More on that Gelernter article.

First something I want to get off my chest - I really struggled hard to get through the beginning of the article. Little jabs and barbs like "scientists['s...] locker-room braggadocio", "if scientists were rat-catchers", "punks, bullies, and hangers-on", "the sin against the Holy Ghost that pious scientists are taught never to forgive", "the intelligentsia was so furious that it formed a lynch mob" - all directed at a specific category of people - this is classic "us versus them" signaling that would normally lead me to flip the bozo bit and quickly move on to more interesting reading. I only soldiered on because of the aforementioned glowing recommendations from smart people.

(For the record, a lynch mob typically involves pitchforks and beatings, culminating in a hanging. Careless use of this phrase in contexts where you only mean "many people disagreed with person X" is going to be offensive to a bunch of groups whose relatives' lives were claimed by actual lynch mobs.)

It doesn't get much better; for instance, Gelertner next launches a mostly gratuitous attack on Kurtzweil and those who subscribe to his ideas. There is some actual argument in there: "man as we know him is the top growth on a tall tree in a large forest", "if you make lots of people grossly different, they are all lost together" - but you really have to struggle to get to it amid all the bile.

I don't really know Kurtzweil's work, and I'd readily agree that a firm prediction of "Singularity by the year 2045" is going overboard and making Singularitarians in general look a bit silly. But none of this supports Gelernter's points; it's just venting.

Gelernter insists on trotting out straw-man caricatures of imagined opponents' positions, and in the process misrepresents not just one or two individuals but scientists in general. By way of Searle, he suggests that scientists refuse to "accept the existence of things that can’t be weighed or measured, tracked or photographed" because such things are "damned annoying". This isn't a critique so much as a childish taunt. Not all scientists are obsessed with measurement, and there are such things as qualitative research and so-called soft sciences.

His arguments against Dennett's views are of the same sort - I've mostly dealt with them in my previous post.

When he argues, "computationalists cannot account for emotion", he again displays apparent ignorance of lots of significant work in evolutionary psychology (see for instance Tooby and Cosmides' overview, linked.) Fear, for instance, can be quite readily explained in terms of an ensemble of psychological and behavioral dispositions that are appropriate in threatening situations (and thus fitness-enhancing): it would be poor design for this response to cohabit easily with, say, curiosity or aesthetic joy; but it is good design for it to be associated with heightened sensory awareness. The resulting configuration of portions of our mind, smaller than the whole, is what we experience as the "inner feeling" of fear.

When he uses "thirst" as an example of something that cannot be accounted for by a functionalist perspective, and adds that "[the] feeling, in turn, explains such expressions as 'I am thirsty for knowledge,' although this “thirst” has nothing to do with the heat outside", I want to refer him to Hofstadter's work on the role of analogy in human thought - work that is quite compatible with functionalism.

I can't make head or tails of what Gelernter wants to make of the so-called "Zombie argument" - Dennett has dealt with that quite convincingly ( He mostly seems to want to count David Chalmers as being on his side.

But, again, the way he closes this section makes it quite clear for me what he's on about: "Just as God anchors morality, God’s is the viewpoint that knows you are conscious."

Time and again, to sum up, this article turns a blind eye to the sophisticated versions of the argument it pretends to rebut in strawman form. That makes me mad - and there is no mystery about this "inner experience" for me.

What I'm seeing, overall, is a familiar religious diatribe against the (perceived) encroachment of the sciences, thinly disguised as a critique of the arrogance of the current scientific establishment. The latter viewpoint happens to be one I agree with, and this is perhaps why some of my smart friends appear to buy the pitch as a whole; to me, though, it is a wolf in sheep's clothing.
Add a comment...

Laurent Bossavit

Shared publicly  - 
There are many things to disagree with in this article but it's an interesting read.

I'm not sure Agile is a "disguised unionism"; some of the debate about it does hint at a sort of class struggle.

On the one hand we have Agile as "more humane software development", on the other hand Agile as "doing more with less".

A lot of the angst about Agile arises from people being sold Agile under one promise but only realizing the other. That is, management buys Agile believing it will bring about better "productivity", but then finds it has only lessened its control; or workers buy Agile believing it will bring them increased autonomy, but then discover it was really only about micro-managing them into producing more stuff faster.

IMO each of these promises is the price to pay to get the other, and separating them can only end in tears.

This for instance: strikes me as misguided because it undercuts the "increased worker autonomy" promise.
Add a comment...
Have him in circles
724 people
A delightful short story.
Add a comment...

Laurent Bossavit

Shared publicly  - 
Read the linked for a different perspective on "lines of code". Also Emily's writeup of an array languages symposium:

Also look at this, a text editor written in a handful of lines:$/edit.k

Emily says it "looks like line noise". You know what else looks like line noise? Compressed text files. Compression crams as much information as possible in the smallest space, getting rid of all the redundancy. Text before compression is highly redundant, this helps understanding in particular by affording error correction. If I spell it "eror" you still know what I mean.

What's a program? A description of an abstract machine's behavior. Which is to say, a text, which entails structure and redundancy. You can compress the redundancy away, to different extents. That depends on the language.

If you want to evaluate how well a compressor performs, you can't just take the size of the output (compressed) text as the metric. You have to add the size of the decompressor. A smarter decompressor is bigger but can compress more efficiently. For instance, if your decompressor includes every word in the English dictionary you can represent a word with a single number, its index in the dictionary. (Plus a few bits for case and declension and so on.)

The goal of VPRI seems to be compression in that sense. The program above, "edit.k", is very small but the decompressor must have a lot of sophistication.

"Lines of Code" is useless as a metric because it totally fails to account for the redundancy/compression tradeoff.

I've seen several software systems which consisted largely of massive amounts of dead simple code generated from much smaller data files and a somewhat sophisticated code generation engine. That's one way to compress. The generated code lines don't "really" count towards the system's cognitive complexity. (Except... One of the worst ideas in programming, by the way, is to then check those code files into the version control system and start modifying them by hand. If you do that, you end up in a peculiar circle of Programming Hell.)

I've seen software systems where WAY too much of the behavior was specified by a set of XML files (Spring configuration, if you must know). These would normally not be counted as "lines of code", but in this case they should.

Why? Because these files account (on these projects anyway) for a large portion of the cognitive complexity. Making changes to anything usually involves searching through Java files to see where the behavior is, then searching for the names of particular classes in the XML to see what objects are wired to what other objects. Predicting the behavior becomes a juggling exercise.

This is poor compression, like using Run Length Coding on 32-bit photo files. Like RLC, I suppose XML files have their limited domain of applicability, but mostly I've seen them contribute "noise".

We all know that noise compresses poorly. In programs, the equivalent of noise is accidental complexity: say, using a Data Transfer Object to load values into an instance then passing the instance to a "procedural-written-in-OO" set of functions, then writing the result back to a DTO. (If you want a simpler example: assigning value X to variable A, but by way of several unnecessary intermediate steps involving other variables.)

When you count a system's LOC, you are most often going to count a large amount accidental complexity, "noise".

This is the correct intuition behind Function Points (flawed as they are), that you need independent ways of expressing the following three distinct concepts:
- how large a program NEEDS to be, "essential complexity"
- how large it HAPPENS to be, "contigent complexity",
- how hard it is to WORK with, "cognitive complexity".

Function Points have aimed at formulating a relation between the first two, and pinning down number one. Cyclomatic Complexity can be understood as a (not very successful) attempt at number three.
Rafael Ferreira's profile photo
Add a comment...

Laurent Bossavit

Shared publicly  - 
I've been thinking about James Bach's recent posts on integrity.

Let's state a definition and a hypothesis. We'll call stand-out qualities the things that distinguish you from other people in your job market.

The hypothesis is that your stand-out qualities tend to determine the kind of work environment you end up in: those are the workplaces that put a premium on precisely those qualities, making them more likely to hire you over someone else even if they're overall better than you. (A kind of comparative advantage, if you will.)

To illustrate, if you're a top-notch engineer you might end up working in places that have a strong engineering culture. (Remember, this is a hypothesis; I'm open to hearing objections! I'm exploring the consequences if I'm correct.)

Similarly, if you're a great coach, outstanding at nurturing and bringing out the best in people working in teams, you may find yourself in a workplace that places a premium on harmony.

There could be dark sides, true tradeoffs. A workplace with strong engineering culture may also be one where cutthroat competition is the norm, rather than teamwork. One that values harmony may not necessarily value "getting shit done" quite as much as you'd like.

More generally it isn't necessarily the case that your standout qualities also happen to match your conception of a great work environment. Life may be bittersweet to some of us who never have trouble finding employment but never seem to be quite satisfied with their current job.

The remedy, of course, is to have multiple standout qualities - so that you can choose jobs or gigs where you can have your cake and eat it too, so to speak.

If your standout quality is integrity, you might generally end up working in places where people value things like not keeping secrets, carrying out promises, surfacing unpleasant truths.

There may be bittersweet tradeoffs, but this strikes me as a strong argument when people object "what if you have to choose between getting a job and preserving your integrity"?

If you are the kind of person who does not value integrity, who does not have it as a standout quality, you shouldn't be surprised to find yourself hired in places where you get stabbed in the back by people you thought you could trust.

I'd rather not have work of that kind. Early in my career, I had this happen quite a bit: decisions from other people that I experienced at deeply hurtful betrayals. Later on, I made a conscious decision to develop integrity, authenticity, transparency as my own stand-out qualities. I haven't experienced betrayal - no serious ones, anyway - in a really loooooong time.

It's hard to be sure of the cause-effect relationship here, but let's say I have a strong hunch that living up to a value of integrity - even at some occasional personal cost - was one of the best decisions I ever made.
Jesse Alford's profile photoAnne-Marie Charrett's profile photoLaurent Bossavit's profile photo
funny, for me its the other way, I never finished the Black Swan, but I'm devouring Antifragile. 
Add a comment...

Laurent Bossavit

Shared publicly  - 
So a few people I think well of have pointed me to this article by David Gelernter of Linda (tuple space) fame, praising it to the skies.

I'm just writing this to put some of my thoughts out there in no particular order, perhaps to sort through and organize later into a more coherent critique.

I tried to read the article with an open mind, even started out agreeing with part of the leading pargraph. But what I found throughout was caricature. It worries me that someone of this caliber can make such weak arguments about the comparison between minds and computers and not be called out on it.

Let's dive in the middle with the section called "The Flaws", wherein he wants to show that "the master analogy—between mind and software, brain and computer—is fatally flawed" and offers as his refutation some "simple facts".

Fact number one is: "you can transfer a program easily from one computer to another, but you can’t transfer a mind, ever, from one brain to another".

This is a misuse of analogy, not a "fact". Try transferring the software from a Windows laptop to a Mac; let me know what luck you have. Try transferring a Linux executable to a Window box. (Yes, some technically sophisticated folks can actually do this; but it's not "easy".)

The facile comparison disregards the entire history of computers. There was a time when transferring a program from one computer to another was anything but "easy". Programs for the EDSAC ran on the EDSAC, and that was it. Computers were as unique as an individual organism.

Later, the notion of "operating system" allowed programs to be transferred from one unit of a mass-produced computer to be run on one that had different characteristics (memory, storage, and so on). Later still, software started becoming "portable" - given a source code representation of a program, you could compile it on a different operating system, even a different architecture, and (in principle) see comparable behavior.

The point here is that the mapping "program :: mind" is grossly inaccurate, an easily knocked down straw man. If you map "mind" instead to "the entirety of the operating system, application software, user data and preferences stored on one particular computer" then it's already much less clear that it's "easy" to transfer.

For another way to fix the analogy, if you map "program" to "a particular computation that a mind can perform", then on the other hand transfers of some parts of a mind to another are easy, and in fact so commonplace as to be almost unnoticeable. "Add 4 to 17 and think of the resulting number" is such a program, easily transferred, which by now your mind has (I expect) executed and obtained the output of.

Gelernter's Fact #4 is the only one that's roughly correct: minds cannot be erased from brains, whereas a computer can be reset to a pristine state. But that's a contingent fact of the process of evolution that gave rise to brains, versus the directed evolution that gave rise to computers. It has little bearing on whether the "master analogy" is valid as a source of insights.

Fact #2 is the same mis-mapping again: "you can run an endless series of different programs on any one computer, but only one program runs, or ever can run, on any one human brain". This is just a confusion of levels. If it was literally true, communication and teaching would be impossible. Fortunately, the human mind shares with computer programs the property of modularity: it is composed of a great number of somewhat independent "mind bits", some of which can be swapped out and replaced by others. We call this process "learning".

Fact #3 almost reads as a joke: "software is transparent; I can read off the precise state of the entire program at any time". This may be true in principle - but in practice it does you no good if the source code to the program in question is a plate of spaghetti. You will still not be able to predict the behavior of the program or fix its bugs. As for Fact #5, "computers can be made to operate precisely as we choose", try telling that to anyone spending most of their days struggling to fix bugs.

Conversely, when he says "minds are opaque—there is no way I can know what you are thinking unless you tell me" - this conveniently ignores all the various ways we have to get a "read" into what another person feels and thinks, from the lo-tech - looking at their face, à la "Lie To Me" - to the very high-tech such as brain imaging. (That brain imaging is not "there" yet in terms if telling anything we can't tell from looking at people's face is not a fatal objection: our ability to "read" other people has had millions of years' worth of refinement, and still has limitations.)

The point here is that these rather trivial comparisons cannot illuminate whether the difference between minds and computers in these various respects is truly one of kind rather than merely one of degree.


I need to stop now, will perhaps have more to say later.

I fear that Gelernter's real point is this, buried after a long and meandering exposition of the "Zombie Argument":

> Of course the deep and difficult problem of why consciousness exists doesn’t hold for Jews and Christians.

The article presents as a critique of science's arrogance with respect to the mind, and perhaps Gelernter does have a point that the institutions of science are out of whack and need reining in, that these institutions "have dedicated themselves to stamping out reasoned argument and constant skepticism and open-mindedness". There is an arrogance in leaping from the intuition that a problem is solvable in principle to declaring it "almost solved" and making public policy on that basis.

But that's not the real target of Gelernter's attack, IMO. What he wants is for science to stop claiming that Man isn't special. That's not a challenge to the institutions of science, it's a challenge to science itself, an old and familiar one. There is nothing new in his arguments, nothing that shows he has paid attention to what we have learned (and people like Dennett have synthesized) from a few decades of entering the computer age.
Lev Gorodinski's profile photoKaushik Sridharan's profile photo
Agreed. I found parts of the article nearly ridiculous. Instead of offering something new, it seems to repeat the tired story of how the progress of science threatens subjectivity, emotion, being special, etc.

He goes further to claim that functionalism can't express emotion, or subjectivity without any sound foundation. But why can't we be machines with subjective states? I'm not claiming the computation theory of mind is complete, but neither does the theory itself. After all, the theory, or any other theory including the author's, establishes a model of the mind - and all models are inherently incomplete.

Repeated demonization of science and its supposed crusade against what is truly human is overdramatized and under-analyzed. Indeed, what the author does well is appeal to emotion and, with all due respect, the article seems to be better fit for a screenplay than a philosophical discussion.
Add a comment...

Laurent Bossavit

Shared publicly  - 
A prominent French scholar writes:

In France, the present negotiations we face with Elsevier concerning subscriptions are also fierce. Yesterday all academic French institutions received the announcement that negotiations have broken down, and we will no longer be able to access their journals on December 31st.

If you could provide me details about similar negotiations with Elsevier you have heard about, I will forward them to colleagues in charge of the present negotiation. I am also looking for information concerning the fact that Elsevier pays some of us in an obscure way (there is no contract, other editors are not informed, etc.). This might explain why some of our colleagues are supportive of Elsevier.

If you contact me, I can arrange to have information passed on to this scholar - while maintaining your anonymity if you like.  You can send me a private message on G+.  Or, my email address can be found on my webpage.   (There's a slight intelligence test involved.)
François Parmentier's profile photoAdolfo Neto's profile photo
Add a comment...
Have him in circles
724 people
Other profiles
Basic Information