Archive for December, 2007

Movie Management

Friday, December 28th, 2007

We’ve all seen movies where some protagonist hacker has a gun to his head, whether figuratively or literally. He is told by the antagonist that he has 30 seconds to “hack the mainframe” or “break into the CIA central computer” or whatever it is. He objects, but then manages to get in just before someone is shot. Those of us who work in technology know that this kind of thing is purely fiction. Take another example: think back to all those Star Trek episodes where the captain asks the engineer to do something. The engineer, possibly in a heavy Scottish accent tells the captain, “Aye, it’ll take me four hours.” The captain says something like, “you’ve got two.” Then, of course, the engineer gets it done in two, and just in the nick of time. Apparently people who write scripts in Hollywood are not very good at estimation! And we all know that this is not how things ACTUALLY work, right? Right?

I’m beginning to wonder if some people, particularly non-technical managers of technical folks aren’t really able to separate fact from fiction. Okay, here’s the facts of the matter:
1. Some things actually do take time! Some things can’t be done faster just because we WANT them to be done faster. This is particularly true of creative efforts. When we build software, there is a certain amount of the work that is creative in nature. No amount of desire can make certain work go faster. Take for example painting. If you need to paint a room, there’s not much creative work involved. And if you put 10 painters in the room, they can get the room covered in a fresh coat of paint faster than 1 painter could. But that is very rarely what software development is like. It is much more akin to a painter who is commissioned to paint a portrait. This is a very different kind of painting. Adding more painters to the task does not necessarily make it go faster. It might actually make it take longer and we’d all be suspicious of the quality of the outcome.
2. You can’t know how long something is going to take until you figure out WHAT it is that you have to do and HOW you are going to do it. And this in itself takes time. So the accurate estimate comes only AFTER a significant amount of work is done.
3. In the real world, our performance is not just measured by what we get done. We are often measured by the accuracy of our estimates. In this regard, the protagonists mentioned earlier would not do so well. And in reality, things usually take much longer than is estimated. They very rarely take less time.
4. Most technical people work better and faster when they are trusted and given some amount of latitude. The kind of movie-management where the hacker has a gun to his head is purely fiction. Most of us would not even be able to type three words if we had a gun to our heads. The idea that if pressure is applied, the effort will go faster is utter hog wash. It is no substitution for real motivation and real management.

These are the facts as I see them. And despite the overwhelming amount of literature that is out there to support these ideas, it is still an alarmingly frequent thing to run into the movie-management philosophy. I hear about it all the time and regularly run into it myself. It is a shame! As a whole, technology professionals could probably be much more productive if management didn’t take their cues from Hollywood.

Code Conventions

Friday, December 14th, 2007

According to Sun’s Java Code Conventions:

“80% of the lifetime cost of a piece of software goes to maintenance.
Hardly any software is maintained for its whole life by the original author.
Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.”

This is not new.  And yet, it seems to me, it is rare to find developers who actually write code with this in mind.  Where’s the disconnect?

Ruby on Rails Demos

Monday, December 10th, 2007

As I mentioned previously I have been learning Ruby. There are some pretty cool demos of Ruby on Rails here: http://weblog.rubyonrails.org/.

Models

Friday, December 7th, 2007

“[Models] are powerful tools for representing complex structures and relationships for the purpose of better understanding or visualizing them. … Good models emphasize the salient features of the structures or relationships they represent and de-emphasize the less significant details.”

– Alan Cooper & Robert Reimann, About Face 2.0

Optimize for Intermediates

Wednesday, December 5th, 2007

“A well balanced user interface … doesn’t cater to the beginner or to the expert, but rather devotes the bulk of its effort to satisfying the perpetual intermediate. At the same time, it avoids offending either of its smaller constituencies, recognizing that they are both vital.”

– Alan Cooper & Robert Reimann, About Face 2.0

Learning Ruby

Monday, December 3rd, 2007

I’ve been hearing a lot about Ruby. It seems to be pretty popular right now. And it has been a while since I’ve learned a new programming language, so I decided to see what Ruby is all about.

So far I am struck by a couple things. The first of which is how flexible the language is. There are often several ways to do the same thing. For example, here are two ways to print out the contents of an array:

arr = [ "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" ]

# Option 1
arr.each do |day|
puts day
end

# Option 2
arr.each { |day| puts day }

I like the way you can put the ‘if’ condition at the end of a statement:

print "They are equal.\n" if x == 7

And I like the fact that you don’t need to end a line with a semi-colon like in Java and C#. If the compiler can figure out that I’m missing a trailing semi-colon, why does it need one?

But the second thing that strikes me about Ruby is a lack of consistency in the language. Some conditional statements have an optional “do”. For example:

# these two loops are the same
while 1 == 1 do
something
end

while 1==1
something
end

But on other constructs such as the “loop do”, the “do” is required. I’m sure that if I were using ruby day in and day out, I’d become accustomed to those things and not even think about them anymore. But for someone learning the language, it does take some getting used to.