Jonathan Lalou's Blog

A short reminder: in a try/catch/finally section, the block in the finally is always executed. “Always” means “even if a return statement is reached in the try or catch“.

A short piece of code shows more than a long speech. The following JUnit test ends with no error:
[java]package com.stepinfo.poc.cartography;

import org.junit.Test;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNotSame;

/**
* Created with IntelliJ IDEA 12 "Leda" CE
* User: Jonathan LALOU
* Date: 08/Apr/13
* Time: 22:41
*/
public class TestTryCatchFinally {

public static final String TRY = "try";
public static final String CATCH = "catch";
public static final String FINALLY = "finally";

private String tryVersusFinally() {
try {
return TRY;
} catch (Exception e) {
return CATCH;
} finally {
return FINALLY;
}
}

private String catchVersusFinally() {
try {
throw new RuntimeException();
} catch (Exception e) {
return CATCH;
} finally {
return FINALLY;
}
}

@Test
public void testTryFinally() {
assertNotSame(TRY, tryVersusFinally());
assertEquals(FINALLY, tryVersusFinally());
}

@Test
public void testCatchFinally() {
assertNotSame(CATCH, tryVersusFinally());
assertEquals(FINALLY, catchVersusFinally());
}
}
[/java]

Case

Here is a case of stupid error. I started up a new project in IntelliJ IDEA, laying on a Maven archetype. On launching the first unit test, I got the following error:
[java]Cannot instantiate test(s): java.lang.SecurityException: Prohibited package name: java.lalou.jonathan.multiposts[/java]

Quick fix

As you may have noticed, the package name was prefixed with java.… which is prohibited by the JDK. An immediate fix is to restore a package name not starting with java..

The code in the JDK is explicit: the exception with such a message is raised in a unique occasion:
[java] if ((name != null) && name.startsWith("java.")) {
throw new SecurityException
("Prohibited package name: " +
name.substring(0, name.lastIndexOf(‘.’)));
}
[/java]

J’ai eu la chance d’assister a la derniere journee de DevoxxFR a Paris, le vendredi 29/03/2013, pour le compte de mon employeur StepInfo, sponsor de l’evenement. Voici quelques impressions en vrac

General

• C’est bien organise, il y a du monde, et excepte au moment du depart au niveau des vestiaires, il n’y a pas eu de gros souci de logistique.
• Les entreprises sponsors ont joue le jeu 😉
• Que ce soit au niveau des stands ou des conferences, la domination des Mac est ecrasante! Google a reussi a mettre en valeur ses ChromeBooks, mais j’ai vu peu de Windows et encore moins de Linux.
• J’ai pu assister a 4 conferences, toutes interessantes, mais d’un niveau heterogene, je reviens dessus plus en detail ci-dessous.

IDE Java : astuces de productivité pour le quotidien

La conference est animee par Xavier Hanin (@xavierhanin). Il y presente les trois IDE phares du monde Java: NetBeans, Eclipse et IntelliJ IDEA.

Maitrisant plutot bien IDEA, je n’ai pas appris de choses fondamentales sur mon IDE, si ce n’est le raccourci Ctrl+Shift+A pour afficher les intentions. J’ai connu NetBeans a ses debuts (Forte puis Sun ONE), mais j’en ai totalement perdu la maitrise depuis des annees. Quant a Eclipse, il m’arrive de le lancer quelques fois par an pour des problematiques clients specifiques, mais je suis contraint d’avoir recours a la souris en quasi-permanence ; sous IDEA c’est tres rare.

Un “sondage” assez grossier des personnes dans la salle a donne des resultats interessants: ~15% des developpeurs presents utilisent NetBeans, ~25% IDEA et ~90/95% Eclipse.

Quick Start avec le Cloud Google

La conference est animee par Didier Girard de SFEIR et Alexis Moussine-Pouchkine de Google France. Les principaux outils de Google pour le cloud sont presentes, en prenant pour hypothese de creer une startup: une solution “a l’ancienne”, avec serveurs d’applications, gestion materielle etc. est avancee, avant de ceder la place a une solution entierement sur le cloud de Google.

En un mot: c’est tres convaincant.
Je regrette que le sujet n’ait pas ete elargi vers des solutions cloud alternatives, comme celle d’Amazon.

• Didier Girard:
• Sur twitter: @DidierGirard
• Sur Google+: +Didier
• Alexis Moussine-Pouchkine:
• Blog: http://alexismp.wordpress.com/
• Twitter: @alexismp
• Google+: +Alexis

