Dave Rooney shared a link today to a July 1996 article in CrossTalk: The Journal of Defense Software Engineering by Dr. Randall W. Jensen, titled “Management Impact on Software Cost and Schedule.”

As a firm believer and occasional practitioner of Extreme Programming (or, “XP”), the article is naturally very interesting. One of the key practices of XP is called Pair Programming, where two people sit at one computer and work on producing the code in unison. It’s very challenging: most software engineers are poor communicators, have social anxiety issues, or otherwise find objection to having to actually work with someone else directly. I’ve found that the biggest objectors to it are those who have never even done it. It is naturally one of the biggest advantages of the core XP practices over all the other agile methodologies popular today. Therefore, it’s no surprise that it hasn’t been done before. What’s surprising is how much earlier than XP it was done: according to Dr. Jensen’s article, it was done in 1975 (!):

Two-Person Team. The two-person (2P) team implements the adage “Two heads are better than one.” When this concept was first implemented in 1975, there was great concern the productivity gain could never offset the additional resource expense. The two-person approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code, and documentation as if the team was a single individual. The 1975 team’s project was a real-time, multitasking system executive of approximately 30,000 FORTRAN source lines. The development team had five 2P teams and a progressive Theory Y type project leader. The traditional development environment, outside the 2P team organization, was typical of most environments. The architecture design was completed in a war room environment. The project architecture divided the development into six independent tasks, with the two smallest tasks assigned to one team. The 2P teams returned to the war room environment during system integration. The team concept appears to have been violated when the project was divided among five independent teams working in their own small war rooms (two-person offices). There were two organizational issues working here:

• The facilities people (known as the furniture police) were not convinced this idea would work.
• The tasks were truly independent. Thus, the minimum team size of two programmers was adequate, and the project proved the significant benefits of teams as small as two people.

Final project results were astounding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm prior to the project. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization’s norm. Was the project a fluke? No. Why were the results so impressive? A brief list of observed phenomena includes focused energy, brainstorming, problem solving, continuous design and code walk-throughs, mentoring, and motivation.

It’s easy to come up with excuses why “this just won’t work” but the reality is, if you instead find equally creative ways to create an environment where your team can do Pair Programming, the measurable benefit will make you wonder why you hadn’t been doing this all along.

Tags:
software development,
Extreme Programming,
two-person teams

My laptop’s clock seems to get out of sync and fall behind quite often. I suspect it’s because the clock frequency keeps changing thanks to the power-saving SpeedStep stuff. However, it’s irritating that my clock is always wrong–especially when Windows XP has a built-in NTP client! Of course, the default is to poll once a week (!) … and the “Date and Time Properties” dialog doesn’t allow you to configure how often to poll.

Luckily, it is configurable through manual modification of a Windows registry value. It’s in the registry hive, here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

The value is SpecialPollInterval which is a DWORD number of seconds that is set to 604800 (one week) by default. I’ve ratcheted it down to 3600 (one hour) to minimize the drift of my clock but not putting undue stress on my local NTP server.

Once you’ve made the change, you’ll need to restart the Windows Time service in order for it to pick up the new interval. From a Command Prompt:

C:...> net stop "Windows Time"
The Windows Time service is stopping.
The Windows Time service was stopped successfully.

C:...> net start "Windows Time"
The Windows Time service is starting.
The Windows Time service was started successfully.

That’s it. You’ll want to click the “Update Now” button in the “Internet Time” tab under “Date and Time Properties” to force a NTP sync. and update the “Next synchronization:” date with your new poll interval.

I hope this tidbit is useful to anyone else looking to adjust the polling frequency of their Windows NTP client. I know this has certainly bothered me for a long time before I finally figured it out.

Update 2018-07-10: Some time between 2007 and 2018, Microsoft published and made publicly available documentation on the Windows Time Service, for anyone who’s looking for it.