ITJOBLOG

Reconsidering recruitment

Thu, 26 Aug 2010 15:01:16 +0000

Starting my career in the software development trenches at consumer electronics company Psion, I've seen the challenges of recruitment from all angles. And as my career has evolved from job seeker to recruiter the frontline experience has stayed with me. Particularly the ability to recognise the very best skills for the job. I also have an appreciation from both angles of how important it is to invest time in recruitment to make the right decisions. A bad judgement call has repurcussions on the individual, the immediate team and the wider business. In recent weeks, I've once again found myself in a situation where considerable people growth is required. I'm working on a project at Accenture, assisting their Embedded Mobility Services group. Mobile is increasingly a hot topic, and there's strong demand for people providing expert consuItancy in a variety of mobile development project settings. This experience has led me to review my beliefs about the best way to carry out recruitment in such situations. Permit me to think aloud...

To start with, I remain a huge fan of graduate recruitment programs. The best graduates bring fire in their bellies: a "we can transform the world" attitude that doesn't know what's meant to be impossible - and often carries it out! Of course, graduates typically take some time before they can be deployed in the frontline of commercial software development. But if you plan ahead, and have effective "bootcamp" courses, you'll have new life in your teams soon enough. There will be up-and-coming stars ready to step into the shoes left by any unexpected staff departures or transfers. If you can hire a group of graduates at the same time, so much the better. They can club together and help each other, sharing and magnifying what they each individually learn from their assigned managers and mentors. That's the beauty of the network effect.

That's just one example of the importance of networks in hiring. I place a big value on having prior knowledge of someone who is joining your team. Rather than having to trust your judgement during a brief interviewing process, and whatever you can distill from references, you can rely on actual experience of what someone is like to work with. This effect becomes more powerful when several of your current workforce can attest to the qualities of a would-be recruit, based on all having worked together at a previous company in the past. I've seen the benefit of this effect via networks of employees, sometimes at competitive companies, who all knew each other and who could vouch for each others' capabilities during the recruitment process. I've also utilised internal networks of high-calibre people from newly mergered and acquired companies, a time when talent can easily get overlooked. The benefit here isn't just that you know that someone is a great professional. It's that you already know what their particular special strengths are. ("I recommend that you give this task to Mike. At our last company, he did a fantastic job of a similar task.")

Next, I recommend hiring for flexibility, rather than simply trying to fit a current task description. I like to see evidence of people coping with ambiguity, and delivering good results in more than one kind of setting. That's because projects almost always change; likewise for organisational structures. So while interviewing, I'm not trying to assess if the person I'm interviewing is the world expert in, say, C++ templates. Instead, I'm looking for evidence that they could turn their hand to mastering whole new skill areas - including areas that we haven't yet realised will be important to future projects.

Similarly, rather than just looking for rational intelligence skills, I want to see evidence that someone can fit well into teams. "Soft skills", such as inter-personal communication and grounded optimism, aren't an optional extra, even for roles with intense analytic content. The best learning and the best performance comes from ... networks (to use that word again) - but you can't build high-functioning networks if your employees lack soft skills.

Finally, high-performing teams that address challenging problems benefit from internal variation. So don't just look for near-clones of people who already work for you. When scanning CVs, keep an eye open for markers of uniqueness and individuality. At interview, these markers provide good topics to explore - where you can find out something of the underlying character of the candidate.

In summary, I see recruitment and induction as a task that deserves high focus from some of the most skilled and perceptive members of your existing workforce. Skimp on these tasks and your organisation will suffer - sooner or later. Invest well in these tasks, and you should see the calibre of your workforce steadily increase.

Whither the business card?

Mon, 09 Aug 2010 07:44:59 +0000

Anyone who has been in the IT sector for a reasonable amount of time will have collected their fair share of business cards. As a freelancer on the look out for new IT work, they used to be invaluable. Handing them out at conferences, training events, and even at chance meetings in the bar used to increase your chance of getting work. But with smartphones and social networking, are they as important as they used to be?

I'm thinking about the last few contacts I made face to face in this business, and it dawns on me that most of them have been made electronically. I hate business cards, because I never have time to enter all the details from the cards that I collect on trips. This means that the information on the cards sits in drawers and gets lost. It is never there when I need it. Neither is the information on the card 'alive', because it doesn't represent a link to someone's online information. Instead, it is static, and dry.

I generally find contacting someone via a social network far more productive than simply exchanging business card information, because not only do you get a means of contacting them online, but you also get other useful information about them that is regularly updated. Adding someone on LinkedIn, for example, will give you useful information about who they have worked with, and what they've done. When dealing with potential employers or employees, this is invaluable.

Even when I meet people face to face, I now find myself linking with them electronically by 'bumping' them. Bump is an application available for the iPhone and the Android operating system that lets you exchange contact data by simply shaking your phone near someone else's. All of your contact information drops into their address book, and vice versa. It even lets you connect to your fellow Bumper on social networks such as Facebook and LinkedIn.