The Spring Update: Looking at Spring 3.1, 3.2, and 4.0

La presentation est menee par Josh Long de SpringSource. On se rend compte tres rapidement que ne serait-ce que pour la qualite du show, nous les Francais (voire les Latins) nous sommes largement en dessous de la qualite des Anglo-Saxons.

Josh enonce ses concepts, donne des exemples, met l’eau a la bouche. Au bout de 50′ de conference, je n’ai plus qu’une envie: retourner coder avec les dernieres versions de Spring!

Parmi toutes les nouveautes, j’en retiens deux:

• l’AnnotationConfigApplicationContext, qui m’evitera de taper d’ecrire un bloc comme:[xml]    <context:component-scan annotation-config="true" base-package="lalou.jonathan.beans"/>[/xml]
• l’integration future des websockets d’HTML5 pour obeir a la norme JEE7 d’ici la fin de l’annee.

Ce dernier point m’interesse particulierement, en raison d’un projet sur lequel je travaille actuellement, et dont nombre de problemes seraient resolus par les websockets de JEE7. Theoriquement, et potentiellement, d’ici la fin de l’annee 2013, nous pourrions integrer une brique “Spring JEE7” avec websocket au sein d’un WebSphere 8 (donc non JEE7-compliant), au lieu d’etre dependant dans la prochaine release du serveur d’applications d’IBM.

Josh:

• sur twitter: @starbuxman
• sur son blog: http://joshlong.com/
• Google+: +Josh

Entre HPC et big data: un case study sur la simulation du risque de contrepartie

C’est la conference dont j’ai vu le moins le rapport avec Devoxx, mais ayant passe 7 ans dans la finance de marche j’y ai trouve mon interet. En passant, j’y ai vu le seul PC sous Windows de toutes les conferences :-D.

Le theme de cette conference est: comment deporter une partie du calcul intensif de Monte-Carlo du CPU vers les GPU? Ces derniers ont une taille et une structure de memoire radicalement differente de celles des CPU (CPU+RAM pour etre plus precis). Les GPU permettent d’effectuer des masses de calcul en un temps bien plus faible (jusqu’a 99% de gain) qu’en architecture classique, moyennant une reecriture du code C en un autre langage adapte, par exemple OpenCL.

Les deux speakers, de Murex, sont Adrien Tay Pamart (visiblement pas tres a l’aise en mode geek) et Jonathan Lellouche pour la partie technique.

Durant les questions, l’existence de ponts Java vers OpenCL, comme JavaCL est evoquee. Il est dommage de ne pas avoir plus de temps pour creuser ce theme.

5 ans et 500 releases en 50 minutes !

La presentation est dirigee par Freddy Mallet  et Olivier Gaudin de Sonar.

La demonstration est rudement bien faite. Les dirigeant de SonarSource retracent, dans un ordre plus ou moins chronologique, les problemes, ou les impediments a-t-on envie de dire, rencontres en 5 ans sur Sonar.
Quelques themes forts: le context switching est une plaie, on ne gere pas une entreprise commerciale avec des clients comme un simple projet open source, etc.

• Freddy:
• Sur twitter: @FreddyMallet
• Olivier:
• Sur twitter: @gaudol

En guise de conclusion

Devoxx a repondu aux attentes que j’avais en y entrant:

• une journee de formation intensive et motivante
• revoir des “anciennes tetes”
• echanger des cartes de visite

Qu’il me soit donc permis ici de remercier StepInfo pour m’avoir permis d’acceder a cette journee, ainsi que les organisateurs de Devoxx pour le travail qu’il ont accompli.

Vivement DevoxxFR 2014!

Lecturer

Frédéric Le Mouël holds the position of associate professor at INSA Lyon within the Telecommunications Department and CITI Lab, while also serving as a member of the INRIA Amazones research team. His academic background includes a PhD from University of Rennes 1 focused on adaptive middleware for mobile computing environments. Frederic’s research spans component-oriented architectures, service-oriented computing, and dynamic adaptation mechanisms, with particular interest in bytecode manipulation as an enabling technology for runtime adaptation. The JooFlux project, which he presents, represents a culmination of these research threads.

Abstract

