Decide everything as late as possible, but not later.
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 … Continue reading The Age of Agile
Stuff Matters is a very nice little book about the materials that surround us. Organized in ten chapter, each tracing the history of a class of material (metal, paper, glass, plastics, chocolate, gels, graphene, concrete, ceramics, biomaterial), we get to better appreciate how much tinkering and research took place over centuries to discover all these … Continue reading Stuff Matters
Companies have traditionally organized software-related activites in three silos: Dev, Test/QA, Operations. The QA effort is realized after a long phase of development resulting in bug spikes and difficulties to plan the work for the development teams during this time. When companies were engineering software "piecewise" this was the only way. Only when all pieces … Continue reading No More QA
Discussions monolith vs microservice are hotter than ever. Usually, a monolith is synonym for “big ball of mud” in these discussions. It of course needn’t be so. A modular monolith is perfectly possible. Also, microservices isn’t an entirely new idea either. As some says, it’s SOA done right. The usual argument in favor of microservices … Continue reading Autonomy and Microservices
Architects do typically three things: they own, they coordinate, and they mentor. As an owner, the architect maintains the integrity of the system at a high level. He designs the foundations, identifies tradeoffs, decides on essential changes. As a coordinator, the architect facilitates work and optimizes the exchange of information. He connects people, gather information, … Continue reading Do You Need an Architect?
The central argument of the Mythical Man Month from Fred Brooks is that conceptual integrity is the most important consideration in system design, and that conceptual integrity will only be achieved if the design comes from one, or a few resonant minds. I will contend that conceptual integrity is the most important consideration in system … Continue reading Conceptual Integrity in Large Systems
Software design as a separate activity from implementation -- "up front" design -- got a bad press with agile methods. Agile advocates say the design should be emergent. They say, design without coding is waterfall. It's a waste of time. I understand that you don't want to design the whole system up front. But at … Continue reading In Defense of Design Before Coding
We often take for granted the technology we have and forget that it's the result of a tedious evolutionary process. A Railroad Track is the Width of Two Horses is one of the first stories about the evolution of technology that I remember reading, maybe ten years ago. It rings more like a colorful story … Continue reading How Technology Evolves
I started my career writing flash applications. Then I moved to Java. Both are middleware technologies that abstract the underlying operating system and enable cross-platform interoperability. I've actually never wrote a professional application that relied directly on a specific operating system. This was fine to me. "Write once, run everywhere" was great for productivity. For … Continue reading Platforms and Innovation
If you want to make enterprise integration needlessly complicated, follow these tips. 1. Model poorly A poor model is always a nice way to make things more complicated than they should. Examples: You can name thing badly. You can model everyting as strings (key, list, etc.). Or you can reuse overly generic abstractions in multiple … Continue reading 10 Tips to Fail with Enterprise Integration