Unfortunately, BlackBerry users, along with owners of other phones other than the iPhone or the Android, can't use Bump. But even in this scenario, or in a situation where someone has a supported device but doesn't use Bump, I find that we connect with each other later on by searching each other out on a social network.

Even if someone hands me a business card these days, I will generally throw it away within a couple of minutes. Why? Because I use a business card scanner built into my phone to register all of their information and drop it straight into my contact database. I was using Shape Services' Business Card Reader for the iPhone, which takes a photograph of a card and uses a mixture of optical character recognition and clever software guesswork to decode the visual information in a card. However, CardMunch is now offering a similar application with a difference - you pay for each card, and the image is farmed out using Amazon's Mechanical Turk service to human workers who verify that the information on the card has been correctly interpreted.

I've also found myself replacing the traditional CV with an electronic one. I find that using LinkedIn's profile page to its full extent can provide more information than a conventional CV ever could. When applying for gigs nowadays, I send people my LinkedIn profile URL, which lists my full working history, while also displaying other people's testimonials about me. It's like having tens of references built into your CV.

Of course, people will still probably want to carry cards around in case of emergency - but I'd hope that at this point, people would be willing to do something really creative with them, and use them as high-end calling cards for particularly valued contacts, rather than merely as the inefficient mechanisms for information exchange that they have become. Back in 2001, design firm IDEO presented a project that it hoped would reinvent the business card. The company has taken the link down since, which is sad, because even now, the ideas presented there are still highly imaginative. Here's the Wayback Machine link to a cached version of the original site.

Agile Gives Management a New Schedule Game: Double Your Velocity

Tue, 27 Jul 2010 08:57:35 +0000

In Manage It! Your Guide to Modern, Pragmatic Project Management, I explained a schedule game called "We'll go faster now." That's the game where the project team thinks they can improve their speed, even though there is no data that says they can.

There's a similar management game, called "Double Your Velocity." Say a team is new to agile. They estimate they can complete 72 points in a two-week iteration. In the first iteration, they complete 30. Ok, they figure out what's wrong during the retrospective, and they complete 55 points in the second iteration. They learn more about their estimation, so they estimate the stories better, and they refine what done means, so they plan for 63 points in the third iteration. They make it! They keep proceeding, and eventually, they settle in at around 67-68 points per iteration.

Now, a senior manager wants to "help" the team. I see this often masquerading as "motivation." A senior manager comes to the team, gives them a pep talk, and says, "I want to see you double your points for the next iteration." Depending on the team, they may ignore the manager, flip the manager the bird, or placate the manager by doubling their points for each estimate.

This is a management velocity game. It's a game, because management can't motivate people to do more work. Teams can see what's slowing them down, remove those obstacles and maybe they can finish more work. But this business of "motivation"? What a bunch of nonsense. (Tell us how you really feel, Johanna :-))

The real problem is when the manager thinks that the placating team has increased velocity based on his or her actions or pep talk. That's when the team might think they can go faster now, or they keep playing with their estimation points.

Velocity is personal to a team. Period. Mucking with the points does not make the work get done faster.

Should you care about Windows Phone 7?

Sun, 25 Jul 2010 10:12:37 +0000

Windows Phone 7 may not be available yet, but it is a great talking point. Following the collapsing market share of Window Mobile and the Kin debacle, will Microsoft be able to claw its way back into the SmartPhone market? With mobile apps increasingly important in both the consumer and business world, what would be the consequences of failure?

The strategic importance of the platform makes it interesting even if you think that there is little room for Microsoft's phone in a market dominated at the high end by the two As: Apple and Android.

There is even fierce competition among the also-rans, with Nokia pitching Symbian 3 and Maemo/Meego, and HP presumably about to do something with Palm WebOS. And what about Samsung's bada? There will be blood on the carpet; not all these operating systems will survive - and while that will be a shame from the point of view of diversity, it will be a relief to developers attempting to support the broadest number of devices.

So why even bother with Windows Phone 7? Well, there are a couple of obvious reasons. One is the possibility that Microsoft will deliver an excellent and delightful device. Likely? Past form says no; but the company knows what it is up against so you never know; early reviews of preview devices have been generally favourable.

The second reason is less speculative, which is the way Windows Phone 7 fits in with the rest of Microsoft's platform. If you are used to coding in Visual Studio with C#, then creating apps for Microsoft's new phone will be less challenging than doing so for iPhone or Android. A Windows Phone 7 app is essentially a .NET and Silverlight app, or for games XNA, and from what I have seen so far Microsoft has done a good job with the emulator and developer tools.

The disconnect here is that Microsoft's primary target for Windows Phone 7 is the consumer, whereas those armies of Visual Studio developers are largely building corporate apps. Some of them are also annoyed that Microsoft is not providing compatibility with existing Windows Mobile applications.

