Atelier Logiciel Sandré

Why do we need master craftsmen?

Fri, 22 Jul 2022 00:00:00 +0000

Mastery is not a dirty word, but a social mechanism to counter the devastating consequences of the ~~Dunning-Kruger effect 🇫🇷~~. The most dangerous person in any field is not the uncertain and humble novice, but the beginner, who does not yet know that he knows nothing, but knows enough to believe he knows. He has climbed the mountain of stupidity and must not be left alone with code.

In the ancient European system of guilds, apprentices were not allowed to touch the tools. The material was scarce and therefore expensive. Things have changed for the best, fortunately, at least as long as we still enjoy abundant and affordable energy. When their ability not to waste raw material was confirmed, apprentices became journeymen. They kept that status for several years, during which they were trained to become competent professionals, partly in school and partly on the job. To become masters and be allowed to create their own business, un-supervised, they had to prove their ability to correctly estimate their level.

This is the definition of a master: an autonomous professional, both in the practice of their trade and in the self-evaluation of their skills.

I have many craftsmen among my relatives, working with different materials. Whether they work with pigments, stone, wood, plaster or source code, they all agree on the types of work that require the hand of a master. Whenever school knowledge alone is not enough, when experience must have dug furrows of wisdom into the bedrock of theory, a master is needed.

When others have blurred the boundary between starting and finishing ; When the devil hides in invisible crevices, that time will imperceptibly dig; when the cognitive biases of hastily recruited rookies add up with no moderator to temper the chain reaction; when the work must survive time, change and men, a master’s hand is needed, to make if not to guide.

It is no coincidence that the role of master appeared with the first human industries, only to disappear when energy was abundant. Our societies have the luxury of wasting inexpensive energy on eternal resets. The advantage is a great serendipity that favors innovation. This strategy is about to become an economic failure, if it is not already an ecological one.

Pollination is not only valid at team level. Masters must reach out to juniors to pass on bits of knowledge.

As the inheritor of the failures of those who preceded him, the master is thrifty. He does not waste material and energy reproducing the failures of others. He makes his own and adds them to the corpus he will pass down to his apprentices. Obviously, this phenomenon also works for ideas that look good but have unexpected terrible consequences. These spread anyway, with or without a master, unlike best practice. Masters win this one.

Anyone who looks at our trade can see that the same mistakes are repeated over and over again. It is like a state of perpetual childhood from which no Peter Pan is ever banished. I would venture to say that it is due to a lack of masters, or at least their reluctance to be in contact with those who need them most. Most of them remain among ‘people who get it’, producing excellent software but leaving 95% of the profession to fate and chance encounters. This must change if we are to lift our trade out of immaturity.

Schools generally pay worse than in-company training. However, to think of this topic only in financial terms is to neglect the cheap training that we ourselves have received, from masters who are also paid less than the market. In my opinion, it is our duty to maintain the circle, so that what is given compensates what is received.

A counter-power

The master has authority. This word is frightening, as many people who claim it have tainted it with their illegitimacy. Yet it is crucial in any human group, at all levels, on a subsidiary level.

At the lowest level, take a beginner and give them a request that they know is detrimental to their work and to the person for whom they are making it. They have no authority. Their opinion does not count. Their hand will be forced, unless their character leads them to intransigence, which is rare among beginners. They simply have no authority to impose themselves as an expert in their field. Their arguments are swept aside and unless they can present serious documentation as a source of authority, which is rare, they will not have the last word. By dint of being wrong, they will eventually come to their senses, “settle down” and keep quiet. What a loss for the trade! And yet we since at least the twentieth century – Hannah Arendt was prolific on this topic – that our societies do not need more little grey men, content to just follow orders silently.

The French government under Macron in his first term: only 3 ministers (Véran, Dupont-Moretti, Blanquer) had a job related to their portfolio in the 10 years preceding their nomination. Previous governments have not done any better. My point here is not to criticize any party in particular.

This reasoning and its conclusion can also be found at the highest level. Technocracy is to epistocracy what oligarchy is to aristocracy: an ape with a nuclear suitcase. A government of managers, consultants and ‘experts’ who have not worked hard since they graduated, does not guarantee competence in any field. It is not up to the government to choose who should represent a profession before the state, but to the masters themselves to choose their trustees. This system is as fallible as the people who make it up, but it has two advantages over technocracy: competence and authority.