Frédéric Le Mouël challenges the perception of bytecode manipulation as an esoteric practice reserved for framework authors and programming language implementers, demonstrating its practical utility across the software development spectrum from application development to system instrumentation. The presentation systematically demystifies Java bytecode and the JVM’s execution model before examining multiple manipulation tools including ASM, AspectJ, Byteman, and the innovative JooFlux framework. Through live demonstrations and architectural analyses, Le Mouël illustrates how bytecode transformation enables aspect-oriented programming, runtime monitoring, adaptive systems, and performance optimization without source code modification. The session concludes with philosophical reflections on the power and responsibility accompanying low-level JVM access.

Java Bytecode Fundamentals

Java bytecode serves as the intermediate representation executed by the JVM, compiled from Java source through javac. Le Mouël examines the stack-based execution model:

// Source
public int add(int a, int b) {
    return a + b;
}

// Bytecode
0: iload_1
1: iload_2
2: iadd
3: ireturn

Each instruction operates on the operand stack, with local variables accessed through indexed loads and stores. The JVM’s verification process ensures type safety before execution.

ASM: The Foundation of Bytecode Manipulation

ASM provides a low-level API for generating and transforming class files. Le Mouël demonstrates method instrumentation:

public class AddTraceTransformer extends ClassVisitor {
    public MethodVisitor visitMethod(int access, String name, 
                                   String desc, String signature, String[] exceptions) {
        MethodVisitor mv = super.visitMethod(access, name, desc, signature, exceptions);
        if ("process".equals(name)) {
            return new AddTraceAdapter(mv);
        }
        return mv;
    }
}

class AddTraceAdapter extends MethodVisitor {
    public void visitCode() {
        mv.visitCode();
        mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
        mv.visitLdcInsn("Entering method");
        mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V");
    }
}

This transformation inserts tracing without modifying source code.

AspectJ: High-Level AOP Through Weaving

AspectJ compiles aspects into bytecode transformations. Le Mouël shows transaction management:

@Aspect
public class TransactionAspect {
    @Around("execution(* com.bank.*.*(..))")
    public Object manageTransaction(ProceedingJoinPoint pjp) throws Throwable {
        beginTransaction();
        try {
            Object result = pjp.proceed();
            commitTransaction();
            return result;
        } catch (Throwable t) {
            rollbackTransaction();
            throw t;
        }
    }
}

The AspectJ weaver transforms target classes at compile-time or load-time.

Byteman: Runtime Rule Injection

Byteman enables dynamic rule injection into running JVMs:

RULE Trace method entry
CLASS com.example.Service
METHOD process
AT ENTRY
IF true
DO traceln("Entering process")
ENDRULE

Le Mouël demonstrates hot-patching production systems for debugging.

JooFlux: Research Framework for Dynamic Adaptation

JooFlux introduces a registry-based approach to bytecode manipulation:

JooFlux.register(new Interceptor() {
    public void intercept(Call call) {
        if (call.getMethodName().equals("process")) {
            System.out.println("Intercepted: " + call.getArguments());
            call.proceed();
        }
    }
});

The framework maintains original bytecode for potential restoration.

Links:

• Video URL
• ASM Documentation
• AspectJ Project
• Byteman Project

During DevoxxBE2012, Hadi Hariri, a developer and technical evangelist at JetBrains, presented an in-depth evaluation of Kotlin, a then-emerging programming language designed by his company. Hadi, with his background in software architecture and web development, aimed to assess whether Kotlin could address common pitfalls in existing languages while serving as a versatile tool for various development needs. He began by providing context on Kotlin’s origins, noting its static typing, object-oriented nature, and targets for JVM bytecode and JavaScript compilation. Licensed under Apache 2.0, it was at milestone M3, with expectations for further releases leading to beta.

Hadi explained the motivation behind Kotlin: after years of building IDEs in Java, JetBrains sought a more efficient alternative without the complexities of languages like Scala. He highlighted Kotlin’s focus on practicality, aiming to reduce boilerplate and enhance productivity. Through live coding, Hadi demonstrated building a real-world application, showcasing how Kotlin simplifies syntax and integrates seamlessly with Java.

One key aspect was Kotlin’s concise class definitions, where properties and constructors merge into a single line, eliminating redundant getters and setters. Hadi illustrated this with examples, contrasting it with verbose Java equivalents. He also touched on null safety, where the language enforces checks to prevent null pointer exceptions, a frequent issue in other systems.

As the session progressed, Hadi explored functional programming elements, such as higher-order functions and lambdas, which allow for expressive code without excessive ceremony. He built components of an application, like data models and services, to test interoperability and performance.

Syntax Innovations and Productivity Gains