There are also significant limitations in Windows Phone 7 in its first release. There's no multi-tasking, which means you have to write code to handle your application being shut down and re-activated while giving the appearance of resuming where the user left off. There's no native code, which runs contrary to the instinct of experienced mobile developers, some of whome tried and failed to wrest acceptable performance from the Compact Framework, the mobile .NET Framework from pre-Silverlight days. There's no copy and paste - which does not seem a big deal to me, but some people seem to care a lot about this. Another annoyance is that all apps must be deployed throught Microsoft's Apple-style Marketplace, though I hope and expect that Microsoft will come up with a way round this for corporate roll-outs.

Future iterations of Windows Phone could remove these limitations, but in this instance Microsoft does not have time to release something not very good and get it right three versions later.

I'm keen to hear from developers who have tried the preview devices or the SDK. Like what you see? Intend to support it? I look forward to comments, because the success or failure of this product is going to be significant.

Is the mainframe dead?

Fri, 23 Jul 2010 07:31:20 +0000

Is the mainframe dead? No, but it's changing shape. IBM's latest launch is a good example of how traditional mainframe culture is disappearing -- and how the landscape for mainframe skills is changing, too.

IBM's new machine, called the zEnterprise 196, is an update of its System z mainframe. The company, which is calling the unit a "hybrid computer", has married traditional mainframe components along with Power 7 blades, and x86 blades, too. The system, which is also being trumpeted as a "data centre in a box", is designed to support heterogeneous IT operations from a single platform.

Back in the day, a mainframe was a mainframe. Processors designed purely for the mainframe platform were combined with an operating system dedicated to that system. Developers wrote applications in mainframe-centric languages such as COBOL, and the concept of merging different operating systems and hardware platforms into the mainframe was rare, if heard of at all.

For some years now, IBM has been changing that. It has given its mainframe users the chance to run virtualised instances of Linux on its mainframe boxes, opening up the opportunity for many instances of open source applications to run alongside each other. And the zOS operating system supports many modern computing frameworks, such as Java. But IBM still relied heavily on its own processors as the hardware platform for the mainframe and operating system. Conversely, its competition -- who collectively make up a small percentage of the market that IBM dominates -- have mostly switched to commodity Intel CPUs to lower development costs for the hardware.

IBM's decision to mix its traditional home-grown processors along with commodity chips in its new mainframe offering indicates a significant change of direction. The company appears to be acknowledging that the mainframe is increasingly becoming a 'build-out' platform, rather than a traditional 'big iron'-only resource. The introduction of distributed technologies into the mainframe platform shows just how far it has penetrated this traditionally monolithic world.

IBM has explained that this system is essentially a heterogeneous datacentre in a single hardware platform, with all the associated benefits, such as a smaller physical footprint, a unified management hub, and an integrated set of components.

What will this do to traditional mainframe skills? It simply acknowledges their passing. Mainframe administrators as we used to know them are retiring and their skills are disappearing. The new, modern breed of administrator is increasingly required to cope with a variety of heterogeneous technologies in addition to traditional mainframe system management. The mainframe as we knew it may not yet be dead, but it is certainly being displaced by a newer, more flexible approach to big iron

Google Android wins in mobile developer survey; looks bad for Flash, Windows

Wed, 14 Jul 2010 08:24:07 +0000

I've been reading a new survey of mobile developers from VisionMobile. Around 400 developers were surveyed, and the platforms covered were iPhone, Android, Symbian, BlackBerry, Java ME, Windows Phone, Flash, and the mobile Web.

The topic is significant. Companies everywhere are crying out for mobile apps, especially for Apple iPhone but increasingly for Google Android as well. The device+cloud computing model is today's big trend, and support for mobile devices in some form or other is becoming necessary for a wide range of applications and web sites.

The first notable fact is the extent to which iPhone and Android dominate. This chart on page 10 tells the story: there is little relationship between the device installed base and the number of available apps. Windows Phone, for example, has 75 million devices out there but only 13,500 apps; iPhone has 60 million devices and 225,000 apps.

The reason is that Apple has created a viable ecosystem for development, as well as a superb mobile platform. Much as I dislike the locked-down nature of that platform, and its Apple tax, I acknowledge and admire what has been achieved.

Android has just 20 million devices but 72,000 apps. I'd guess that the quality of those apps is not as high on average, but it's still clear that iPhone now has competition.

If this paper is to be believed, Android will even pass iPhone. Android is identified as the most popular among developers, with around 60% using it versus 50% on iPhone. Why?

We believe that Android's lead in developer mindshare ahead of Apple's iOS is down to two factors: first the $99 fee developers have to pay in order to deploy their applications, an entry barrier which reduces the innovation from developing countries. Secondly, the very effective use of open source licensing as a marketing technique to attract developers to Google's Android.

Another factor is that Android apparently offers the best developer experience. In an appendix, the survey tests iOS, Android, Symbian and Java ME for coding, debugging, device emulation and support resources. Novices could create a simple app more quickly on Android. The coding effort was less; building 9 simple apps took nearly 3000 lines of code on Symbian, versus just under 1500 lines on iPhone and a little over 1000 lines on Android. Debugging is faster on Android. The survey comes up with the following claim:

