Skip to main content

Posts

Showing posts from February, 2024

On Bullshit, philosophically.

I was once asked during an intervierw what would be my top three "professional" values. My answer was unexpected in fact I rushed to qualify it a bit.  I said "I find hard to deal with bullshits and bullshitters". Philosopher Harry G. Frankfurt's famous book came to rescue me. Frankfurt's thesis is serious and important. Bullshitting, Frankfurt argues, is not the same as lying.  The liar, like the truth-teller, cares about what is true.    The difference is that the truth-teller conveys it while the liar wants to cover it up.    The bullshitter, by contrast, doesn’t really care one way or the other about the truth. To quote him: The bullshitter may not deceive us, or even intend to do so, either about the facts or about what he takes the facts to be. What he does necessarily attempt to deceive us about is his enterprise. His only indispensably distinctive characteristic is that in a certain way he misrepresents what he is up to. But then surely almost every

Peter Naun on Programmers Mental Models

In  a nutshell, to exemplify the idea that software development should  fundamentally focus on knowledge acquisition (from the envirnoment the software will live in), and building problems frames (see Jackson ) to inform the structure of the architecture (design), I sketched the following. It is simple, not powerfully explanatory, but it is the beginning of something I am working on. So don't shoot me just yet ;-)  Now, l ooking at some literature to further back up or challenge or enrich this idea,  I came across this 1985 article by Peter Naur:  Programming as Theory Building . He says a programmer’s main activity isn’t coding, it’s creating a theory of the problem at hand and its solution. This theory is implicit knowledge, which  can’t be written down. Sure, I can transmit knowledge via documentation. But you can't understand my code as well as I do unless oyu acquire the theory I built in my head, and you can't get that by reading my docs or my code.  In other words,

Problem View vs System View in Software Development

One of the advantages to consider Software Development as a knowledge-acquisition activity, is its inner force to balance the pull to envision the system (design) and the importance of learning the problem first.  There it is, the “problem”, learning the problem first, is rarely an activity in most methodologies.   I am grateful to the immense work produced and clearly articulated over the years by Michael Jackson*, the “father” of problem Frames Analysis. As Jackson argues, the issue is partially due to the fact that the world is is physical and therefore informal. This poses a great challenge in software development: formalization i.e. capturing in symbolic representation a worldly computational problem so that the statements obtained by following rules of symbolic manipulation are useful statements once translated back into the language of the world. There lies the core expertise for any software analyst: learn and frame the problem. I would argue that the articulation of th

Software is a Knowledge Medium. Forget that at your Peril!

  Legacy is something of value you leave for the next generation. At what stage in the history of Software Engineering, "legacy" has become a curse?  Software Factory ? What a heck is supposed to mean? Building software as in a production line? Developer Productivity . The worst of all myths, introduced by maître à penser who do not have the slightest idea of what software really is. A myth perpetuated with the help of pretentious consulting firms... Tech Debt . Another of those topics that gives you an air of expertise like an economist, but it makes no sense at all as a metaphor. Shall I continue? A couple more: Process as the be-all and end-all of software development , because we are persuaded that software is an engineering discipline only . You have the process, you have the product. Aside . To my Agile friends, I am well aware of the first principle in the Manifesto. However, I spot value as a projection of what is done in the field, and not from first principle

"Mens et Opera" defined

Da anni il mio motto richiama l'importanza del pensiero come lavoro.  Mens et Opera , questo il motto. Innanzitutto: il lavoro è costrutto intellettuale, implica la libera e non faticosa iniziativa del lavoro del pensiero: atto cioè attivo a mobilitare, propiziare altri al proprio beneficio (domanda). E il pensiero è lavoro senza fatica. Il lavoro è legge fisica, è moto cioè investimento, è l'impresa della soddisfazione che mette in moto un altro a favore del soggetto operante - divisione del lavoro. Questo genera domande a titolo pieno (ma non ci sono domande che non siano anche offerte). Il lavoro non-lavoro è l’obiezione di principio alla produzione del proprio bene per mezzo della soddisfazione data a un altro. Si chiama invidia. Il lavoro libero (quello testé definito) ammette riposo non come dopolavoro, ma come già interno al lavoro stesso. Da qui quel  Mens et Opera . ___________________ For years, my motto has emphasized the significance of thought as work.