Archive for the 'Uncategorized' Category

Installing Pidgin 2.0 on Debian Etch

Thursday, May 10th, 2007

Wow, lots of libraries to install if you want to build Pidgin from src on Debain Etch. I can’t even name them all.

  • Get the Pidgin source.
  • Unpack tar xjf pidgin*.bz2
  • run ./configure
  • keep installing development libs and perl XML::Parser (which requires libexpat-dev) until config stops complaining
  • make
  • sudo make install

You may also pick up the experimental debs here. For me the experimental debs had too many unfamiliar dependencies.

Faceted Searching With Solr

Thursday, May 3rd, 2007

Chris Hostetter presented this presentation at Apache Con 2006. Faceted searching with Solr. Its pretty good and well worth the read. Solr has some special caching mechanisms to deal with facetes. I know one of the first implementations of Solr at CNET was to support facted search. So you wouldn’t be wrong in saying Solr was built to do faceted search.

Patent Claims and Marshall TX

Tuesday, April 24th, 2007

Techdirt reported Patent Trolls love Marshall TX. Which was also reported in a recent Slashdot article

People are often critical of patents sighting examples of big companies picking on little ones. Honestly I see it the other way around. Small companies get acquired while large companies get picked on by small companies with nothing to loose. I would rather have the current system for intellectual property then no system at all.

What Happened To Those Entries

Tuesday, March 6th, 2007

My service provider changed hosts on my. The old posts are lost on some machine sitting in another datacenter. Sure they sent two emails, but under the title and description our DNS servers are moving. I don’t care if the DNS server changes, I run my own DNS.

My hosting provider didn’t mention they would be changing machines and ip addresses. I swear they are idiots. Hosting providers are free to do whats best for their customers and owners, and providing their actions were clearly communicated I would be fine.

Communications is the key.

My Logo

Thursday, December 14th, 2006

Calder Group Logo

Rapid Development (aka Lean, Agile, Iterative) Processes

Sunday, October 8th, 2006

I get asked lots of questions about the benefits of a highly iterative process. I also get lots of questions about the tools used in iterative processes. These are good questions and I enjoy discussing them with people, but we hardly ever end up discussing the processes themselves.

I must admit I feel pangs of regret, because a key part of Iterative processes is the fact that the group owns the processes. Owning your processes is a lot of fun. After every iteration, the group should ask two questions

  • What Do We Want To Keep?
  • What Do We Want To Change?

If you keep asking those questions, and keep improving your processes, then everything falls into line. What tool to use isn’t even considered, instead new tools are picked to fit the processes that the group puts in place.

For example, lets suppose a group doing 2 week iterations is using Microsoft Project to manage their schedule.

  • After the first iteration: This sucks, we meet everyday and everyone knows the dependencies and what blocking them, yet every detail is still logged in MS Project. Lets stop putting dependencies and blocking into MS Project
  • After the second iteration:MS Project isn’t a huge time sink, but my boss can’t see how much work we’re doing. Lets make a bar graph the number of stories completed
  • After the third iteration:Some people don’t have project and they can’t edit their own task estimates, lets just try Excel instead. We really only need owner, estimate, hours left, status ordered by priority
  • After the fourth iteration:Excel isn’t too bad, now that the schedule is more self serve we can add the Blocked status back in.

Maybe this group will get to white board and sticky notes, maybe they won’t. They will keep working on their processes to make the improvements which work for them.

Nice Shirts!

Friday, June 23rd, 2006

Jeff has a nice collect of Yahoo shirts on display. Someday I will show off my collection of shirts.

I only tracked back 4 posts. TrackBack doesn’t seem to work too well as an API/Protocol. If anyone wants to re-write it I’ll pay them $100. :)

Measuring the Performance of Software Development Teams

Thursday, May 25th, 2006

I am often asked how do you measure the performance of software development teams.

Its a good question, and its surprising that I don’t have any clear answers. Recently I’ve been reading Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management. Which talks a lot about evidence based management and defining what real results are.

First and foremost, I expect my team to deliver something. Since our projects are mostly iterative based we make real deliverables to customers every 1-2 weeks. That right we have something real to show off after a one or two weeks. If a team can deliver something, anything, something has seriously gone wrong.

Second I look at story velocity. This measurement is usually aggregated across a single group, although sometime I peek at contractor story velocity, and compare it to the average to see if they are worth keeping. This measurement is only valid if the team stays together. If the team member keep moving around then the measurements get all screwed up.

Which brings me to my next metric. I look to see the number of people moving in and out of the project. Within an iteration the number should be zero. If a person leaves at the end of an iteration, they shouldn’t come back, so we measure that too.

Finally, I look at the severity and the number of bugs filed post launch. This includes the number of rollbacks, and outages caused by poor release planning. Any bugs which are severe enough to fix within two days or less, and filed after launch are a bad sign. Either, the requirements were not communicated correctly, or the level of quality was poor. Either way these critical post launch bugs are a huge time sink. Bugs filed after launch which must be fixed in one-two weeks or less are also measured.

Lastly something that I would like to measure, but have a hard time doing it is the amount of idle time for engineers. A poor manager doesn’t know how to keep his/her staff occupied. A poor manager will let their staff be blocked for long periods of time.

For non-agile projects I don’t have as many good measurements. With planned projects I make sure milestones are hit, and that a milestone exists every week or two. I also keep an eye out for heroes and cowboys. A cowboy or a hero is a bad sign, because it means one person is running too much of the project and their is a lack of peer review and team accountability. Either means a manager will never get the true status of a project.

Microsoft Business Scorecard Manager

Tuesday, May 23rd, 2006

I saw I demo of the Microsoft’s BSM. I have to say it looks pretty sweet. There is even a proof of concept for getting score card reports on your mobile phone.

Imagine, you manage a sales team and before the months end you can send each member of the team a SMS message with a link to their personalized score card. They’ll know exactly how they are doing against their goals.

Once the data is setup the interface is nice and clean, and usable by just about anyone. Even if the data is in Excel, the sourced data can not be changed, but data derived from the source is possible.

Pretty cool

test

Sunday, May 14th, 2006

test post