Hadi delved into Kotlin’s syntax, emphasizing features like extension functions that add methods to existing classes without inheritance. This promotes cleaner code and reusability. He showed how to extend standard library classes, making operations more intuitive.

Data classes were another highlight, automatically providing equals, hashCode, and toString methods, ideal for immutable objects. Hadi used these in his demo app to handle entities efficiently.

Pattern matching via ‘when’ expressions offered a more powerful alternative to switch statements, supporting complex conditions. Hadi integrated this into control flows, demonstrating reduced branching logic.

Smart casts automatically handle type checks, minimizing explicit casts. In his application, this streamlined interactions with mixed-type collections.

Interoperability and Platform Targets

A core strength, as Hadi pointed out, is Kotlin’s full compatibility with Java. Code can call Java libraries directly, and vice versa, facilitating gradual adoption. He compiled mixed projects, showing no performance overhead.

Targeting JavaScript, Kotlin compiles to efficient code for web fronts, sharing logic between server and client. Hadi previewed this, noting potential for unified development stacks.

He addressed modules and versioning, still in progress, but promising better organization than Java packages.

Functional and Advanced Constructs

Hadi introduced traits, similar to interfaces but with implementations, enabling mixin-like behavior. He used them to compose behaviors in his app.

Delegated properties handled lazy initialization and observables, useful for UI bindings or caching.

Coroutines, though nascent, hinted at simplified asynchronous programming.

In Q&A, Hadi clarified comparisons to Ceylon and Scala, noting Kotlin’s balance of comprehensibility and power. He discussed potential .NET targeting, driven by demand.

Real-World Application Demo

Throughout, Hadi built a sample app, testing features in context. He covered error handling, collections, and concurrency, proving Kotlin’s robustness.

He encouraged trying Kotlin via IntelliJ’s community edition, which supports it natively.

Hadi’s presentation positioned Kotlin as a promising contender, fixing expensive language flaws while maintaining industrial applicability.

Links:

• Hadi Hariri on LinkedIn
• JetBrains website

Case

I have to work on an “old-school” project: without Maven (and even without integration within Eclipse). The JARs depended on by the application are located in a lib/ folder. Besides, I cannot add JARs to company repository.
How to integrate Maven with this lib/ folder?

Solution

First of all, you have to enable the support of Maven within IntelliJ IDEA: select the project > right click > add framework support > select Maven.

Create a pom.xml and complete the main information.
Identify the JARs which are relatively common (eg those available in http://repo1.maven.org/maven2/), and add them as dependencies.

Now, you still have to deal with “uncommon” JARs

Quick and (very) dirty

The quickest way is to add the JARs as dependencies, declared with scope system, eg:
[xml]<dependency>
<groupId>unknownGroupId</groupId>
<artifactId>someArtifactId</artifactId>
<version>someVersion</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/foo.jar</systemPath>
</dependency>[/xml]

The main drawback of this dirty solution is that when you generate your archive, the JARs depended on with scope system will not be exported… Quiet a limitation, isn’t it?

(A bit) Slower and (far) cleaner

You have to declare a “remote repository”, of which URL is local, such as:
[xml]<repository>
<id>pseudoRemoteRepo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<url>file://${project.basedir}/lib</url>
</repository>[/xml]

Then, declare the dependencies like:
[xml]<dependency>
<groupId>UNKNOWN</groupId>
<artifactId>foo</artifactId>
<version>UNKNOWN</version>
</dependency>[/xml]
Move and/or rename the JARs, for instance from lib/foo.jar folder to the actual one, such as lib/UNKNOWN/foo/foo-UNKNOWN.jar.

Now it should be OK ;-).
In my case I prefered to add Maven Assembly plugin with the goal jar-with-dependencies, to be sure to build a unique JAR with complete exploded dependencies.

package “nagios-nrpe-server”
“`

He demonstrates real-time dashboards that correlate application metrics with infrastructure health, enabling rapid incident response and informed scaling decisions.

Economic and Organizational Impact: Beyond Technical Excellence

Bertrand Paquet concludes with a quantitative analysis of the pipeline’s impact: deployment frequency increased from weekly to multiple times daily, mean time to recovery decreased from hours to minutes, and infrastructure costs became predictable and scalable. He argues that these technical achievements enable organizational agility—new features can be tested in production with real users within hours of conception, creating tight feedback loops that drive product excellence.

Links:

• Video URL
• Octo Technology Website

end
end
“`

