When a Method Can Do Nothing, Michael Feathers:
If polymorphism means anything at all, it means that the object is in charge. We send it a message and it is up to it to decide what to do. That’s core to OO and part of Alan Kay’s original view of objects – that they are all about messaging. That said, it is not the dominant view today.
The majority of this article is on working with/around conditionals using intention-revealing method names or null objects. Yet, this paragraph smacked me in the face with “oh, yeah, obviously!”. Lots of people view the moving parts in object-oriented languages as ways to group and share functionality. But to people who talk about OO a lot, read the history books, read the pattern books, know what SOLID is, etc. it’s an entirely different thing.
Here’s a sports metaphor: the Dallas Cowboys are a widely disliked sports team, for various reasons. If I was from anywhere but Dallas, it would be “not cool” to count myself one a fan. But being from Dallas, I have an entirely different view on the Cowboys and can safely watch their mostly mediocre performances with occasional memories of greatness, safe from scorn.
I find that holding that tension in my head is important when talking to sports fans. It’s the same with OO: you haven’t read the books, watched the presentations, or worked the exercises I have. We’re on different pages, but we need to talk about the same code and how to structure it. There’s a tension between my understanding of OO and the next person, but it’s not a barrier. We have to get our language straight before we can talk about language!
In short, we have to establish what city in OO-land we’re from before we can effectively talk about OO.
What future are we building, given that we play a role in such an important process?
On the role designers play, what they do as careers progress, and how design can positively enhance the world.
Reminder: if you tilt your head just so, developers do a lot of design activities too.
A channel, a sewer, Alabama, and a sunset walk into a bar:
What’s intriguing you, dear reader?
The best thing you’ll read about football today. Peyton Manning is what happens when a guy with the attention to detail of an accountant is also proficient at throwing a football and making snap decisions. Manning also looks like he could give you excellent tips on cutting your hedge or fixing that one toilet.
This is why Peyton is my favorite Manning.
Better Code Design through Pictures:
Looking at a picture like this reveals so much that is missing when only looking at Emacs or Vim. Classes that violate the Single Responsibility Principle may become obvious because they’re related to too many other classes. Cyclical dependencies might be identified. Even class names may be brought into question. These discoveries are not very obvious when writing code, but they were remarkably obvious once we threw the structure up on the whiteboard.
I almost always have some kind of notebook and pen by my side so that I can doodle words and shapes. Having a whiteboard nearby is even better.
This advice is going on a year old, but it’s still some of the best around. If you’ve got ungainly ActiveRecord objects that are doing way more than abstracting your data model, you are missing classes in the design of your application. Chances are, one of the objects Bryan describes here is what you might want to extract.
Facing risk by instrumenting the hell out of it:
Software development is a complex system existing as it does at the intersection of people, systems, good intentions, confused and changing goals, and overly literal state machines. Past behavior isn’t always an indication of future behavior, and humans are terrible at reasoning about complex systems. As such we’re unlikely to know or have good visibility into whether we’ve reached a steady state and our hypotheses are likely to be wrong. In this uncertain and complex environment we initiate change only when the cost of not making a change overcomes the fear of making it.
First in a series on how Etsy writes, deploys, and operates changing software without The Fear. Thanks for writing this stuff down, Kellan!
Problems, puzzles, startups as dynamic mazes:
just running to the entrance of (say) the “movies/music/filesharing/P2P” maze or the “photosharing” maze without any sense for the history of the industry, the players in the maze, the casualties of the past, and the technologies that are likely to move walls and change assumptions
I love this idea about thinking of solving systems as though they were an ever-changing maze, with history (fallen players) embedded within the system. Doubly so when you extend the metaphor to solutions that route around one problem to brazenly take on another problem. If this had a further extension to football playcalling, it would be perfect.
Practice Responsible Refactoring:
When cleaning up the code enables you to work faster for a task you aren’t dreaming up but actually have at hand, refactoring is the way to go.
Dave Copeland makes the point that refactoring without a value-added change (feature, improvement, bug fix, optimization, etc.) is a losing proposition. By the numbers, he’s absolutely right. Further, I’ve found that probably half of the refactorings I’m convinced are necessary aren’t as simple or useful as I thought once I get an hour into them. Despite all that, keep doing therapeutic refactorings for practice and to keep your spirits up.
Here’s a nice story on technology that isn’t startups: Unhappy truckers and other algorithmic problems. Logistic networks are a technology, just like smartphones. They make our world way better, but they do so invisibly and at a slower pace than the churn of mobile apps, web frameworks, and startups. But they’re still solving problems, moving the needle. They’re just, possibly, less obsessed with technology tribalism and fashion. Some days, that seems like a pretty useful space to find oneself in.