Using the above data, we can say that when developing common applications, each hour of work for a given Android developer, irrespective of level of experience, equals 1 hour and 10 minutes for a Symbian developer, 1 hour and 20 minutes for a Java ME developer and approximately 1 hour and 30 minutes for an iPhone developer.

Contentious, no doubt, and a lot will depend on what sort of app is being developed. Still, a good result for Android.

Both iPhone and Android seem safe bets, but what about other platforms? Adobe Flash is an interesting one:

Our research further indicates that Flash developer mindshare seems to be in decline, despite Flash's installed handset base of more than 1.3B devices. Adobe's string of execution failures has meant that the installed base for Flash Lite is extremely fragmented, breaking the write-once-show-anywhere story for media brands who are Adobe's key customers. At the same time, Flash, the much-touted replacement for Flash Lite, was more than 18 months late, while Flash Lite shipments have stagnated, dropping from 43 percent to 15 percent of handsets sold from 1H09 to 2H09. This leaves Adobe with a rapidly shrinking window of opportunity, primarily on Android handsets, while having been banned from Apple's growing empire, and slowly seeing the adoption of HTML5, yet another replacement threat for Flash.

That's overly negative in my view. In favour of Flash is that it runs on the Web and desktop as well as on mobile, and will run across a number of mobile platforms. Even so, the research shows the pressure on Adobe to deliver mobile Flash, which will not be in the hands of the public until Android 1.2 "froyo" is availble on devices; and the Apple problem will not go away.

Symbian is in trouble too; in fact, since Nokia is now moving to MeeGo for smartphones, it now has little interest for developers. Some observers think Nokia should go to Android instead.

Java ME? Windows?

The vast majority of Java ME respondents have lost faith in the write-once-runanywhere vision. Moreover, anecdotal developer testimonials suggest that half of Windows Phone MVP developers (valued for their commitment to the platform) carry an iPhone, and would think twice before re-investing in Windows Phone.

That strikes me as accurate. Predicting the future is hard though. Google Android came from nowhere; it is possible that a couple of years from now different patterns will have emerged.

For now though, it's iPhone and Android all the way.

Team Velocity Indicates Progress

Thu, 08 Jul 2010 07:25:09 +0000

Once we get past the first few iterations, velocity should be relatively constant, unless people are missing. If it is not, that's an indication that something might not be right.
A decrease in velocity, assuming no one is on vacation or away, may indicate technical debt.
An increase in velocity may indicate technical debt because the features are not really done.
Or, a velocity increase may be a result of the team revising how they create user stories or estimate.

Velocity changes are not good or bad, they are. And, if you track velocity, you will have more information about the team's progress.

I particularly like to track velocity as a burnup chart.

You can see in this image that requirements increase over time (what a surprise :-), and that the team has a relatively constant velocity. This team had been together for a while which is why their velocity was relatively constant. When the product owner decided to increase the number of requirements, they were able to predict (and meet) their new date for release.

Velocity work as long as you are using some form of incremental lifecycle. Since agile is iterative (using timeboxes) and incremental (completing features as you proceed), velocity works well to indicate real progress.

Slowly but surely, the IT industry is recovering

Fri, 25 Jun 2010 10:22:54 +0000

Is the IT industry recovering? It might be, if recruitment figures are to be believed. According to statistics from CWJobs.co.uk, the number of IT jobs advertised in all sectors in the first quarter of 2010 was 4% higher than during the previous quarter. CWJobs's quarterly survey of the IT jobs market also found that the financial services market -- perhaps the most hardest-hit by the economic downturn -- posted 23% more jobs in Q1 than it had in Q4 2009.

The financial services sector is one of the most IT savvy, given its propensity for moving pieces of information around. When information is your core product and your means of differentiation, it makes you invest in IT more than, say, someone in the manufacturing sector might. CWJobs.co.uk says that financial services has been the top ranking sector for IT job postings since 2006. The media follows next in terms of permanent IT job postings, followed by retailers and the public sector. Manufacturers come in fifth. The results are pretty much the same for contract IT positions, aside from the public sector, which beat media, retail and manufacturing companies to become the second most prolific poster of contract IT jobs.

It's about time we saw some movement. 2009 was a poor year for the IT industry overall. Gartner said last month that worldwide IT services revenue fell 5.3% to $763 billion in 2009 as the world recoiled from the financial crisis. We are due for some good news, for a change.

We can see the signs of recovery in other areas, too. In April, Gartner said that worldwide PC shipments had grown by 27.4% in the first quarter of the year, reaching 84.3 million units -- that's getting on for 1 million PCs each day. Slightly more conservative figures from IDC said that the worldwide market for PCs had grown by a more modest 24.2% to 79.1 million units. A year ago, the PC market had seen the worst decline since 2001, slipping by almost 7%. This indicates a massive refresh among companies which have avoided buying new equipment for some time. Part of this might be down to the success of Windows 7, but I suspect it's more to do with an economic recovery thawing previously frozen budgets.