Roux advocates testing pricing models through A/B experiments on payment pages, measuring conversion rates across different tiers. He discusses freemium approaches where core functionality remains free while premium features drive revenue, using analytics to identify which capabilities users value sufficiently to pay for.

Cultural Implications: Democratizing Innovation Through Methodological Discipline

Camille Roux concludes with a broader reflection on how these practices fundamentally democratize technological innovation. By reducing the barrier to entry from months of development to days of validation and prototyping, the methodology empowers a wider spectrum of creators—solo developers, domain experts without coding expertise, and intrapreneurs within large organizations—to test ideas systematically. He argues that this shift represents not merely a technical evolution but a cultural transformation, where failure becomes inexpensive learning rather than career-ending catastrophe, and where success emerges from disciplined experimentation rather than visionary genius.

Links:

• Video URL
• Human Coders Website

In an engaging session, Dick Wall and Bill Venners, co-founders of Escalate Software and prominent figures in the Scala community, introduced newcomers to the Scala programming language. Dick, known for his JavaPosse involvement, and Bill, president of Artima and author of key Java texts, adapted their training curriculum to cover foundational elements. Their approach fused object-oriented and functional paradigms, emphasizing Scala’s blend of familiarity and innovation.

They commenced with the Scala REPL, a tool they use daily for experimentation. This interactive shell allows immediate code execution, inferring types and storing results for reuse, making it invaluable even for Java developers exploring libraries.

Dick and Holly—wait, Dick and Bill—highlighted Scala’s strong typing with inference, reducing boilerplate while maintaining safety. They demonstrated basic operations, showing how everything integrates into a unified hierarchy, unlike Java’s primitives and references.

Defining Variables and Immutability

Transitioning to variables, Dick and Bill distinguished between vals (immutable) and vars (mutable), promoting vals for reliability. This design choice encourages constant use without extra syntax, contrasting Java’s final keyword. They illustrated reassignment errors, noting REPL’s scoping allows redefinitions, mimicking nested blocks.

Type specifications, optional due to inference, follow names with colons, inverting Java’s order for natural flow. Examples showed string inferences and explicit declarations, underscoring flexibility.

They addressed mutability choices, advising private volatile vars for necessary changes, or mutable objects within immutable structures, depending on context.

Control Structures and Expressions

Dick and Bill explored control structures, revealing Scala’s expression-oriented nature. If statements return values, enabling concise assignments without ternaries. While loops, though imperative, yield Unit, encouraging functional alternatives.

For comprehensions, powerful for iteration, support guards and yields, transforming collections declaratively. They demonstrated filtering even numbers or yielding transformed lists, highlighting pattern matching integration.

Try-catch blocks, also expressions, handle exceptions functionally, with finally clauses for cleanup. This uniformity simplifies code, treating controls as value producers.

Functions and Closures

Delving into functions, they defined them as objects, enabling higher-order usage. Simple defs showed parameter typing and inference, with return types often omitted.

Function literals, akin to lambdas, capture environments as closures, allowing deferred execution. Examples illustrated anonymous functions for mapping or filtering, emphasizing Scala’s functional leanings.

They introduced by-name parameters for lazy evaluation, useful in custom controls like loops, mimicking built-in syntax without special privileges.

Collections and Functional Programming

Scala collections, immutable by default, support transformations via methods like map and filter. Dick and Bill showcased creating lists, accessing elements, and applying operations, yielding new collections without mutation.

They contrasted mutable variants, advising caution for concurrency. For comprehensions over collections generate new ones, combining iteration with functional purity.

Approaching functional style, they encouraged avoiding side effects, using recursion or folds for aggregations, fostering predictable code.

Advanced Basics and Q&A Insights

In Q&A, they addressed optimizations: Scala uses primitives internally, with @specialized for generics avoiding boxing. Profiling mirrors Java tools, with quirks in coverage.

Dick and Bill wrapped by previewing afternoon labs on Scala Koans, urging practice. Their session laid a solid groundwork, blending theory with practical demos, preparing attendees for Scala’s expressive power.

Links:

• Dick Wall on LinkedIn
• Bill Venners on LinkedIn
• Artima website

Lecturer

