Despite what you may have heard about distributed development, it’s not cheaper, it’s much harder, but it’s also worth it. That’s the message passed on by Zack Urlocker at the Monki Gras conference held in London earler this month. Urlocker’s talk, “12 Practical Tips for Managing Distributed Development” combines his experience with the experiences of a number of other managers who work with developers.

Urlocker is currently the COO of Zendesk and formerly executive vice president of products for MySQL. With MySQL and at Zendesk, Urlocker has no small amount of experience with working with distributed development teams. Zendesk, says Urlocker, is staffed with 160 employees and has four offices and two developer centers. MySQL was an “extreme outlier in distributed development” with more than 400 employees in 40 different countries — with 95 percent of developers working from home. The idea was “to hire the best we could, regardless of location.”

But how to make that work? A lot of managers have a bias for having employees in the same office. However, you can make better hires and have higher productivity from many developers if they work from home, wherever that may be.

Practical Tips for Managing Distributed Development Teams

One of the first tips, which Urlocker credits to Mark Devisser of Akiban, is that “toolsets define behavior.” Companies need to use tools that are “globally accessible” whether a developer is just down the hall or a continent away. It’s also vital to use continuous integration tools like Jenkins to ensure that problems are immediately obvious.

He also says that code should be at a “demoable” state at least twice a month. When there are problems with a project, they should be fixed immediately because you can’t “catch up” at the end of a development cycle.

Projects should also be distributed from the start. That means using tools like GitHub, Mercurial and other development tools meant for a distributed developer team. Code check-ins need to be well-documented with “brief and to the point” information about new commits.

Communicate, Communicate, But Use Social Media Carefully

Companies do need to be careful of trying to “force fit” social tools. Most of the time, a developer team will naturally gravitate to tools – like IRC — that they prefer. Don’t shove Yammer or the 37Signals suite down a team’s throat if they’re not into using it, but if they’re going to use those tools they’re probably a worthwhile investment.

Transparency is important even when a team is all in the same location, but when you’re dealing with a distributed workforce, it’s doubly important. Urlocker cited Steve Wilson for the transparency tip, and says that distributed teams need to spend more time on up-front requirements and written communications. Increased communication is vital when you’re working with people remotely.
If necessary, over-communicate. Urlocker says that if left alone, developers “assume the worst.” That means that managers should spend about half their time communicating with their teams. Use tools to screen-share or see demos on a regular basis. If possible, teams should have a 15-minute “daily scrum” or other meeting to keep interaction flowing. But don’t require video conferencing, says Urlocker. “It’s always 3 a.m. for somebody.”

Quality is just as important as quantity. Urlocker says that teams should use “military precision communications,” and include all relevant details when talking about an issue. That means bug numbers, customer IDs, helpdesk tickets, whatever is possible to make sure that an issue can be handed off.

Bring Developers Face-to-Face

Just because you have a distributed workforce, it doesn’t mean you should never get together with the team. Face-to-face time is necessary for team-building and it can be good to get teams together for sprints.

But don’t always make it about bringing developers to you. Urlocker says that “you can’t build a global culture from HQ.” Managers need to get on a plane and break bread and drink beer with their turf. That’s not just true of the development team, Urlocker says that product management and marketing should be in the act as well.

Having worked with distributed teams myself (I haven’t really worked in an office since the late 90s), I can attest that this is vital. You work much more effectively with people you’ve met face to face, and you’re much more invested in a company when you feel a bond with co-workers. It’s not necessary to sit in the same cube farm as everybody else to foster this. A few good visits a year with team members can work wonders.

Measuring Distributed Development Team Success

How do you know you’re successful if you don’t have a way to measure it? Another major tip for distributed teams? Metrics. As Urlocker pointed out “what gets measured gets done.” He also encouraged teams to publish metrics for the entire team to see – and yes, that does mean a “wall of shame” for developers who break builds and so on.

Finally, to be successful, you have to go all-in. Don’t assume one culture or one timezone. Make sure that everybody is using the same tool set, and has full access to the same set of tools.

Along the same lines, Nat Friedman has a tip that applies well here: everybody dials in. Level the playing field for people who are remote, and make sure every participant on a conference all dials in. That means that you don’t have four people in a room shouting over a speaker phone. If you want to make remote workers hate life, make them sit through hour-plus meetings where everyone else sounds like they’re at the end of a wind tunnel.

But, most of all, embrace distributed teams rather than being grudging about it. It may not be simple, but it does have a lot of benefits. You can recruit globally. You can save on rent. You might save money on salary, but you’ll certainly have an easier time recruiting senior developers and the best talent if you don’t restrict your search to people living in (or willing to live in) a single area.

Oracle and SAP may be back in court on June 18 to begin a retrial of Oracle’s corporate theft lawsuit involving SAP’s former TomorrowNow subsidiary, according to a judge’s order Thursday.

Oracle was awarded US$1.3 billion in damages from SAP last November as compensation for TomorrowNow’s theft of software and support materials from an Oracle website.

SAP argued the sum was unfairly high, and the court agreed, overturning the jury’s award. Oracle was given a choice of accepting a lower damages amount of $272 million or going into a new trial, and earlier this month it picked the new trial.

The two weeks starting June 18 are the only two weeks free on the judge’s calendar this year, Judge Phyllis Hamilton of the Northern District Court of California said in her scheduling order Thursday. If Oracle and SAP reject that date, they can choose Aug. 13, 2013, or else hope an opening comes up before then.

It will be a busy year for Oracle in the courts. The company is fighting two other big cases that are due to go to trial this year. One was brought by Hewlett-Packard, over Oracle’s decision to drop support for Itanium. The other is Oracle’s suit against Google for alleged patent and copyright violations in Android.

