Monthly Archives: June 2010

Interesting Things

Jasmine bundled with RubyRacerJasmine is now optionally bundled with the RubyRacer gem. This lets you run Jasmine tests through Google’s V8 engine in a browser-less environment. Similarly, some Pivots paired Jasmine with Johnson and env.js to produce JazzMoney. Right now, JazzMoney is the only headless testing tool for Ruby that has DOM support, but I’m sure RubyRacer has that in mind. You can find JazzMoney here.

Interesting Things

RubyMine IntegrationRubyMine is integrating with Pivotal Tracker! Beta version 2.5 lets you follow stories through the IDE’s task tool and tags your source control comments with the current tasks. It’s nice to see the title of your current story as you work. I’m excited to see what deeper integrations lie ahead. This screenshot shows what it looks like selecting a story through the menu item Tools > Task > Open…

Preview Woes

In the the process of pulling assets out of a PDF we’ve noticed Preview crashes opening files larger than 45MB. Adobe Reader opens the same files without problems. Has anyone else had problems with Preview?

I ran into that issue and used the PDF optimizer in Acrobat to pull-out unnecessary markup and compress the images. That seemed to take care of the issue for Preview.

When starting any software project, there’s an age old argument: should we build something simple that solves our current problem or should we use an existing product that’s more complex, but more feature rich, since we know that’s where we’re going to end up in the future?

…

an oft neglected repercussion of building too much too quickly is that the extra functionality can calcify your product and make it very rigid. Releases become more complex, new features take longer to implement and bugs take longer to fix. You can find yourself a prisoner of your product, maintaining functionality and features that no one ( or very few ) people use. It can demoralize a engineering team, making them more and more susceptible to the nuclear option: the big rewrite.

I think the tendency to lean towards a more exhaustive solution upfront comes from a time when the effort require to change software was much higher than it is today. When systems were written in C, C++, Perl or even Java, making changes was a large undertaking. The thought of possibly throwing away chunks of code was nerve racking. It represented a huge investment in time and money. However, with todays rapid development languages and frameworks like Ruby/Rails & Python/Django, the investment required to create something, both in time and money, is rapidly shrinking.

“The Ruby community cares about building high-quality apps, but doesn’t necessarily care about shipping high-value apps.”

Jeff went on to say that the Ruby community is obsessive about craftsmanship. This is a good thing, of course. We test. We write clean code. We take the time and care to build applications that are beautiful and do what our customers ask for.

Therein lies the rub: what customers ask for is rarely what they want, and almost never what they need. As Henry Ford put it, “If I had asked what people wanted, they would have said faster horses.” Or as I put it, your customer may pay you $1000 to deliver him a knuckle sandwich, but no amount of precision or strength training is going to leave you with a happy customer.

It turns out that constructing a high-quality application is not enough – you have to conceptualize and design an application that users will actually find useful. Doing this is every bit as difficult as constructing the software, if not harder. It requires a combination of research – generating new ideas from asking questions & identifying problems – and feedback – testing out ideas you’ve created. The Ruby & Agile worlds have been primarily focused on getting user feedback, without doing the all-important research.

Weeks ago, some people in the Ubuntu community got a bit disappointed with the distribution’s core team:

We are supposed to be a community, we all use Ubuntu and contribute
to it, and we deserve some respect regarding these kind of decisions.
We all make Ubuntu together, or is it a big lie?

We all make Ubuntu, but we do not all make all of it. In other words, we delegate well. We have a kernel team, and they make kernel decisions. You don’t get to make kernel decisions unless you’re in that kernel team. You can file bugs and comment, and engage, but you don’t get to second-guess their decisions. We have a security team. They get to make decisions about security. You don’t get to see a lot of what they see unless you’re on that team. We have processes to help make sure we’re doing a good job of delegation, but being an open community is not the same as saying everybody has a say in everything.

From my experience having velocity as a goal doesn’t make any difference to the motivation of the team which is often cited as the reason for referring to it as a target.
In all the teams I’ve worked on people are giving their best effort anyway so they can only really have an impact on the velocity by doing one of the following:

Working longer hours

Cutting corners on quality (by less testing perhaps)

Finding a smarter way of working

…
In reality I haven’t noticed that people on the teams I’ve worked on pay that much attention to whether velocity is considered a target or not. People just do their job and we pretty much always have the same velocity each week regardless.