In a way ideas only count for a little in computing, because you kind of have to implement this stuff. This is the part of the story that really makes me clutch at my throat, because every time you implement something, 5 years go away.
March 18, 2010
The Most Depressing Thing I Heard in 2008
June 15, 2009
Ignoring Just One Deprecated Warning
Switching projects over to iPhone OS 3.0 means discovering that functions I’m using are deprecated. Occasionally there isn’t a totally straightforward replacement, and the best thing to do is to file a bug/TODO/note for myself, and ignore the warning until a later version, when major refactoring will be possible. But bitter experience has taught me to have Xcode treat warnings as errors1, so it’s necessary to trick the compiler into ignoring the warning for things to build.
-Wno-deprecated
The -Wno-deprecated flag tells GCC to suppress warnings about deprecated code. But adding it to an Xcode project means you won’t get useful warnings about other depreciated code.
You could file a bug telling yourself to turn that warning back on after the deprecated functionality has been updated. That should work just fine. But it feels like bad project hygiene to me.
Casting and Protocols
Type casting is a dangerous old-C technique that’s earned its infamy. But it’s undeniably fitting to use a deprecated language feature to get deprecated code to build. The basic idea is to declare a protocol that includes the method you want to suppress warnings for,
@protocol DeprecatedHack - (void) myDeprecatedMethod; @end
then just cast your objects so the compiler thinks they implement the protocol,
[foo myDeprecatedMethod]; //warnings [(id<DeprecatedHack>>)foo myDeprecatedMethod]; //no warnings
Although having to declare a protocol is somewhat heavyweight, it leaves a nice artifact in the code reminding you to replace deprecated functionality.
Protocols Not Required
Sometimes just casting to id is enough. This happens if another object has a non-deprecated method with the same name.
1For experimental or prototyping projects I let warnings slide. But in the main project I always treat warnings as errors. Ignoring them in production code has never worked — warnings fester and grow on each other.
Because Objective-C is so dynamic, there are many errors that the compiler can warn you about, but can’t be totally sure are errors. For example, methods can be added to a class at runtime, so if you call -someMethodThatDoesNotExistAnywhere, the compiler will warn you that something is up, but won’t stop the build, because the necessary code could magically appear at runtime. Of course, 99% of the time, it’s me accidentally using count when I meant length, etc. What I’m really trying to say here is that treating warnings as errors is an even better idea in Objective-C.
September 6, 2008
The Term “Sprint” is Very Wrong for Software Projects
My employer is big on Scrum-flavored Agile Software Development. This is not a critique of “Agile” practices (if you want one Steve Yegge won’t let you down). I just don’t have enough experience organizing software projects to judge if this whole “Agile” thing is working well or not. But I do think the choice of the word “Sprint” to denote a unit of work is harmful.
A sprint is unsustainable. Fully recovering from a true-sprint takes a long time. To be ready to sprint again, you must rest for far longer then the sprint lasted. And you’re pretty useless (at least running-wise) while you rest. These are simple things that we learned as kids on the playground. This is what “sprint” means to people.
Calling repeated multi-week units of sustainable and quality work a “sprint” makes no sense whatsoever. Worse, it subtly encourages over-exertion and behaviors that are detrimental to a project.
It might be argued that in the context of Scrummy-Agileness, “Sprint” is a technical term, divorced from the common parlance. Whatever. Words don’t change meaning overnight, and they are almost never their own antonyms. Word-choice is known to influence people.
Sure, word-choice alone isn’t enough to derail a project, or sink a methodology. That’s why this isn’t a criticism of “Scrum”, which will ultimately stand or fall for other reasons. But there are plenty of much better terms to describe a chunk of work, that will help long-term productivity. Wouldn’t you rather work for a company that evaluated how effective a “Play” was?