Making Usage Patterns Explicit in Code
In nearly every OO application there’s at least one large class. By large, I mean a class that has 15 or more methods. We expect classes to have focus and it’s hard to make the case that a class with that many methods is about one thing. There will be some sort of grouping. Sometimes it’s explicit in the names of the methods, sometimes it’s . . .
Using Static Call Counts to Explore Internal Structure
In an ideal world we’d be able to see more in our editors and IDEs. We see our code, and that’s just about enough to work but there’s so much more that we can know.
One of the things I’d like to know is the number of call sites that each method has. In frameworks or libraries, we’ll have methods that are never called . . .
How Social Media Architecture Affects Group Cohesion and Behavior
Before I started programming I majored in architecture. I have a strong visual imagination and as a teen buildings just “popped” into my head without me putting them there. As a career, it seemed like a natural fit but unfortunately I never really learned how to draw well enough so I moved on to engineering and computer science. . . .
I’ve been hearing people talk a lot more about Technical Debt recently. I’m glad. Anything we can do to pay more attention to long term quality is good. Technical Debt is a valuable frame for those discussions. No one wants to be in an impossible situation and teams that keep accumulating Technical Debt often end up there. It’s a land of . . .
A while back I wrote about what it takes to kill code. I won’t take up any time repeating why it’s a good idea to get rid of code that’s dead or low value. I think that anyone who’s spent time trying to understand or change some area of code only to find out that it’s never really used knows how frustrating it can be.
As often as . . .
Everyone involved in software development seems to know what Technical Debt is. It’s a powerful metaphor. In Ward Cunningham’s original formulation, Technical Debt was the accumulated distance between your understanding of the domain and the understanding that the system reflects. We all start out with some understanding of a problem, and we . . .
The debate between proponents of static and dynamic typing never seems to die down, but it has matured. Most people I encounter seem to be ready to accede that people can do good work in a dynamically typed language. On the other side, it’s becoming more and more apparent that as type systems grow, the number of error classes we can eradicate . . .