Pierre Pezziardi has built a career as an entrepreneur and innovator in technology and finance, co-founding OCTO Technology and the Université du SI, as well as launching Octopus Microfinance and NotreBanque. His work promotes “convivial informatics”—systems that break down organizational silos, empower individuals, and support self-organizing teams. In 2005, Pierre initiated Octopus, an open-source platform for microfinance that fosters global collaboration on lean and agile methods to improve financial access for the underprivileged. He contributed to BabyLoan, France’s first peer-to-peer microcredit operator. From 2010, as CIO at Bred Banque Populaire, he applied lean techniques to banking. Since 2011, Pierre has led NotreBanque, developing affordable, transparent community financial tools.

Abstract

Pierre Pezziardi probes the role of developers in contemporary enterprises, questioning whether the profession garners the respect it deserves amid perceptions of high costs and limited value. He traces the historical evolution from artisanal coding to industrialized processes, critiquing how this shift has diminished developer autonomy and innovation. Through analogies to manufacturing and personal anecdotes, Pezziardi advocates for lean principles, self-organization, and cultural shifts to restore pride in development. The presentation analyzes systemic issues like productivity stagnation and organizational silos, proposing methodologies that empower developers as key innovators in business success.

The Developer’s Image: Perceptions and Realities in Enterprise

Pierre Pezziardi opens by addressing the awkwardness developers often feel when describing their profession, noting the common reaction of polite disinterest or skepticism from non-technical interlocutors. He posits that this stems from informatics’ reputation as expensive, delayed, and often unhelpful in real business contexts. Pezziardi argues this image is not unfounded, rooted in double exhaustion: declining productivity in large systems and outdated organizational models ill-suited to modern technology.

He explains productivity stagnation: marginal costs for new features rise due to legacy complexity, while organizational exhaustion manifests in siloed structures that hinder collaboration. Pezziardi draws historical parallels to the industrial revolution, where artisanal crafts gave way to assembly lines, similarly in software where developers became cogs in bureaucratic machines.

Pezziardi’s methodology involves reflective questioning: why do developers hesitate to claim their role? He suggests it’s because enterprises view informatics as a cost center rather than a value creator, leading to undervaluation.

Historical Evolution: From Artisanal to Industrialized Development

Pezziardi traces software’s trajectory from the 1960s, when programmers crafted bespoke solutions on punch cards, to today’s industrialized processes. He critiques the “software factory” model, where specialization fragments work—analysts specify, coders implement, testers verify—mirroring Taylorist principles.

This fragmentation, Pezziardi analyzes, breeds inefficiency: specifications become outdated, leading to rework and delays. He contrasts this with lean manufacturing’s origins in Toyota, where empowered workers halt lines to fix issues, fostering continuous improvement.

Pezziardi’s personal anecdote from banking illustrates: implementing lean reduced delivery times from months to weeks by involving developers in business decisions, eliminating wasteful handoffs.

Implications: traditional models stifle innovation; lean empowers developers as problem-solvers, aligning with agile’s emphasis on cross-functional teams.

Lean Principles: Empowering Developers Through Autonomy and Collaboration

Pezziardi advocates lean as a remedy, rooted in eliminating waste (muda) and respecting people. He details principles like just-in-time production and jidoka (automation with human intelligence), translating to software as iterative development and automated testing.

He analyzes waste types: overproduction (unused features), waiting (delays in reviews), defects (bugs). Pezziardi proposes solutions: small batches, continuous integration, pair programming.

Pezziardi stresses cultural shifts: from hierarchical control to self-organization, where teams pull work and collaborate. He cites Octopus Microfinance as an example, where open-source contributions cultivate global knowledge sharing.

Methodologically, Pezziardi encourages daily practices: developers engaging marketers or accountants to understand needs, fostering empathy and efficiency.

Cultural and Organizational Shifts: Fostering Pride in Development

Pezziardi examines why developers feel undervalued: siloed roles limit impact, bureaucratic processes disconnect from users. He proposes redefining the developer as a cultivator of value, integrating business acumen with technical skill.

He analyzes geek culture’s potential: collaborative, innovative, yet often isolated. Pezziardi urges exemplifying values like humility, continuous learning, and cross-disciplinary dialogue.

Pezziardi’s narrative methodology—using humor, analogies (e.g., assembly lines)—engages to inspire change. Implications: enterprises adopting lean unlock productivity; developers gain fulfillment, transforming informatics from cost to asset.

Conclusion: Reclaiming Pride Through Convivial Informatics

Pezziardi concludes that technology outpaces culture; developers must lead by promoting convivial systems—tools empowering users, breaking silos. By embodying lean values, developers can reclaim pride, positioning themselves as pivotal to organizational success.

Links:

• Video URL
• OCTO Technology Website
• NotreBanque Initiative