Bad masters are inevitable, but under good institutions, they also represent a trade and act as regulators. Of course, one must learn from the mistakes of the 18^th century with its tight nepotism, as well as from the flaws of contemporary systems. If this work is done correctly, one master’s ‘no’ can prevent the work from perishing and the collective ‘no’ of a trade organized around its masters can do the same for their field, or even their nation.

This post follows the one about juniors.

Towards a culture of software quality

Fri, 22 Jul 2022 00:00:00 +0000

Poor incentives create a game where players benefits from producing poor code. Over time, the game weeds out stubborn players, leaving only those who produce poor code. Is there no alternative? Not if one takes a strategic approach.

Let's talk about indicators, performance and especially incentives. I have seen inane requirements such as these on Devops project offers:

HIS KEY PERFORMANCE INDICATORS :
- Number of fixes during the acceptance phase
- Performance of developed components (with benchmarks)
- Respect of the deadline in the implementation of the modifications
- Number of regressions " class="figure-img img-fluid"/>

Translation : HIS KEY PERFORMANCE INDICATORS :
- Number of fixes during the acceptance phase
- Performance of developed components (with benchmarks)
- Respect of the deadline in the implementation of the modifications
- Number of regressions

Let's imagine that I am an unscrupulous player, in a game called ‘software development’. These rule encourage me to type out the most despicable code possible quickly, in order to find as many bugs as possible during acceptance tests. My manager will then congratulate me and give me a nice bonus. My code will be fixed through regression testing and become exploitable eventually, but my interest is that each new feature is as dirty and buggy as possible. Such rules foster the hero syndrome.

This is of course a caricature. Upon leaving school most developers do not have this mindset. But they can acquire it, thanks to incentives. I believe game theory is an interesting perspective to start from on this topic.

Group psychology

A manager decides to recruit a whole team of juniors and formalizes their objectives on a contract. At first, nobody pays attention to these indicators and they generate neither reward nor sanction. Everyone will do their best, or not, depending on the day. The objective will only become visible after a few pay slips, discussed and compared around the coffee machine. The players get to know the rules little by little.

Let's take a closer look at two developers from this team. Alice practices TDD and never pushes code that was not properly tested. Bob modifies the code, checks that the pre-existing tests go smoothly, but will only write new ones if a bug occurs. Indeed, the reappearance of an identified bug is a regression, and this means a pay cut. Bob is smart.

Then comes the time for acceptance testing. There are few issues with Alice's code, whereas Bob's untested code generates many bugs. The manager will see a rather serene Alice working her hours quite normally. Bob, on the other hand, does not seem to count the hours he spends debugging the project, gets worked up, grumbles and exhausts himself to meet the deadlines. And in terms of objective measures, the manager's Excel sheet will show that Bob has fixed more bugs than Alice.

Bob is careful and knows that a regression means a pay cut. So he makes sure to test his bug fixes, by practicing zealous defect testing. Everything encourages him to do so, and this is a good thing, but wouldn't it have been better if these bugs had never existed?

At the end of the month, Bob will have a more substantive bonus than Alice. Worse: managers will have a better opinion of him, he will appear as more present, more involved and more supportive than Alice! Her frustration is slowly building. Several months down the line, she will be fed up. She will run down the slope of resentment and will carry out the following actions:

Help Bob. Let's assume Alice is kind. She will explain to Bob the value of writing good code. But should he be willing to change, it is not in his interests to do so. If he stops generating bugs, he will lose his pay and no longer be in the management’s good graces! So Alice starts to ...
Hate management. Alice maintains a good relationship with Bob, and even tries to turn him into an ally. She tries to plead her case to management, but the subjective perception of the difference between them will not work in her favor. She will be seen as a bad student who tries to move the goalposts, or even as nothing more than a jealous colleague. Bob has no interest in going beyond passive empathy. Alice will eventually blame him and come to ...
Hate Bob. Since he doesn't deserve the money, he has to pay for it in other ways. Bob is favored by management, which makes it difficult to denigrate him directly. If she hasn't quit already, Alice will lower her quality standards so that Bob no longer benefits from HER work. His standard is botched work? OK, botched work it is then.

For the sake of the narrative let's assume that Alice did not quit. She has become a Bob. At first she adjusted her behavior out of jealousy and spite towards him. As the months go by and her compensation increases with management approval, Alice eventually forgets her initial situation. She has become a better player, considering the rules.

5 years later, it does not matter whether the technical referents, managers and Lead Devs are Alices or Bobs. The were different at first but have now become totally interchangeable. The objectives may even have disappeared in the meantime. The company’s corporate culture has integrated practices that will be very difficult to change.

In team management, as in satellite orbiting, a small change of trajectory, though painless at the beginning, can have catastrophic consequences at the end.

