Decide everything as late as possible, but not later.
Companies have traditionally organized software engineering 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
To check if a salesman is good, one classic is the "Sell me this pen" test. To check if a software designer is good, I propose the "Design me a calendar app" test. That was one of the topic we chose for the software engineering lab, and I loved the results. There are several reasons … Continue reading Why a Calendar App is a Great Design Exercise
The world is constantly changing. From electricity to cars to television to the internet, most generations have seen at least one breakthrough. This will continue, and it's certain that my generation will witness another technological shift. Interestingly, how we react to new technologies changes itself with time. For a lot of new technologies, my first … Continue reading Living in the Future
