He was Serge's best friend first and his partner after that. It saves a lot of meetings. They disagree regularly, usually about how something should be set up, and never for long. What comes out is almost always better than what either would have come up with alone.
Aaron joins as soon as it is about architecture or a takeover. That is when he asks the awkward questions: what happens when this gets ten times bigger, who looks at this in three years, and what do you do when this supplier stops. Nobody is waiting for those questions in a first call, which is exactly why they need asking.
They have known each other long enough not to keep an argument about architecture polite. That is exactly the point. What comes out is almost always better than what either would have come up with alone, and it rarely takes more than an afternoon.
The question is not whether it works. The question is who still understands it in five years.
That is where his firmest opinion comes from: a rebuild is almost never the answer. Everyone looking at someone else's code for the first time wants to throw it away, and that is a feeling rather than an analysis. That old system holds ten years of exceptions nobody wrote down, and in a rebuild you discover every one of them again. Usually once the new system is already live.
Replacing it in pieces takes longer on paper and is cheaper in practice, because you are never six months without a working system. He wrote a piece about it that you will find on the blog.
What it costs: about an extra week at the start of a project. What it buys you: not having that rebuild conversation two years later.
What to call about
- The setup of a new platform, before any code gets written.
- Taking over someone else's code, including what that realistically costs.
- A code scan: what state the thing you have is in.
- A second opinion on a plan or on someone else's quote.