What is to be done? Strategic options.

I went down Alice’s road, but I left before my hatred of the game turned into hatred of the players. I took a step back and came up with a strategic response to the problem.

This situation is a variant of the Monkey Theorem, which can be found as much in business as in politics or in technology usage patterns. Using empiricism, I have so far found three solutions for those who refuse to end up like Alice:

Counter-culture. This is currently the main option, embodied by the software craftmanship movement: going freelance, working with clients ‘who get it’ (Arpinum's slogan), hanging out with other craftsmen on places like Okiwi. The idea is to create a market for quality code, coexisting alongside the market for mass-produced code.
Infiltrating management. In France, since the Vichy period, it is management that initiates change, the rank and file can only comply. I suggest that developers agree to play the game and get in through the back doors of training, consulting, coaching, HR, in short, cross-functional corporate functions, all the better to contaminate the big players. The idea is to change practices ‘from the top’ in key accounts, and turn them in the hope that the market as a whole will mimic them.
The power struggle. In this scenario, Alice stands her ground. She refuses to hate Bob, gives in to management on incidental stuff, but makes no concession on quality. This requires great determination and a good knowledge of labor codes. The goal here is to occupy, to last, to convert and to influence. The model followed here is that of a union: hang on, hold on, wear the enemy down and show that you are right.

I am not claiming that one of these strategies is superior to another. My conviction is that only a mix of the three will allow the shift towards a culture of software quality. I simply want to open new doors. Too many articles just bemoan the damage caused by poor software quality and explain its causes and the solutions on a purely operational and technical level. My purpose is of a strategic nature: how can we put an end to Therac-25, MasterNet, Denver Baggage Handling System?

This article is the first of a tetralogy. In the next ones, I will discuss each of these avenues in detail, highlighting the benefits and shortcomings of each. More importantly, I want to link each strategy with personality types, to provide guidance to those who want to see change in our trade.

Craftmanship is not primitive engineering

Fri, 22 Jul 2022 00:00:00 +0000

Lewis Mumford (1895-1990)

The notion that industry is the necessary evolution of any craft is a platitude that is strongly anchored in the contemporary mind. In the second half of the twentieth century, a major trend originating with Lewis Mumford[i] swept through most of the disciplines that were taken for granted by industry: architecture, furniture and even agriculture. It is called the vernacular style[ii], from Latin vernaculam: homegrown, and seeks to reconcile science and tradition, productivity and beauty.

My profession, software development, did not exist when the vernacular style emerged and its inclusion in this debate only occurred in the 2000s, with the software craftsmanship movement. A lively debate opposed the proponents of ‘Taylorist’ software engineering to those of software craftsmanship[iii] which would soon part with the agile movement. The controversy revolves around the lens with which we should read the emergence of the IT industry between the 70s to the 90s. The historical qualitative failure of software development, which the Standish Group is so passionate about[iv] was analyzed and interpreted in different ways by both camps.

The methods of the 1970s were clearly a recipe for failure for the profession.

Software craftsmanship argues that the disaster originates in the shift from the craft practices of the 1960s to waterfall methodologies. In these, value is the result of a streamlined industrial process in which the developer has no driving role. Software craftsmanship pleads for an iterative and incremental process of software design, where a small team decides collectively with the client on all design choices. Paul Taylor[v] sees this rhetoric as entirely derived from the vernacular school and based on an empiricism that its practitioners endorse explicitly. The strong presence in the trade of former hippies sympathetic to the ideas of Marcuse and Illich, may well be one of the causes of this movement, but this is a personal hypothesis. To my knowledge, no study of the origins of this school of thought has been carried out.

Vernacular architecture, or architecture without an architect. The analogy has extended to other fields, including software development.

On the contrary, for the supporters of engineering, whose arguments are summarized by Ivar Jacobson and Ed Seidewitz[vi] development has failed because of a lack of rigor in its methods. The authors do not denigrate craftsmen, who are the source of many very beautiful thing. However, they consider that arts and crafts are by nature inefficient, because they are not repeatable and therefore not open to optimization. Only the practice of engineering, a ‘craft supported by a theory’, would allow software development to move forward. According to the authors, engineering standardizes the practices of different masters and different schools behind a common theory.

Several questions are implicit in this debate. First, is the craftsman really that allergic to science? In other words, isn’t it fallacious to accuse the traditional way of transmitting knowledge of going against science? Second, does any craft have no choice but to progress into engineering, any vernacular practice into an industry, any tradition into a science? Finally, is it appropriate for a developer to identify with the figure of the craftsman? This paper will try to provide an answer to all three.

Is the craftsman an unwitting technophobe?

In the 14th century, Etienne Marcel, then provost of the merchants of Paris, held the King of France in respect! As the leader of the small craftsmen and journeymen, who were a majority in Paris at the time, he knew that he was more powerful than the King, whom he wished to have controlled by the guilds, three centuries before England’s Glorious Revolution. It is largely due to him that the popular imagination associates craftsmen with the Middle Ages, when they were very powerful.

Daniel Bernouilli (1700-1782): physician, physicist, mathematician and astronomer. A typical polymath of his time.

What a downfall it was when the trades were abolished on June 14, 1791 by the Loi Le Chapelier[vii]! It was also at the end of the 18th century that the scientific method really took off, gradually closing the period of the great scientists of the Modern Era. Polymaths gave way to armies of specialists: physicists, biologists, archaeologists, etc.

Because of this temporal correlation, a distorted image of the ‘Ancien Régime’ has formed, a period going from the High Middle Ages to the Modern Period, with its craftsmen gathered in guilds, its musketeers, its carriages and its wigs. Fantasy and medieval sub-cultures did not help by definitively linking the craftsman to this ‘era’.

However, correlation is not causation. This argument cannot be enough to label craftsmen as ‘anti-science’ or relegate them to Renaissance fairs.

A second argument against craftsmanship targets the transmission of knowledge through apprenticeship, which may also be called transmission by tradition. It is accused of creating silos that are harmful to the universal sharing of technical knowledge. And indeed, master craftsmen had their secrets, which could be lost in the fragile process of their transmission to a single apprentice. However, this problem is not specific to crafts, but to any business based on knowledge. The opacity of industrial secrets, patents and expensive academic journals has replaced that of guilds, so this argument cannot be used against crafts alone.

Without Alexandra Elbakyan, no one could access global scientific literature without paying heavy royalties to largely superfluous publishers.

I argue that the level of the available technology is the main issue at stake here, and that industry would have done no better than the crafts of past centuries with the same technological means. Recent advancements in printing and publishing fostered the development of today’s knowledge production channels. In our century, access to academic literature has never been so easy, many journals are freely available, even if one has to go through channels that are more legitimate than legal[viii].

Nowadays, anyone who wants to work based on scientific facts can do so, whether their mode of production is tradtionnal or industrial. The professionals around me work in fields as diverse as computer science, art and construction, but they all base their work on knowledge acquired during their initial training. The bricklayer or carpenter knows the basics of mechanics, the illuminator has a basic understanding of chemistry, and any self-respecting developer must have a modicum of interest in best practices. None of these professionals can afford to be too far behind the times. This observation is as true for employees in the industry as it is for craftsmen, who often received the same training.

It is after graduation that things become more complicated. Very few professionals continue their training and few are interested in the academic literature. As they have no other incentive, most wait for restrictive standards to be released to resume their training. Unfortunately, the same behaviour can be observed among physicians, even though they are, in theory, required to continue their education. It is probably a matter of culture, and the craftsmen are in the same boat as the industrial workers.

Among developers, apart from academics themselves, interest in academic work is mainly found in the software craftsmanship movement. I have a strong bias due to my own personal circle, but I have never met a colleague who did academic watch in the industry, their main obsession being the latest tool/language/framework.

This humorous sticker might hit home a lot more than expected.

When these simple and largely fallacious arguments have been exhausted, all that remains against craftsmanship is a very old discourse in the history of ideas: the blunt contrasting of science and tradition, where the latter stands accused of promoting dogmatism, irrationality or immobility. I will try to deconstruct this in the second part of this paper.

The craftsman is not an imperfect engineer.

Lorenzo Cifonelli, master tailor. His existence is not incompatible with that of a clothing industry. This is certainly a craft of civilization.

All the current industries that are recent creations emerged from a formerly artisanal field. I know of no discipline that has gone the other way. And they all coexist with an older traditionnal counterpart, which has always survived with an emphasis quality and high level of customization. One thing textiles, automobiles, butchery or catering share is that the presence of a majority industry has never eliminated what Bruno Lussato calls a ‘craft of civilization’ [ix].

Craftsmanship is as old as the tool and will never disappear totally in favor of industry. Its main advantage, which guarantees its survival in lean times, is resilience. Whereas engineers are process specialists, craftsmen are specialists of a raw material. They do not produce a specific good, but have extensive knowledge of a material and the tools needed to shape it. To put it in one word, they can adapt.

Monoculture means mono-outlet.
Translation: 450 tons of unsold potatoes due to the lockdown. Villiers-Herbisse, Aube. Agriculture: a commercial potastrophe.

The Covid crisis confirmed this theory: the artisans were at the forefront of mask production, long before the industrialists managed to reorient their production, when their machines enabled them to do so. And the most diversified and least industrialized farmers were the ones who best weathered the crisis (without wasting public money, I mean).

The craftsman will never have the capacity for optimization that the industrialist has, which makes him less competitive during the good times, in the fields where low cost in mass is an obligation. But he makes up for it in the long run through resilience and adaptability, as he is less vulnerable to contingencies than the industry. The craftsman is a complete producer, both a worker and a manager, often in direct contact with his customers. Taylor notes that this makes the product feedback loop very agile, with the craftsman able to design in very small increments and not burdened by the weight of the industrial process.

Craftsmanship is not a profession, but a mode of production, which has existed and coexisted with industry since at least the 10th century. It is not a baroque or diminished industry, but another way of producing: less optimized, but more resilient. Industry and craft are in no way mutually exclusive in any given sector. All luxury sectors are industries that include a large part of craftsmanship at the end of the chain. The respective shares of craft and industry in a given sector is essentially a political and strategic question. Eradicate craftsmen and you will eradicate costs, at the expense of a total lack of resilience and adaptability, even an absence of civilization according to Lussato. Ban industry, and you get a society ill-equipped for economic warfare and modern warfare altogether, unable to defend its political choices against foreign powers.

I will go further: no strategic sector can afford to be completely industrial or completely artisanal. To oppose the two is silly, especially in a country like France, which has a true hybrid culture. On the global stage, an economy always loses by choosing one or the other.

French exports in 2014. A mix of crafts and industry. Source : Wikipedia.
Translation:
Aircraft, spacecraft and launch vehicles

Cars

Motor vehicle parts and accessories

Turbojets, turboprops and other gas turbine engines

Packaged drugs

Petroleum oil, refined

Wheat and meslin

Fresh grape wines

Metal jewelry

Trunks or cases of any kind.

Conclusion

This synergy between crafts and industry is also present in the relationship between their cognitive underpinnings: tradition and science. Too often (stupidly) opposed, these two modes of knowledge production are inseparable.

The Chinese Pyramids of Xixia. Is it the Annunaki or the Atlanteans this time?

First, because no industry exists without tradition and no craft exists without science. What is the reason behind the contemporary standard railroad track gauge? Because the axles of Roman chariots were standardized a long time ago[x]. Why are certain structures, such as pyramids, found all over the world, despite the absence of interaction between their builders? ~~Because a race of reptiles has been moving under the earth's surface for thousands of years.~~ Because the people who built it had deduced empirical laws from the study of nature, well before the conceptualization and standardization of the scientific method, which did not invent science but only a step towards more rigor. Craft has been based on theoretical knowledge since the first stone tool.
Secondly, because pure science is not applicable as is. It must be applied to serve practitioners. And applied to what? To a body of knowledge, transmitted in a traditional manner, precisely. Science comes to refine and increase the knowledge of a craft as discoveries are made, but it is indeed professionals, trained by teachers and masters, who must apply it to their work.
Finally, because a frozen tradition does not survive, except possibly in museums. A craft that ceases to amend its body of traditions with each generation dies. Frozen traditionalism is not viable from an economic standpoint, but it goes even further: a craft that does not evolve the way it amends its tradition with each generation is not viable. With each generation, the way science and tradition interact with each other must also be renewed!

Craft and industry have no fundamental difference in their relationship to science. Any difference between the two is one of degree but not of kind. The craftsman may have a more conservative approach than the engineer. The fundamental difference between these two characters lies in the mode of production, thus in the characteristics of the final product.

A book that should be used for case studies by students.

This is exactly the conclusion I will apply to software development. A software craftsman is not an anti-engineer who denies certified best practices™ in favor of the teachings of obscure gurus. He has no issue with science, which he gladly uses (more than the average developer) to keep a critical eye on what a community member, certified master or mere peer, teaches.

The software craftsman is, above all, free from the enormous track record of methodological failures of the last 40 years. He was there when programming came about, was forgotten in the era of waterfall methodologies, and came back in the 2000s. The academic literature proves the craftsmen right about practices that have been adopted in their communities for decades. Worse: there seems to be no way out of the impasse in which all attempts to make software a formal discipline, with solid theoretical and mathematical foundations, find themselves

We continue to build castles of wind, towers of thought, in a purely empirical manner. The material we are sculpting is so peculiar that it would be legitimate to ask ourselves, finally, if it is not software engineering that lacks meaning? Some professions cannot be approached in any other way than through an industrial logic. Perhaps with software development we have a case of a profession that only craftsmen can truly practice.

Opposing crafts and industry, whether at the level of a sector or that of a country is silly. This does not exclude the possibility of trades for which one or the other of these forms is counterproductive. I would argue that software development is, as far as we know, one of them.

[i] Technique et Civilisation (1934) ; Paris, Le Seuil, 1950 ; Marseille, Parenthèse, 2016

[ii] https://en.wikipedia.org/wiki/Vernacular_architecture

[iii] http://manifesto.softwarecraftsmanship.org/

[iv] The Standish Group, CHAOS Report

[v] Taylor, P. (1). Vernacularism in Software Design Practice: does craftsmanship have a place in software engineering?. Australasian Journal of Information Systems, 11(1). https://doi.org/10.3127/ajis.v11i1.143

[vi] Jacobson, Ivar & Seidewitz, Ed. (2014). What happened to the promise of rigorous, disciplined, professional practices for software development?. Queue. 12. 10.1145/2685690.2693160.

[vii] https://fr.wikipedia.org/wiki/Loi_Le_Chapelier

[viii] https://fr.wikipedia.org/wiki/Sci-Hub

[ix] Lussato Bruno, La Troisième Révolution

[x] It is quite possible that this explanation itself, impossible to source, is a tradition. It exists because no researcher has come to verify it, one way or the other – another illustration of the intimate link between science and tradition.

Are juniors worth anything ?

Fri, 22 Jul 2022 00:00:00 +0000

Our trade is wasting the potential of its juniors. Sold right out of school as turnkey products, they are a cheap and very malleable workforce for employers, middlemen tech companies in particular. Because of the enduring myth of the man/month, they are required to be as productive as seniors for the same tasks. This is neither a service to the juniors, nor to the company. So what are juniors good for anyway? This paper, which may read like a defense for my (former) students, tries to provide an answer.

This article is a continuation of my strategic statement. However, it can be read independently.

A junior is any professional who, owing to a lack of experience and therefore of confidence, is unable to identify or refuse situations where the rules of art are violated.

This is a very broad definition, including inexperienced developers as well as Expert Beginners, who find implausible situations normal because they have always worked that way. It is loosely based on apprenticeship in France during the Ancien Régime. A young apprentice only became a journeyman when he could demonstrate his ability not to pose a danger to himself or to the profession. He was confined to odd jobs and training projects until his master deemed him worthy.

The situation is exactly the same with junior developers: they lack the experience to be aware of the danger of doing things wrong. The one enviable they have going for them, compared to their colleagues working in the world of physical objects, is the ease of editing, and therefore of rectification, that code offers. The apprentice developer can therefore be yoked to production tasks safely and with little to no trouble, as long as everybody remembers that he is only a junior until proven otherwise.

A profession of children

Unfortunately, many companies, mostly out of ignorance, treat juniors as if they were not. The junior is often a good programmer, but a developer in the making. In the short term, their output may look good enough. Only in the medium term, when judged on quality parameters such as maintainability, reusability and accidental complexity of the code, will the junior fail.

In any other industry, a well-informed manager would have noticed the quality problem and traced it to its source, even the forgotten contribution of some junior who was little too wet behind the ears at the time. This does not happen in software development, because what a manager expects of his developers is not the elusive quality, which is more often mentioned than encountered nowadays, but simply that they keep their heads above water for one more iteration. The developer has replaced the mechanic in popular imagery.

Worse, developers often show as much resignation as their managers. Most have never seen a quality project or never even heard of a happy developer at work. Too many have accepted the grind, the mediocrity they have been subjected to, and expect to ‘move on to project management’ or to another trade, with no regrets.

Our job is 70 years old, and has boomed for the last 30. This is not reflected in its demographics.

Our field is composed of irresponsible children, and if the defendants were to sit on a dock, the juniors would be the only ones not on it. We are all responsible for this mess.

The teachers remain in their ivory towers, no longer willing as they are to teach in schools for the price they are offered, and reserve their services for a few companies ‘who get it’.
The schools make do with the lecturers they find at market price, which is largely determined by the money that companies are willing to put into cooperative training courses.
Companies often don’t understand this and think, with good reason, that it is better to go for the cheapest option and take on juniors who can be easily sorted out, whereas hiring a ‘senior’ will, in most cases, be the same as hiring an Expert Beginner who is as competent as a junior, but at twice the price.

We are stuck, on a systemic level, in a vicious circle of incompetence and lack of accountability, and there is no single solution to it. And the only ones who can act are the developers who are aware of the problem.

Sympathy for juniors

I do not think of myself as a master. I do not think I have reached the level to claim this title. However, I have not seen myself as a junior for several years. I came out of it almost randomly. Someone showed me the way and I managed, somehow. Not everyone was so lucky and the losses are immense, like sparrows flying off an airport tarmac.

Creating a culture of software quality, as I discussed in another article, will take time. Masters need to come down from their ivory towers. Working in a software workbench, surrounded by other masters is of course a necessary retreat, and I know only too well how grueling the management of beginners can be. However, too many masters are totally cut off from the juniors. There is no bridge, and not even that spark that would be enough for some to start their hazardous personal journey towards quality.

Tar Valon, in Robert Jordan's Wheel of Time. An interesting allegory of the ivory tower.

Are juniors worth anything? Yes, we give back what we received. We often go down the road of quality by chance encounter. This is largely inefficient, but that’s how it is. Creating the conditions for a massification of quality is a long-term project. Pragmatism demands that we continue to pass on knowledge in this way for lack of anything better. To this end, I identify three levers that constitute the strategy of infiltration described in the above-mentioned article.

Teaching at CS schools. Even though the pay is much lower than corporate training. It’s a militant act that pays off. In-house training is like angling, whereas teaching in a school is like net fishing. Many students hear and few listen, but that’s more people than just the professionals ‘who get it’.
Giving prospects a chance. A customer with shaky practices, but willing to learn from his mistakes, is an valuable opportunity on all levels, human as well as economic level. It’s a win-win relationship, especially if it helps boost the morale of a depressed team. For this, academic research is a remarkable tool. You’re not hearing the advice of a single expert, but reading the literal state of the art!
Accompanying company founders. It is through future CEOs that software quality can be injected into the corporate cultures of tomorrow. Unfortunately, this is also the least profitable job, as the future CEO rarely has the means to pay an expert. The wisest ones will see this as an investment. If you train decision-makers from the incubator, they will probably call on you after their fund raising.

Just because a goal requires long-term strategic planning does not mean that it is impossible to act in the short term. Juniors are a tremendous lever. It will take about 5 years for a trained and motivated junior to be able to pass on his knowledge. This is short and therefore contagious. The Covid crisis showed the potential of contagious processes.

This post have a continuation about masters.

Training as a craftsman

Sat, 07 Nov 2020 00:00:00 +0000

In a company, one rarely choose their training courses. The anticipation of needs by the management often determines the schedule. For those who are self-employed, and even more so for craftsmen, training is a demanding task and a matter of personal discipline.

Preparing cuttings to create hedges. One of the first things to do when settling somewhere in is to mark out the boudaries.

Having stopped working as a salaried employee and then as an on-site freelancer has allowed me to regain control of my schedule. Not having one full-time client, but several simultaneously, offers many down times, from a few hours to several days. I use the longest of these to reinforce my personal autonomy. At any time of the year, there is always work to be done. The shorter pauses offer less freedom. Taking out the tools and putting them away takes time. Moreover, the brain hates it when context changes abruptly and wastes time trying to find its way around. Better stay focused on the same type of activity then. Extended learning is a great fit for these medium-sized open slots – between half a day and an hour. For anything shorter, a clear break is the best investment.

That settles the question of 'when to train'. But to do what exactly? Here is my personal recipe, with no pretence to any authority.

I train using 3 families of sources, each with its own temporality. This diagram is a rough assessment of the value of each source. Science and books offer solid knowledge that has been verified and often designed to last. This is not the priority on the Internet, which is more likely to be a place for debate and experimentation. Of course in reality things are more complex. Some blogs like Mark Seemann's or Martin Fowler's are somewhat authoritive and it is not uncommon for researchers to write about the latest and most ephemeral trend and be publish. Like any model, this diagram is wrong, but useful.

The rest of this paper presents each of my sources of knowledge. You can jump directly to the one that interests you.

The foundation: books.
The professional conversation: videos, blogs, podcasts.
The state of the art: research papers.

The books

A good book is a robust body of knowledge, a basic brick in a developer's continuing education. Every profession has its authoritative sources. Ours is no exception: Martin Fowler, Uncle Bob Martin, Osherove, Hunt&Thomas, etc. There are already tons of 'must-haves' lists on the Internet, so I won't list my entire pro library.

The cost of the technical books is the first obstacle to acquiring them. 50€ is not an unsual price for this type of book, large and with a small circulation. The most popular ones are rarely available second hand. And I personally hate annotating books, which leads to an inelegant post-it-fest on them.

Some classics I recommend.

Having books is mandatory for a developer, you can't do without them and any additional knowledge will build on this foundation. If your shelves are empty, I recommend starting there. Only then can you explore what researchers and practitioners have produced most recently.

To find good books, I have two methods: asking for recommendations in the community and looking at the most cited books in scientific papers. This way I have a good chance of not investing in disappointing books. I tend to miss the latest publications, but I accept it because that is not why I buy books.

Pros	Cons
High density of information	Key knowledge
Key knowledge

Research papers

Collecting and reading research papers accounts for about 2/3 of my training time. About half of it is reading. The rest is spent tracking references, filing, downloading and printing articles.

A beginner would be better off reading the classics and practicing for a few years, otherwise scientific knowledge may seem dry and very abstract to him, because his limited experience bars him from having encountered yet practical applications for what the articles discuss.
A non-English speaker will have no access to 99.99% of the papers. English being the Latin of computing, learning it is not an option.
A non-English speaker will have no access to 99.99% of the papers. English being the Latin of computing, learning it is not an option.

With these precautions in mind, I will share my method. I have been refining it for 3 months and using it successfully.

It all starts with a simply Google Scholar search on very vague topics. The more vague the better, we'll see why next.

The binder where I store the articles I want to keep.

The results arrive by mail, I sort them first by their title, and a second time by their abstract. I store the interesting articles to print them in batches, as I hate reading long documents on a screen).
Now comes the time for reading. I do a first quick superficial reading. It allows me to make 2 stacks. The first one will be read in more detail later. The second one will only be used to extract interesting references (this is notably the case of meta-studies, which are not always useful to non-researchers).
I extract the references of all the papers I read. They will be mixed with the Google Scholar results to perform the next iteration. The referenced books are noted in a notebook. The most cited book is likely to be ordered.
I sort the papers I want to keep by their major themes, with a post-it note for each summarizing its interest and possibly bookmarks. They are intensely highlighted.

