When scientists and engineers explain their esoteric disciplines to the general public, they reach for analogies. Sometimes those analogies are apt and serve to clarify what is hard to understand, sometimes they are less apt and serve to obfuscate and confuse. We certainly use our fair share of analogies in software development — construction, manufacturing, brain surgery — and some of them, especially the one to construction, have been very harmful.
So when I saw the article in the NYT this past week on pair programming, I started counting the analogies.
A lot of pair programming chatter this week. Starting with a New York times article describing pair programming at Hashrocket. It’s an interesting article, with a tone that could be described as “anthropologist describing the strange, yet quaint customs of the native tribe”
Obie Fernandez followed up with a list of 10 reasons why pairing doesn’t work in most cases. It’s actually a list of the things that Hashrocket does to support pairing, although entries like “2. Most software developers just don’t want to work that hard” and “1. Most software shops don’t really care about excellence” do have a certain, “aren’t we great” vibe to them, causing Mike Gunderloy to dryly observe: “Funny, Extreme Programming Explained never said anything about fancy hw or being awesome as a prerequisite for pair programming.”
C’mon Mike — everybody knows that being awesome is a prerequisite for everything in XP.
Josh Susser adds that pair programming isn’t right for all projects, particularly projects that have long compile times that force the pair to stare blankly at the screen.
I’d also add this interview with Kent Beck because a) every programmer could use some more Kent Beck in their life and b) because he talks about XP as being concerned with the the social context of programmers, with pairing being a part of that.
Now you are caught up. Here’s the part where I talk.
A couple of days ago I happened upon an interesting article about the difference between art and design. The author makes a lot of interesting points, and whether you agree or not with the statements he makes, the article does make for a great conversation starter.
Art and design are two different words, and some say two different worlds as well. The use of each often comes with a distinct connotation. I could go on about how design’s goal is to solve a problem, whereas art doesn’t necessarily always have a problem to solve. I could talk about how art doesn’t necessarily require a common user experience, whereas design more often than not does. I could expand upon that by discussing how art doesn’t require that a thing be usable, whereas design is often judged in part or whole by its level of usability. I could even discuss how art can be effective whether done collaboratively or not, and contrast that with numerous examples of how here in our agile software development environment at Pathfinder we find collaboration inseparable from our design process.
But I could also talk about how much art and design overlap and blend, so much so that it becomes difficult to make concrete distinctions. And how, sure, software design is about solving a problem, but it’s also about solving a problem beautifully. (more…)
If you’re an ambitious new Rails developer in Chicago who wants to work along side Dr. Noel and our other sage Rails developers, check out our Rails Internship.
The problem: I needed to display a warning to a user if the data they were looking at was more than 90 days old.
The solution: Create a method that takes 2 dates (either DateTime or Time), and returns the number of days, or hours between them.
def self.difference_in_dates(date1, date2, unit = 1.day) return nil if date1.nil? || date2.nil? || unit == 0 (( date1.to_time - date2.to_time ) / unit).round.abs end
The problem was simple enough, and my tests were all passing, so I moved on to my next task.
That code has been out in production for several months, but earlier this week, a new developer told me he got an error when running the test:
NoMethodError: undefined method `to_f' for Mon, 21 Sep 2009 14:29:38 -0500:DateTime
(we’re running this in Rails 2.0.2)
I looked at the code, knowing it was working before, ran the unit tests myself, and didn’t see the issue. Now I’m on Windows and everyone else is on a mac, so as soon as I run into an issue that no one else has seen I want to prove if its a Windows problem. But wait, this test has been running in our Continuous Integration server (Hudson) for months, and no one else on the team ever had any issues with it, and the code has been working in production without any errors in the logs.
I jumped into rails script/console to see what’s up, and here’s what I found:
>> x = DateTime.now => Wed, 23 Sep 2009 00:00:00 +0000 >>; x.to_time => Wed Sep 23 00:00:00 UTC 2009 >> x.to_time.to_f => 1253664000.0
Which is what I expected, but when I asked the other developer to run that same instruction, he got an error.
>> DateTime.now.to_time.to_f NoMethodError: undefined method `to_f' for Mon, 21 Sep 2009 14:29:38 -0500:DateTime
What’s up with that? We’re running the same code, and all of our libraries are the same version. Looking at the date value in his error, I saw the timezone, and decided to try this variation locally:
>> x = DateTime.parse("2009-09-21T14:29:38-0500") => Mon, 21 Sep 2009 14:29:38 -0500 >> x.to_time.class =>; DateTime
So I’m gathering that when there is a timezone and you ask DateTime.to_time, its just going to give you back a DateTime.
I’ve worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That’s where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance — however that is defined — is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.
To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990’s money. The part of the system that resolved the transactions was really really “important,” but the part of the system that allowed an application helpdesk to support users by seeing what their user’s saw cost 60% more to develop. That’s right, an “unimportant” helpdesk module was more expensive and took more effort and cost more than the “important” backend that handled billions of dollars a day.
Please continue reading after the next sentence.
I installed Snow Leopard a couple of weeks ago.
Wait — don’t stop reading. This isn’t a post about how to install MySQL or a post about whether or not Snow Leopard is the Greatest Thing Ever. There are plenty of other places on the Internet where you can get that information.
I wanted to talk about two cool corners of the Ruby universe that I started using as a result of my Snow Leopard installation: MacRuby and RVM (more…)
At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.
We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.
We move onto user stories, all of which are written from the point of view of the personas: (more…)
The other day, I was trying to get the icon for a button in flex programmatically for a FlexUnit test. The code I was testing set the icon of a button using
setStyle('icon', ICON). I attempted the obvious
button.getStyle('icon') in the test, but was surprised that this always returned
A little bit of digging revealed that the I needed to go through the style declaration for the button. When changing my test to assert on
button.styleDeclaration.getStyle('icon'), I was able to successfully access the icon.
I found this a bit non-intuitive, but fortunately it only involved some investigation and minimal code changes.
If my previous post about the value of agile meetings over traditional status meetings got you interested, I want to share a common pattern of behavior I often see from teams trying scrums for the first time. Hopefully you can avoid these and save yourself some time.
For new teams to Agile the statuses given in scrums are generally … well … lies. “Yep, on time. No obstacles.” I was once told by a colleague that, “You can’t hide on an Agile team.” This is true. However, this kind of exposure can be extremely uncomfortable for individuals to get used to. In traditional software teams people aren’t used to their peers asking them direct questions and paying close attention to their progress.