I’ve been thinking about cohesion, coupling, and the Single Responsibility Principle quite a bit recently. The other day I realized that cohesion is harder to explain or understand than coupling. I figured I’d put that thought out into the world via twitter (not realizing that Glenn Vanderburg had said essentially the same thing about four . . .
Over the past 30 years, the internet has transformed the world in immeasurable ways. As internet use spread from universities to the mainstream, millions of people were able to access and contribute knowledge, build businesses and connect with the world - at first with simple dialup modems over phone lines and later with more advanced . . .
At QCon New York last month I hosted a panel on architecture and nearly all of the questions were about microservices. It isn’t hard to sense the excitement many are feeling about this approach. When I first heard about microservices, the people talking about them framed them as a reaction to monolithic architecture, frameworks, and SOA. It . . .
One of the things that we don’t appreciate enough in software development is the way that ideas echo across the industry. I remember seeing Rich Hickey and Stu Halloway presenting Datomic and feeling palpable echoes of git’s repository model. A similar thing happened to me a while ago with microservices - I got the sense that they were an . . .
One of the clear benefits of functional programming is composability. It’s easy to take fundamental operations like maps, filters, and folds, and build up computations that are both powerful and concise. But sometimes concision can come at the expense of readability.
This Ruby code creates a data structure that is used to generate . . .
Recently, I’ve been using algorithmic complexity as a metaphor for change complexity.
Usually, when people talk about complexity in code, they are talking about cyclomatic complexity in classes and methods, but the fact of the matter is that there are other forms of complexity that are worth noting - particularly the complexity of . . .
People don't refactor nearly enough in most projects. It’s easy to find large classes and methods, inscrutable logic and poor naming in most code bases. When we have that sort of situation it’s easy to just look the code and say “that needs refactoring.” The implication is that we should fix problems when we see them - if we can identify . . .