I'm On Rails

Finally, I have put www.henrikmartensson.org on Rails! I have rebuilt the site from the ground up with Ruby on Rails. It was a pleasure to do it.

The visible changes are small. There are a few more menu choices, including a link to this blog. The site also lists the most recent postings to this blog.

Behind the scenes, the site is now database driven. Articles, presentations and images are stored in a database and retrieved on the fly. This makes the site a lot easier for me to update and maintain. I hope this will encourage me to write more articles. We'll see what happens.

I had an unexpected problem with reading the Atom feed from this blog. I tried two different Atom modules, but neither could parse the feed properly. Both had trouble with Atom entries that contained more than one link. The problem was easily solved with REXML and XPath. The current implementation is a bit of a hack, but I'll improve it in the near future. I think there is a blog post just waiting to be written there.

The Best Kind Of blog Post

Pascal Van Cauwenberghe at Thinking For A Change has made the kind of blog post I like the most: it's about me. Well almost, it is about the Variance Trap series and the Theory Of Constraints based software development simulations I have run.

His post also reminds me that I haven't quite finished the series yet. One more article to go. Coming real soon now...

Test::Unit::XML 0.1.5 Has Been Released

Paul Battley emailed me about a bug in Test::Unit::XML. Attribute strings containing entity references were reported as not being equal even if the strings were exactly alike. I fixed the bug, added an assert_xml_not_equal assertion for good measure, and made a new release.

The assert_xml_not_equal assertion is the inverse of assert_xml_equal. It is mostly a convenience method. That is, it was convenient for me to have it when I wrote a test that compared attribute values.

I haven't worked much on my open source projects lately. It is not that I have lost interest. It is just that I have been otherwise occupied. Thus I am doing defect-driven development at the moment. When someone finds a bug, I fix it. If I can make some small improvement without spending a lot of time on it, I do that too.

Spolsky on How to Organize Software Companies

Joel Spolsky has written an interesting article about how to organize and run software companies. Here is a quote:

The command-hierarchy system of management has been tried, and it seemed to work for a while in the 1920s, competing against peddlers pushing carts, but it's not good enough for the 21st century. For software companies, you need to use a different model.

And here is another:

...if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings?

I think you will find the article an interesting read.

The 80/20 Rule

At Google, they have an 80/20 rule. Developers spend 80% of their time on work that has been assigned to them, and 20% is their own time, to spend on projects that are just interesting. That is one day per week that a Google employee can sit thinking things through, dreaming new stuff up, and implementing it.

Does it work? AdWords was created this way, and it is a major revenue maker. Google employees seem pretty enthusiastic. Google does attribute part of its success to the system. It seems to work very well, at Google.

Of course, at Google they have a pretty open and enthusiastic attitude to new ideas. "When someone comes up with a new idea, the most common response is excitement and a brainstorming session" according to a post by Joe Beda at Google. According to Beda, managers at Google actively encourage employees to come up with new ideas.

It is something to think about.

The Danger of Success

Pascal Van Cauwenberghe has posted an interesting article on the danger of succeeding with Theory Of Constraints. He is quite right. If your part of a process has been the system constraint, and you elevate it, some other part of the process will be the new constraint. The people responsible for that part of the process may be rather unhappy with you.

A friend of mine took a job as a subcontractor. He finished his job ahead of time, with no defects at all in his work. His manager was not happy. My friend was accused of "idling", because he had finished ahead of schedule.

The idea that it was the manager who was slow in obtaining more work was of course never under consideration. Nor was it ever under discussion that if the contract had been anything other than a time-and-materials contract, finishing early would not have reduced the net profit.

Quite often the slowpokes protect each other without even realizing they are doing it. I once worked at a company where nothing had less than 6 months lead time. Set up a web server, 6 months. Set up a build system, 9 months. Start working on a project, at least 6 months of up front design.

I have never been good at shutting up, so I pointed out that 6 months of up front design not only slowed the project down (see my postings about iteration size), it also deprieved us of feedback, so it was impossible to verify that the design really worked. I was told by the project manager that having a 6 month design phase did not matter, because we were waiting for the web server anyway.

Of course, the IT department that took 6 months to do a 1 day job felt no pressure either. The project was just in the design phase anyway, so why would we need a web server?

If we had set up the web server ourselves, it still would not have solved our problems, because we did not have the build machine. Still, none of that mattered, for getting a development database set up also took 6 months.

There was one thing more that was 6 months: the time estimate for the project.

Ah, well. There is no business like the IT business.