A full cycle takes about a week. I have not yet found a viable method to manage periods of intense scientific activity. For now, the unread papers pile up without constituting a major inconvenience. The reading order is perfectly arbitrary, I read according to my fancy.

Pros	Cons
Solid knowledge, often verified	Often difficult to read
Present the techniques of tomorrow	Long and tedious sorting process

Videos, blogs et podcasts

The professional conversation is the last family of sources in my order of priority. This is for many reasons :

Following it is exhausting. Everything moves very fast. Good tools are necessary, but they only make sourcing work slightly less painful.
The community produces a lot of noise and drama. Many leading professionals have trouble separating their expertise from their strong opinions, especially during major political events. When the ‘opinion’ and ‘expertise’ channels aren't separate, even the best monitoring tool drowns in noise
I am mostly satisfied with the two previous sources. The solidity of the great authors mixed with the latest discoveries of the researchers is an effective mixture.

A watch that has been neglected for 2 years is not a pretty sight.

This is strongly felt in my technical watch, which is completely neglected and eaten up by product placements. That's why I won't give any advice in this article. I plan to get my technical watch back on track, capitalizing on the knowledge I acquired at the École de guerre économique. An article will come out of it, some day.

Pros	Cons
Immediately applicable	Very variable quality
Easy to share	Lots of noise and drama
	Strong investment needed to keep one’s watch up to date.

Conclusion

We are what we eat. This is true for the mind as well as the body. With the Internet, the temptation of intellectual nibbling is great: to learn only about fashionable technology, while neglecting the more substantial works that give us substance. Often less accessible, they only reveal their secrets to those who take the time to learn how to cook them. This is true for books, but especially for scientific papers. Unlike their peers in other sciences, CS students never hear about research during their initial training and barely have any notion of it. If I had not come across zetetics and the world of popular science, I would have missed an abundant and precious source of knowledge.

Atelier Logiciel Sandré

Why do we need master craftsmen?

A social role

A counter-power

Towards a culture of software quality

Group psychology

What is to be done? Strategic options.

Craftmanship is not primitive engineering

Is the craftsman an unwitting technophobe?

The craftsman is not an imperfect engineer.

Conclusion

Are juniors worth anything ?

A profession of children

Sympathy for juniors

Training as a craftsman

The books

Research papers

Videos, blogs et podcasts

Conclusion