So, what are the most common IT skills required in job postings this year? SQL was the most requested IT skill for both permanent and contract IT jobs, followed by C, and C#. Database skills are therefore still in high demand. Specific database products from Oracle and Microsoft featured in the top 10 list of skills, suggesting that this perennially sought after skills area is still hot.

It is time to break out the CVs again -- in the IT industry, at least, the green shoots of recovery are firmly above the ground. Have a nice summer.

Why I'm wary of user experience hype in software design

Sun, 20 Jun 2010 08:05:22 +0000

I'm just back from Adobe's partner conference in Amsterdam, where George Neill, Lead Experience Architect at Adobe Consulting, shows us this great slide depicting a woman processing mortgage applications. She has a PC on her desk which is running her organisation's app for managing mortgage applications. However, around here desk are multiple signs of usability failure. On her left, a paper calendar with names and phone numbers handwritten onto deadline days. On her right, an old-fashioned paper roll calculator. In front of her, a pile of paper forms colour coded with post-it notes. The app, Neill notes, should be handling all these tasks, but one glance at the user's working process is sufficient to expose its poor design.

All good stuff. The next thing we see is a nice application built with an Adobe Flex front-end and an Adobe LiveCycle back-end, with the not-so-subtle implication that these user-experience (UX) focused tools will help us create applications that fix this kind of design failure. There's also talk here at Adobe's partner conference of a new era in software built on customer experience, and how consumer technology from iPhone to Facebook and Twitter is raising expectations when it comes to business applications. There are even a few digs at developers, the people who, it is alleged, hate it when requirements change and who develop software geared towards the IT system which which it integrates, rather than towards users.

There is truth in all of this, but I'm cautious. It is easy to find a poor application and poke fun at it, but the idea of observing users and creating applications that improve their productivity is not a new one, and it is not necessary to use Adobe's stuff in order to do good software design. There are even times when it gets in the way. I recall spending time looking for a campsite on the web, for a holiday, and how it was in general the simple HTML sites rather than the "rich" Flash-driven ones that were easier to navigate. Admittedly the average campsite does not create web applications to Enterprise standard, but the underlying point is that there is a case for simple as well as a case for rich. Never forget "skip the intro".

The key question here: how do we define excellence in user experience? Let me state the obvious for the moment.

Applications that have functional deficiencies will not be rescued by any amount of eye candy or beautiful state transitions; and if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue, unless we strip all meaning from the term and use it for every aspect of software design, features and performance.

Second, software can deliver a good UX without necessarily having gorgeous graphics and multimedia. As a business software user, I value applications that let me accomplish tasks quickly and easily. Question: think of a web application that changed the world, partly thanks to superb UX? Answer: Google search. Question: how much PhotoShop and Flash was used in designing the fantastic Google home page?

The case for user-centric software design is irrefutable; but we need rigour when it comes to working out what that means and how to achieve it. I like this comment which I found in an 2004 paper by Larry Constantine:

User-centered design is a good idea in need of improvement. The needed improvement is found in practices that put uses rather than users at the center of design and in changing the prime objective from enhancing user experience to enhancing user performance.

UP rather than UX resonates with me. It also reminds me of Kathy Sierra's mantra: creating passionate users. If the current rush towards UX puts the focus there, I am all in favour. If it means newly empowered designers imposing some sort of visual or multimedia experience on us whether we like it or not, count me out.

Standing Up at Standup Meetings?

Thu, 03 Jun 2010 08:03:19 +0000

A client who's trying to move to agile is having trouble with the idea of literally standing at standup meetings. "I get the whole part of keeping the meeting short, but why do we have to stand up? My legs get tired."

I explained that when people don't stand, they are more likely to initiate and jump into sidebar conversations, aka rat-holes. "We don't do that here."

Um, yes, they did. And, we had the video to prove it. We were trying to do a feature-in-a-day, something I often do with clients, to see where the bottlenecks are, and how little they can actually do and still deliver valuable results. We were doing one-hour timeboxes with standups in between to see what was actually going on. We gained a number of valuable insights in our standups:

The one-hour timebox was too short. We should have done two-hour timeboxes. But we didn't because not everyone could free their schedules to participate every two hours, so we learned something about their projects and their daily organization.
When everyone stood up, the standups were no more than 5 minutes. When even one person sat down, we had tangents and rat-hole discussions.
They discovered that creating a project on their configuration management system cost them more than 30 minutes. Very interesting.
They learned that they had people who were even more specialized than they originally thought.
Almost everyone was quite willing to learn what other people do and how to help them.

If you are considering moving to agile, try a feature-in-a-day. And, as you do that, do practice standup meetings and standing up for them.

Apple iPad launches, a bad day for Microsoft and Adobe

Tue, 01 Jun 2010 10:00:34 +0000

