tayb.in

Software Engineering and Everything Else

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 scenerio. 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 truely believe the team will come out ahead, although the sweetspot 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.

Require.js and HAML

I’ve been having very good luck with requirehaml. I had been looking around at various templates, but none of them seemed to support compiling before delivery to the client. This script does that and compiles them into easily verifiable javascript files, packaged up to be included with my existing require.js AMD build.

So far, I haven’t actually had that much HTML to include, but hopefully that will change as my project takes shape and grows.

Now I just need to find something to do the same for SASS.

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.

How to Setup a Pretty Good Dev Environment on the Mac

(This was a quick write up for a coworker, but others might find it useful)

This assumes you have XCode. I mean, really now.

First thing to do is install mac homebrew. It’s a package manager of useful open source software. You install it by pasting into the terminal:

1
/usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

then just to make sure it’s working, run:

1
brew install -v git

Next we want to install the node package manager.

It’s a simple

1
curl http://npmjs.org/install.sh | sh

Lastly, I like to setup rvm, for managing multiple ruby installations and keeping my base machine clean of stray gems.

1
bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

RVM is a little more complicated since you also have to add a little something to your shell file so that the paths are loaded correctly

1
echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"

That’s about it. I’m still looking into how to setup the RVM equivalent for python, but it seems that community is still figuring out their tools and a clear solution hasn’t emerged yet.

The Stillness Before the Storm

It’s ten hours before the doctor induces my wife into labor. It’s only 9pm, but I’m bored and want to start a project. I also know that I shouldn’t since the next week will be very busy.

So I sit here and wait.

Now With Penguin Sounds

I used to have another blog at Penguin Sounds. I had this idea that I would put personal posts on taybin.com, and programming/professional posts at penguinsounds.org. But in the end it just split the effort on both blogs and confused friends and family.

So I’ve now imported the rest of the penguinsounds archives to this site and redirected the URL. The only downside is that I had one post with over a hundred comments from a couple years ago from when iMovie ‘08 was released to mass-disapproval.

New Books!

I bought a couple books today. I picked up Managing Humans and Real World Haskell.

Managing Humans really needed a better editor. Maybe I’m not in the manager mindframe enough to understand it, but it jerked around and contradicted itself.

I’m hoping the Haskell book isn’t as disappointing. I’ve been wanting to understand functional programming for a long time, but never got around to picking up a book that explained how to model real programs that rely on input from the outside world.

What the Hell, Autoconf?

There’s a new autoconf out, autoconf-2.63.  It continues autoconf’s fine tradition of having the suckiest release schedule and quality of the GNU toolkit.  You would think that they would increment the major number whenever they release a non-backwards compatible release, but they don’t for shear preversity.  I guess 2.63 just rolls off the tongue, and I can’t blame them.  The ridiculousness of having to test for different versions of your platform configuration tool boggles me.  I’m at a loss for words at how much the autoconf maintainers have failed their core mission.

I’m not even going to go into their choice of m4 as the file format.  That probably made sense at the time. But that the thing is implemented in sh is just stupid.  

Really, what the autoconf maintainers should do is what the make maintainers never had the guts to do.  Realize that their software is making the world a worse place, pick a worthy successor, and never update their project again.  In my perfect world, autoconf is allowed to commit hari-kari.  Meanwhile, automake is lined up against a wall and shot at dawn.

On the plus side, this might be the chance for everyone to finally move to a sane build tool like waf or cmake.