Stuff Matters

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 materials and their properties. Most materials in the book are … Continue reading Stuff Matters

No More QA

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 were finished could you integrate them and test features end-to-end. … Continue reading No More QA

Autonomy and Microservices

Discussions about 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 is that autonomy is a good thing: teams can … Continue reading Autonomy and Microservices

Do You Need an Architect?

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, and plan activities. As a mentor, the architect provides the … Continue reading Do You Need an Architect?

Conceptual Integrity in Large Systems

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 design. It is better to have a system omit certain … Continue reading Conceptual Integrity in Large Systems

In Defense of Design Before Coding

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 the feature level, a bit of thinking before coding does … Continue reading In Defense of Design Before Coding

How Technology Evolves

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 than a true historic account, but it nevertheless left an … Continue reading How Technology Evolves

Platforms and Innovation

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 the kind of applications I was developing, what these middleware … Continue reading Platforms and Innovation

10 Tips to Fail with Enterprise Integration

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 contexts instead of defining one abstraction per context. Or you … Continue reading 10 Tips to Fail with Enterprise Integration