The iPad has just launched in the UK, queues are long, stock is short, and it is yet another successful new product from Apple. The iPad has frustrations, like no Adobe Flash support for web browsing, no Java, no printing, and the general sense that you do things the Apple way or not at all. Still, users love it and are willing to pay for it, and in the end that is what matters.

Does this shiny gadget have any relevance to the more humdrum world of business IT? I think it does, especially when taken together with other factors. Here's a remark from Apple CEO Steve Jobs from an informal email conversation with Ryan Tate:

The times they are a changin', and some traditional PC folks feel like their world is slipping away. It is.

Yes, it's a Bob Dylan reference; read the entire thread to see why. Jobs is marketing his company's stuff, of course, but a few days later the stock market put some solid evidence behind his claim. Apple's market capitalisation surpassed that of Microsoft for the first time since 1989. Microsoft remains more profitable; but the figures reflect the market's judgment that Apple has better prospects for growth.

Another sign of change comes from one of Microsoft's most important partners, HP. At the end of April it acquired Palm, and with it the WebOS operating system for mobile devices. Whether HP can make a success of WebOS is uncertain; it will not be easy going up against Apple and Google Android. What is more significant is the implication that HP has finally lost faith in Microsoft's ability to get it right in mobile.

Despite some positive buzz around Windows Phone 7, Microsoft did not help its case when it announced a major reshuffle in its Entertainment and Devices division on May 25th. This follows the bewildering launch of the Kin phone - bewildering because it seems right out on its own in terms of strategy - complete with typical Microsoft flaws according to this thoughtful review:

But the obtuseness of this user experience doesn't stop with the Spot -- it permeates the entire interface as though decisions about how things should work were made almost arbitrarily, without anyone stopping to test them in the real world. The Twitter implementation is a great example of that. You can add your Twitter account to the phone and see updates from people you follow, and you can update your status from the top of the Loop... but that's all you can do. You can't retweet something, you can't send a direct message, you can't go to single person's feed to see all their updates, and you can't even open a link in a Twitter message from the Loop!

Windows Phone 7 will have to be much, much better if Microsoft is to claw back any ground in mobile.

I digress. All that matters is that the world is changing, and looking less Microsoft-shaped with each passing day.

In saying that, I don't mean to diminish the excellent work which I see coming out of some parts of Microsoft - Visual Studio 2010, for example - or to ignore the continuing dominance of the company in many areas of business IT. Many companies still standardise on Windows, and Microsoft Office remains the only productivity suite I come across in work.

All true, but the two great IT trends of today are not centred on Windows and Office. One is mobile, the other is cloud computing; and of course there is synergy between them. Apple's iPad is a further advance for mobile, and will drive increasing mobile data usage and increasing demand both for iPad/iPhone applications and for web applications that work well on those devices.

Agile Requires Cross-Functional Teams

Fri, 28 May 2010 07:32:45 +0000

I'm discussing some engagements with some so-called "Agile" clients. I ask them what they mean by agile, and they say they work in timeboxes (most of the time), and that they have a ranked list of requirements. And, then they say that when the developers are done, they hand off to the testers at the end of the iteration. They don't understand why the testers can't keep up.

Development isn't the only activity that needs to happen in the timebox. Testing, writing, anything else that you need to get to releaseable product is what has to happen in the timebox. That's why agile requires cross-functional teams for the entire duration of the timebox. (I would argue for the entire project.)

Here's an example. Say you're working on a medical device. You have development to do, testing, a little documentation, and the requirements traceability matrix to fill in so you have an audit trail. You would need some developers, at least one tester, a writer, and either that team needs to know how to do the paperwork, or you need someone from the process group to work with the team. At the end of the iteration, you have finished features: tested, documented for the user, and documented for an auditor.

You can't do this without a cross-functional team. But too many managers are concerned about wasting people's time. "But the writer isn't busy the entire time. I want people working at 100% capacity!" Here are some arguments against that kind of thinking:

Do you care more about keeping people busy or releasing the product? If you care more about releasing, it won't matter if people are only partially "utilized." They can either help out or think about how to make the rest of the project work easier for the rest of the project team. When people have a little slack time, they can think about how they work.
You don't actually know how much time the writer needs to make the documentation correct, or how much time the tester needs to test. People who are not developers are so accustomed to doing the bare minimum (or less), they don't always know what it takes to do a great job.
People who are not fully "utilized" can provide early feedback to the others in the team, whether that feedback is about the project or the project's process. The team can catch problems early rather than too late.

The cross-functional team optimizes for the project and therefore the product, not the individual. If you are already working in timeboxes, great. If you have a single-function team, add one more function the next iteration. Keep those people there the entire iteration. See what happens. I bet you decide to add any other missing functions for the next iteration.

Don't think you can do agile with a single-function team. Yes, you can work in timeboxes, which is almost always a great idea. But you aren't getting the advantages of agile with a single-function team. You're still pushing the feedback downstream instead of receiving the feedback right away. Try an integrated, cross-functional team. You may be surprised by how fast you can go--or at least, by knowing earlier that you are not going to be able to meet a release date.

