Mens Et Opera - Reloaded

Writing a Manifesto may be cool. It may make you feel belonging to something historically relevant. But they are generally subjects to the law of unintended consequences.  There are exceptions, naturally. I believe Mitchell Kapor A Software Design Manifesto is one of those few exceptions.

Over an interesting post by @Michele Sollecito where he maintains that software development is all design, there's been a lively conversation in the comment. I said in one of the comments that " Design is Dead " and the provocation was picked up. Here a brief comment on why I believe so. For the long answer, I am afraid you have to wait for my paper to be in a readable draft state (and please don't crowd 😀). Premise Martin Fowler in a 2004 long article maintained that software design has changed nature and as a result it is alive though morphed into something else. Jim Coplien , argues, correctly in my option, that it is wise and experience bears this out to get the structure upfront, otherwise you risk driving yourself into a corner, architecturally. I could mention hundreds. This is to set the stage i.e. it is a fundamental debate, and it’s not settled. Unless we introduce beliefs in the mix. Clarification : Talks of "design" abounds, they are everywher

𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗮𝗶𝗹. We all know that. Statistics are staggering. Or just misleading. Bottom line is that every one in the industry knows that IT projects fail often, many have experienced it first hand. Two interrelated thoughts come to mind. They may not resonate with you - which is, incidentally, a very good news! 💭 [𝙼&𝙾 𝙲𝚘𝚗𝚓𝚎𝚌𝚝𝚞𝚛𝚎 #2]  𝚃𝚑𝚎𝚛𝚎 𝚒𝚜 𝚗𝚘 𝚠𝚊𝚢 𝚢𝚘𝚞 𝚌𝚊𝚗 𝚐𝚎𝚝 𝟾𝟶% 𝚌𝚎𝚛𝚝𝚊𝚒𝚗𝚝𝚢 𝚒𝚗 𝚊𝚗𝚢 𝚎𝚗𝚍𝚎𝚊𝚟𝚘𝚞𝚛 𝚠𝚑𝚎𝚛𝚎 𝚙𝚎𝚘𝚙𝚕𝚎 𝚊𝚛𝚎 𝚒𝚗𝚟𝚘𝚕𝚟𝚎𝚍 💭 [𝙼&𝙾 𝙲𝚘𝚗𝚓𝚎𝚌𝚝𝚞𝚛𝚎 #3] 𝚂𝚘𝚏𝚝𝚠𝚊𝚛𝚎 𝙳𝚎𝚟𝚎𝚕𝚘𝚙𝚖𝚎𝚗𝚝 𝚙𝚛𝚘𝚓𝚎𝚌𝚝𝚜 𝚊𝚛𝚎 𝚕𝚊𝚛𝚐𝚎𝚕𝚢 𝚏𝚕𝚊𝚠𝚎𝚍 𝚋𝚢 𝚝𝚑𝚎 𝚘𝚟𝚎𝚛𝚌𝚘𝚗𝚏𝚒𝚍𝚎𝚗𝚌𝚎 𝚘𝚏 𝚝𝚑𝚎 𝚖𝚊𝚗𝚊𝚐𝚎𝚖𝚎𝚗𝚝. All the "explanations" about projects failure you read in (good) literature are an outpouring of (2) and (3).  

At organizational level, software development is a flatland, populated by odd creatures. Lots of alchemy, little chemistry. How to stand out and be innovative? A legit question. When it comes to innovation I discount virtually all the recipes foisted on to us by methodologists, gurus, charismatic figures, mesmerizing narratives, and so forth. Innovation is a "negative" concept*, namely, it is defined by pointing out what stifles it. In other words the best we can do is to set out the conditions to let people innovate, potentially. In this context, fostering an innovative environment for software development is a matter of taking stuff away :-) What stuff? My take. No prescriptive recipes, no universal principles - just observation over the years: 1️⃣ No principles: they are all good and agreeable but provide very little guidance. For example: in many quarters software (design) has been trivialized to SOLID, YAGNI, Beck's 4 principles to name a few. 2️⃣ Don't start wit

In Software Development, knowledge acquisition and transformation on one hand, and internal and external complexity, on the other hand, are two interconnected and inseparable aspects of the same endeavour. F. Hayek, a towering figure in economics, and a major member of the Austrian School of Economics, put it simply. “𝑻𝒉𝒆 𝒄𝒖𝒓𝒊𝒐𝒖𝒔 𝒕𝒂𝒔𝒌 𝒐𝒇 𝒆𝒄𝒐𝒏𝒐𝒎𝒊𝒄𝒔 𝒊𝒔 𝒕𝒐 𝒅𝒆𝒎𝒐𝒏𝒔𝒕𝒓𝒂𝒕𝒆 𝒕𝒐 𝒎𝒆𝒏 𝒉𝒐𝒘 𝒍𝒊𝒕𝒕𝒍𝒆 𝒕𝒉𝒆𝒚 𝒓𝒆𝒂𝒍𝒍𝒚 𝒌𝒏𝒐𝒘 𝒂𝒃𝒐𝒖𝒕 𝒘𝒉𝒂𝒕 𝒕𝒉𝒆𝒚 𝒊𝒎𝒂𝒈𝒊𝒏𝒆 𝒕𝒉𝒆𝒚 𝒄𝒂𝒏 𝒅𝒆𝒔𝒊𝒈𝒏. 𝑻𝒐 𝒕𝒉𝒆 𝒏𝒂𝒊𝒗𝒆 𝒎𝒊𝒏𝒅 𝒕𝒉𝒂𝒕 𝒄𝒂𝒏 𝒄𝒐𝒏𝒄𝒆𝒊𝒗𝒆 𝒐𝒇 𝒐𝒓𝒅𝒆𝒓 𝒐𝒏𝒍𝒚 𝒂𝒔 𝒕𝒉𝒆 𝒑𝒓𝒐𝒅𝒖𝒄𝒕 𝒐𝒇 𝒅𝒆𝒍𝒊𝒃𝒆𝒓𝒂𝒕𝒆 𝒂𝒓𝒓𝒂𝒏𝒈𝒆𝒎𝒆𝒏𝒕, 𝒊𝒕 𝒎𝒂𝒚 𝒔𝒆𝒆𝒎 𝒂𝒃𝒔𝒖𝒓𝒅 𝒕𝒉𝒂𝒕 𝒊𝒏 𝒄𝒐𝒎𝒑𝒍𝒆𝒙 𝒄𝒐𝒏𝒅𝒊𝒕𝒊𝒐𝒏𝒔 𝒐𝒓𝒅𝒆𝒓, 𝒂𝒏𝒅 𝒂𝒅𝒂𝒑𝒕𝒂𝒕𝒊𝒐𝒏 𝒕𝒐 𝒕𝒉𝒆 𝒖𝒏𝒌𝒏𝒐𝒘𝒏, 𝒄𝒂𝒏 𝒃𝒆 𝒂𝒄𝒉𝒊𝒆𝒗𝒆𝒅 𝒎𝒐𝒓𝒆 𝒆𝒇𝒇𝒆𝒄𝒕𝒊𝒗𝒆𝒍𝒚 𝒃𝒚 𝒅𝒆𝒄𝒆𝒏𝒕𝒓𝒂𝒍𝒊𝒛𝒊𝒏𝒈 𝒅𝒆𝒄𝒊𝒔𝒊𝒐𝒏𝒔 𝒂𝒏𝒅 𝒕𝒉𝒂𝒕 𝒂 𝒅

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

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,

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

  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