Category Archives: Best Practices

Agile and Hyperproductivity

I was wondering around my office, which is housed in a co-working location, when I saw on a whiteboard in another company’s office, “Agile: Hyperproductive!” As an engineer type, I had to restrain myself from going in and telling them they were wrong, but I do have some thoughts on the subject.

I like Scrum. I think in the future for most teams, Scrum and similar processes won’t be controversial. They’ll just be how software engineers do things. That said, it’s not going to make you more productive. Its sprints have a higher overhead with daily standups, retrospectives, planning, and grooming meetings. The smaller the sprint, the higher the overhead is.

I’ve seen claims that Scrum will increase productivity by 800! That is incredible. And unbelievable. Are people typing faster? Are they designing faster? My speed of implementing is the same whether for waterfall or Scrum.

With the additional overhead of more meetings, you’re arguably *less* productive compared to an ideal waterfall scenario. But that’s okay, because a development cycle that doesn’t run into issues is a myth. Either a design flaw was found, or the business requirements changed, or some key player leaves. Something will happen, and Scrum’s smaller cycles deals with that better than a waterfall process.

I truly believe the team will come out ahead, although the sweet-spot of the best sprint length is different for all groups. I’ve worked with sprints from weekly to tri-weekly in size and it really depends on the culture of the project.

Just don’t say Scrum makes you more productive.

A nice, hype-free look at Scrum meetings.

AMD modules and web developers

Now that require.js has reached 1.0, it’s probably time to start shouting its praises from every rooftop so that javascript library authors include support for it. Require.js is an implementation of the AMD draft specification which adds simple module support for javascript in the browser. This means no more namespace pollution (if you use it properly).

Unfortunately, we’re talking about web developers who don’t seem to understand basic principals like avoiding namespace pollution. I mean, how can you even have a conversation with someone with such a misconception of good practices?

Jeremy Ashkenas, the creator of CoffeeScript, Backbone, and Underscore also seems to have misconceptions about the purpose of AMD.

I was really hoping that someone with such a worthy track record would have seen the light by now. Luckily the require.js guy himself is pushing for AMD support in Underscore with a new pull request. Once that is pulled in, it looks like Backbone is next on the list.

Since the next version of jQuery will have AMD support, I imagine that the rest of the libraries will follow since they seem to look up to jQuery for best practices.

And then, one part of the nightmare that is working with javascript will be gone.

there but for the grace of god…

I’m so glad I’m not an Apple Release Engineer today. Four major releases today. iPhone 3G, iPhone Firmware 2.0, MobileMe, and iTunes 7.7.

It’s a huge task to synchronize all those releases and it eats up company resources like crazy. You have to have enough people to focus on each task separately.

MobileMe still isn’t working right. They’ve been extending the maintenance downtime further and further.

They have my sympathies.


You’ve read Refactoring. You’ve seen Prefactoring on the bookstore’s shelf. Well, after you’ve fact’d it all up, it’s time for Defactoring.

My new book, which introduces such techniques as overriding your framework’s core eventloop and running dynamic_cast<> on each widget that passes through to see if it’s the widget you’re looking for.

The Power of Binary Searching

I always knew that binary searching was fast, O(log2) and all that. But when you have to run it by hand over 3000 subversion revisions, looking for the place where you introduced a memory leak, and after four steps you’ve eliminated 93% of the search space, you get a new appreciation for it.

There are some tools out there for automating these searches through subversion. They didn’t fit our problem though because determining whether we were showing a memory leak was fuzzy.

Turned out to be 4 memory leaks. Two very minor ones, and two major ones in third party libraries, one of which only showed up on the Mac platform.

Thanks to binary searching, we could quickly identify the exact spots where these leaks were introduced.

Stop using deprecated dlopen() constructors

As I re-discovered for the third time last evening, LADSPA programmers still haven’t made the switch from _init() to __attribute__((constructor)) void init() {}.

The older mechanism has been deprecated since the early/mid ’90s. Most operating systems still supported it but with MacOSX 10.4, Apple dropped support when they implemented their own dlopen() support.

I’ve sent an email about it to the LAD mailing list, but apparently no one listened.