iChat is long live Messages. With Thursdays announcement of Mac OS X Mountain Lion comes the news that iChat is being upgraded and renamed to Messages, with support for the iMessage chat system introduced with iOS 5.

If you can’t wait until Mountain Lion arrives this summer to finally use iMessage with your Mac, relax—you don’t have to. On Thursday, Apple will also release a beta version of Messages for Lion users. (The final version will be available this summer when Mountain Lion ships.)

I’ve spent the past few days using Messages and Mountain Lion. Here is a first look, keeping in mind that Mountain Lion won’t be released for months, so features are in flux and could change.

It uses iMessage

The feature that transmogrifies iChat into Messages is support for Apples iMessage chat system. Apple says that in the few months since iOS 5 arrived, there have already been 100 million registered iMessage users and more than 26 billion iMessages have been sent.

When Apple introduced iMessage, people focused on how its similar to the SMS text-messaging system on phones. And yes, it’s cool that iPhone users can send text and multimedia files over the Internet without any of the per-message charges that wireless carriers levy for texts. But that misses the bigger picture: By using the Internet instead of the cellular system, devices that phones can join the party. iOS 5 gave the iPad and the iPod touch iMessage capabilities too.

iMessage supports some nice extra features such as the ability to (optionally) send information about whether you’ve received and read a message, and when you are in the process of sending a reply. To send a message to someone using iMessage, you need to know their Apple ID (which is usually based on their email address and may also be their iCloud username). Using the iMessage system, you can send text, pictures, and other attachments. If you need to talk with more than one friend, there’s even support for multi-person chats. Its all encrypted, and it works no matter if you’re on an iPhone, iPad, iPod touch, or a Mac. And if you are logged into iMessage on multiple devices, your conversations will go, you can start a chat on a Mac and end up on an iPad, with your entire conversation available for reference.

iChat plus iMessage

Though the name is now Messages, the features of iChat are more or less intact. The app still supports AIM, Yahoo, and Jabber protocols. (Since Google’s chat system uses Jabber, Messages therefore supports Google Talk, too.) There’s still a buddy list and still support for audio and video chats via those services. iChat Theater is still there, too—it’s just called Theater now, and is accessible once you start a video chat from the Buddy List.

The major interface change in the upgrade from iChat to Messages is the new Messages window. This is a new, persistent window that collects all your currently-active conversations, regardless of which service they are on.

A year after it rolled out the Mac OS X Lion, Apple again plans to introduce a new version of its desktop operating system. The update—dubbed Mountain Lion—will ship this summer. As with Lion, this latest version of OS X will incorporate many features first introduced in Apple’s iOS mobile operating system, as Apple looks to bolster the interoperability of its two platforms.

Apple previewed Mountain Lion on Thursday, rolling out a developer release of its new OS. The company also released a public beta of Messages, a revamped version of its iChat messaging app that replicates much of the functionality found in the iOS version of Messages.

In addition to Messages, Mountain Lion also adapts such iOS features as Reminders, Notes, Notification Center, Twitter integration, Game Center, and AirPlay Mirroring for the Mac. Mountain Lion also adds options for limiting the kinds of apps users can install and increases the integration with iCloud, Apple’s data-syncing service. You can get all the details of Thursday’s announcements on our Mountain Lion topic page.

Thursday’s surprise announcement of the next version of Mac OS X had developers across the Mac community perking up their ears, thanks in no small part to a new feature in Mountain Lion called Gatekeeper.

“My takeaway on Gatekeeper is it’s a lightweight introduction of the notion of registered developers outside the App Store,” Daniel Jalkut, proprietor of Red Sweater Software, explained to Macworld.

Gatekeeper relies on a technique called code-signing, in which software developers are provided with a cryptographic certificate from an authority–in this case, Apple–which they can then use to digitally “sign” their applications. It’s similar to the process that consumers encounter when they buy things via the Web, in which they’ve been trained to look for the padlock icon that indicates a secure transaction.

“Security based on digital signatures has been a long time coming, so it shouldn’t be much of a surprise to developers,” said Ecamm Network co-owner Glen Aspeslagh. “As the Mac gains in popularity, Apple’s approach will be a powerful and much needed weapon against malware.”

While our Windows-using compatriots have been plagued by malware of all shapes and flavors, Mac users have remained largely unscathed, although the debate continues to rage over whether that’s because of innate superiority in the Mac operating system or the Mac’s smaller market share presenting a less tempting target for writers of malicious software.

Certificate of authenticity

Apple’s new approach relies on the idea of what it calls “identified developers,” which is to say developers to whom the company has issued a digital certificate. That certificate becomes linked with the developer’s identity and subsequently with their applications. If Apple finds that a software maker is distributing an application that contains some sort of malicious code, it can revoke the certificate, which–depending on how a user has Mountain Lion set up–may prevent the app from launching. Presumably, Apple could even revoke all the apps from a single developer with the flip of a switch.

This isn’t really a new concept for Apple; code-signing as an option has been around since 2007, when it was introduced as part of Mac OS X 10.5 Leopard. And the company has employed it as a requirement for programs distributed in both the App Store for iOS and the Mac App Store.

“We’ve been in the Mac App Store for a while (since the very beginning),” Bare Bones Software’s Rich Siegel told Macworld, “and as far as I can tell, if you’re shipping a Mac App Store product today, you’re an ‘identified developer.’”

But, of course, not all Mac developers participate in the Mac App Store. So while developers can sign their own code to certify, for example, that the contents of their apps have not been altered since distribution, they can’t reap all the potential benefits that code-signing has to offer. In order to do that, the certificates would need to be issued by a trusted authority–to wit, Apple.