Recrafting government as an open platform

Tue, 25 May 2010 07:41:03 +0000

How effective are the world's governments at using technology to become more responsive? Technology has revolutionised the way that we do business, but the public sector has traditionally moved more cautiously than the private one. Now, a report from the Centre for Technology Policy Research in the UK has made some recommendations for the use of technology as an enabling mechanism for government.

The document discusses the concept of open government, which it defines as a government subject to public scrutiny, in which employees work in "smarter, better informed ways". In order to achieve open government, an administration cannot simply tack technology onto existing processes, the report warns. Instead, it suggests changing key processes from the centre outwards.

What might this look like? The report cites Tim O'Reilly, founder of technology publisher O'Reilly, arguing for government to be recast as an "open platform" that encourages innovation and change. To encourage this, the Centre for Technology Policy Research makes several suggestions.

Cultural changes are necessary to create an Internet-aware government, the document says. A vision must be created by leadership, outlining guiding principles that must then be enforced.

Audits should focus on outcomes, while enabling departments to achieve those goals using their own means. Opening up access to social media tools may help them to meet their objectives, by helping governmental organisations to listen to feedback from traditionally under-represented groups, such as front line workers. Other tools that could help to achieve positive outcomes include real-time communication tools such as live chat.

Other technology policies include a board-level, CIO function, compulsory training in technology and related policy for senior civil servants, and the integration of technology planning into public policy documents, rather than addressing it individually in dedicated IT planning documents. Other high-level recommendations include the revolutionising of procurement practices via the use of free cloud-based services for commodity functions such as social networking, and the replacement of all-rights-reserved licencing with open licence agreements in public contracts.

Talking of openness, the use of open standards and open source in public systems is a strong recommendation in the report. Government systems should support interoperability wherever they can, it said, adding that open source, taxpayer-funded code should be shared across all areas of government.

We are already starting to see cloud computing providers targeting this sector. For example, Google has been heavily targeting government players. The City of Los Angeles replaced its Novell Groupwise system with Google Apps last October. At a federal level, the US Government has launched its own cloud computing initiative under the banner Apps.gov, which includes applications from a number of cloud players, including Google and Salesforce.

Significantly, the UK Government just announced this week that it would be cutting $95m from its own IT budget, and David Cameron has in the past questioned the wisdom of large, centralised projects such as the National Health Service's mammoth Connecting for Health project. Instead, he has posited the idea of working with specialist cloud players to achieve similar goals. Signs are already emerging that we can expect a significant policy change in such areas.

All of this will radically change the role of service providers and the process of procurement in public sector IT, and those working in the area would do well to take note. A recent qualitative study conducted by Microsoft in conjunction with the Institute of Directors, called the Hybrid Organisation, describes the need to slim down the size of the state to the point where it performs on a third of national income, rather than half (see video, below). Technology will be crucial to driving the necessary efficiencies into government practice - and those with the know-how to make that happen will be able to capitalise on the trend.

Why Google Wave may not make waves after all

Thu, 20 May 2010 07:50:45 +0000

Image via Wikipedia

This week was an important one for the Google Wave team. The company finally removed the invitation-only beta status from the product, meaning that anyone can use it. It also made the feature usable from within Google Apps, whereas it was only previously usable in individual Google accounts. The problem is that it may be a bit too late for this innovative product to make a dent in the way that people communicate.

Google Wave was announced a year ago at the company's I/O developer conference. It promised to revolutionise the way that people talked to each other online. It could be seen as an evolved version of instant messaging, with dramatically improved functionality. People could talk to each other in synchronous real time conversations, but could also revisit these conversations, known as Waves, over time. They could include other people in conversations at any time, and allow those people to replay the conversations chronologically to see how they had developed. People could insert comments at any point in a conversation, and could see each other typing. Waves could be embedded as objects, and accessed in different places.

The problem is that Google didn't do the best job of explaining the service to people, admitted Lars Rasmussen, one of the people who developed Wave. The product was daunting to use in its raw form. Rasmussen said this week that the team had failed to explain in the hour-long demo of the product what people might actually want to do with it.

The other big problem for Wave is one of critical mass. The service is designed to replace email, and it's about time that someone did. The first email was sent 40 years ago, and while it might have worked well then, it hasn't worked very well lately. Spam, excessive CCing, formatting issues, the difficulty of bringing someone into an email conversation that's been going on for a while - all of these problems make it a hindrance rather than a help for many.

But everyone uses email. Unless you're very important to someone, sending them an invitation to a Google Wave that could possibly require them to set up an account before they can even use it is going to be time prohibitive, and will probably mean you don't get a response at all, other than, "just mail me, will you?"

Then there's the availability problem. Yes, Google opened up access to Waves in Google Apps this week, but only in the Premier edition, which means that if you're a small business wanting to get into Wave communications, you'll have to pay for it.

