When the architecture of a system starts to show its limits, it’s tempting to throw everything away and start from scratch. But a rewrite has challenges too. The existing software is a value-generating asset and must be maintained. The new architecture is unproven and comes with risks. Reaching feature parity can take years, and the rewrite turns also into an integration challenge to inteface the … Continue reading To rewrite, or not to rewrite?
People working on a product or system might have different interests and motivations. For someone, it might be shipping as quickly as possible. For another, it might be keeping operations stable. For a third, it might be ensuring adherence to some standard or policy. There are many forces at play, potentially in conflict. These different incentives inevitably lead to friction at work, since the value … Continue reading Friction
The goal of pretty much any framework/plattform that you use — from a PaaS offering to application server and everything in between — is to make you more productive by taking care of some technical complexity for you: “Focus on the business logic, not the technology”. Frameworks and platforms speed up development so that you can ship faster. And it’s true that you can ship … Continue reading Developers Like Technology, not Business Logic
Marc Hoffmann and I were invited to the 43th Berner Architekten Treffen (BATBern) on “Event-Driven Architectures”. We presented the architecture of the Rail Control System, especially the mechanisms for high-availability. Here are the slides: Continue reading BATBern43
Sometimes, I read an article, and some idea deeply resonates with me and makes a long lasting impression. It changes the way I approach some topic. Fred Brooks’ essay “no silver bullet” was one of the very first article I read that had this effect. The concepts of esssential and accidental complexity are very powerfull, deeply resonate with me, and shaped the way I see … Continue reading Great Articles on Software Engineering
A main responsibility of management is to make sure that teams function well. This implies defining adequate organisational structures and finding adequate people. The Boss Team Sometimes, the structure is easy. There’s a boss and there are employees. The boss decides how the team should function, what should be done, who should do it, and is finally the one evaluating the employees according to his/her … Continue reading Team Structures
If you try to think about the last talk that you gave to a large audience, you might recall feeling a bit anxious standing in front of the audience. You might remember people looking at you and how the room looked like. This memory feels complete. Yet, you don’t recall the actual faces of the people in the room, or the details of the room, … Continue reading Adventures in Memory
The key message of “Drive“, from Daniel H. Pink, is that people are best engaged in a task when they understand the purpose of the job, they can develop the necessary mastery to realise the job, and they have sufficient autonomy to direct things their way. That’s a very simple framework — purpose, mastery, autonomy — and I very much like it. The problem with … Continue reading Drive
Things move fast in the IT industry. Half of the technologies I use today didn’t exist ten years ago. There’s a constant push to switch to new technologies. But when it comes to technologies, I’m kind of conservative. I like proven technologies. The thing that makes me conservative is that mastering a technology takes a lot longer that we think. Most advocates of new technologies … Continue reading Mastering New Technologies Takes Time
This book is about agile management as a way to conduct business — not just software development. In the first chapters, the author presents agile management by characterizing it with three “laws”: the law of the customer, the law of the small teams, and the law of the network. Roughly, I would sum them up as: companies should put creating value to customer at the … Continue reading The Age of Agile
