Adam Wathan has a new post on his site about a different way of thinking he's coming around to about methods, affordances and abilities.

In one of my current projects, I needed to be able to broadcast email announcements to all of the users in the system. If you've read about enough patterns and principles, there's a decent chance you saw [the line allowing an Announcement to perform the "broadcast" operation] and immediately thought to yourself: "What?! An announcement shouldn't be able to broadcast itself!"

I used to think that too, but over the last few years I've started to think differently.

He talks about "do-er" classes that normally would take in something like an announcement and perform the operation to broadcast it. He suggests that this comes from a misunderstanding about the point of methods: abilities versus things you could do with an object. He goes on to give some examples of double standards with DateTime handling, the complexity it could introduce and how, despite it sounding like an immediate action, the "broadcast" method could just be deferring to a background queue anyway.

In a recent post to his blog Marco Tabini talks about what he calls the lost art of using your brain, the fact that people seem to be relying more on the contents of other peoples' brains instead of their own.

The world of technology is riddled with inhabitants who treat tools as if they were religions. OOP, unit tests, patterns... these are all instruments that are supposed to make some jobs better, and not theological formulas that will magically make every single line of code written on the face of the Earth better. And yet, the vast majority of people treats them like they are, sparking everything from language wars to endless—and pointless - discussions on whether a particular technique is better than another.

He goes on to say that the tools developers use every day aren't just limited to the technology that makes them up. They're there to make things easier, but if the developer using them doesn't take the time to engage their minds to use them correctly, they're practically useless (100% code coverage, for example). He shares his three reasons why he thinks this issue is so wide-spread and the steps he suggests to push out of this way of thinking and back into a more mindful, thinking sort of development path.

When it comes to code coverage and untested parts of your application (unit tested, of course), Zoe Slattery has a suggestion that could make your life easier anyway - follow the core PHP developer's example:

But - there is another way, and as usual the PHP core developers are showing us the way. The fastest way to improve percentage of code covered is to REMOVE UNTESTED CODE! Accordingly we saw the test coverage of PHP 5.3 increase from about 55% to a little over 70% over the summer of 2008. At the same time the lines of code in PHP dropped by about 50KLOC. How can this be?

Removing untested code (that's not needed anyway) can reduce unit testing times dramatically and can help you keep your code clean, lean and simple for the upgrades that will come later on.