Isn't this a bit backwards? Surely, if you're trying to persuade people to use a product that you've already admitted has been badly marketed and which few of them understand, you're going to want to give them a free ride?

I have a free Google Apps account, and a personal Google account that I use only because there isn't a Google Apps version of Google's Reader RSS aggregator. All of my contacts are in my Google Apps address book, rather than my personal one, and while I live on the Google Apps version of Gmail, I never check my personal Gmail account. I've tried using Wave in the personal version, and it's such a pain to log in and log out again, or to access each account using separate browsers, that I rarely bother.

This leaves enterprise users to take the open source Wave service and run instances of it in their own organisations, but as we know, enteprises tend to be a little conservative, especially in areas such as communication, which are often beset by regulatory constraints.

In short, it's going to take Wave a little longer to get off the ground than Google may have hoped, if indeed it makes it into the mainstream at all. And that's a real shame, because the concept initially showed a lot of promise.

After Office 2010, is Microsoft Open XML becoming useful?

Mon, 17 May 2010 07:53:12 +0000

Microsoft's Open XML standard for Office documents is controversial. Depending on your point of view, it somewhere between a breakthrough in opening up the standard in which the world's most popular office suite saves documents, or a cynical ploy to counter the momentum behind OpenOffice and its rival Open Document XML standard. Amidst all the arguments, it is easy to lose sight of the simple fact that, whatever its merits, Microsoft Office does now save by default in an XML format.

When Office 2007 came out, it was not really sensible to use the new XML formats, such as .docx for Word and .xlsx for Excel, outside the safety of an intranet. If you sent one as an email attachment, there was a good chance the recipient would not be able to read it. Still, now we have Office 2010 and SharePoint 2010, and Open XML has become both more important and less troublesome. It is the only format fully supported by the new Office Web Apps, for example. Further, most of us have had to come to terms with Open XML, at least to the extent that we can open them. Maybe it is time to see if the new formats might actually be useful.

The most obvious advantage of XML is that you can read and write documents using standard XML libraries. There is no need to have Microsoft Office installed, or to try and run it behind the scenes on a web server in order to parse or generate documents. That said, an Open XML document is not a single file akin to an HTML page. Instead, it is a set of related XML files bundled together as a ZIP archive, using another Microsoft standard called the Open Packaging Convention (OPC) If you are curious, you can rename a .docx to .zip, extract the files, and have a look.

If you have in mind to generate Office documents using an XML library, the bad news is that it is not a trivial thing to get right. The good news, at least for .NET developers, is that Microsoft has an Open XML SDK that wraps this complexity. The further bad news though is that the SDK does not free you from having to understand how an Open XML document is put together.

I discovered this for myself after downloading the latest version of the SDK, newly updated for Office 2010. I wanted to investigate how easy it would be to have a web application generate Word documents for download. It turned out to be frustrating. There is what looks like a nice help document with the SDK, including Getting Started articles and a complete reference. Unfortunately, it does not tell the whole story. I was able to generate a simple document in no time, but was soon troubleshooting issues. For example, I found that whitespace at the end of text snippets was getting truncated, so that words ran together, until I figured out that a text element needs the space="preserve" attribute, wrapped by the .NET library as SpaceProcessingModeValues.Preserve. Using styles was also tricky. I followed the supplied article on applying a style to a paragraph, but although I used a standard Word style it was ignored. Styles are no use without a StylesDefinitionPart that contains definitions for the styles you will use.

In the end, the SDK documentation is little more than the famously lengthy Open XML specification, presented as classes and members instead of plain XML. There are few useful code examples.

Open XML is also verbose, and makes you realise how concise HTML is by comparison. You can embolden a word in HTML with a simple element, but in Open XML you have to add a RunProperties element to the Run element that has your text, and then add the Bold element to RunProperties. Microsoft mitigates this verbosity by using very short element names; it is also one of the reasons for using ZIP compression on the final bundle.

It does get better, once you have done your homework on the OPC and Open XML, and created your own wrapper code for the .NET API. There is also a fantastic Productivity Tool included with the SDK, with which you can open and inspect Open XML documents. Its best feature is called Reflect Code, and generates the C# which creates the document you have opened. This means you can get a working example for any document, which can also be used as a starting point for your own document generation. For example, you can set up a document with some dummy text using the styles you need, generate the code, and then amend it to replace the dummy text with your own dynamic content. The only snag is that an innocent-looking and nearly blank Word document includes a large amount of metadata, themes and other stuff, so the generated code is over 2,000 lines long.

Microsoft could do a better job with the SDK documentation, but this is still a powerful tool for parsing and generating documents, and delivers a means of processing Microsoft Office files on the server without Office or SharePoint installed. If you want to know more, the official resource site is here. Finally, a commercial alternative with a more developer-friendly API for both binary and Open XML Office documents is Syncfusion's Essential DocIO; I've not used it but have heard good reports.