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.

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 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.

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.

So you need a new Windows application. You fire up Visual Studio, but which project type do you select? Windows Forms application, or WPF application?

Windows Presentation Foundation was introduced at the same time as Windows Vista, with final code released in November 2006 as part of .NET Framework 3.0. It was designed to replace existing Windows graphics APIs such as GDI and GDI+ with a more powerful, flexible and scaleable framework for buiding a graphical user interface, taking advantage of DirectX hardware acceleration and rich graphical effects. If Vista had proceeeded as originally planned, it would probably have been deeply baked into Windows itself, but in the end took a lesser role, presumably for performance reasons. Microsoft also added Windows XP support to make WPF more attractive to developers.

Another goal was to improve designer/developer workflow. WPF uses XAML, a declarative XML language, and is amenable to manipulation through a visual design tool. Microsoft released Expression Blend and Expression Design, which export XAML, as well as supporting WPF in Visual Studio.

Developing a Windows GUI can be frustrating. If you have ever wrestled with dialog units or the impact of "small" vs "large" fonts, you will know how badly scaling is handled. WPF is a huge improvement, with sensible layout management as well as great support for multimedia and effects.

Nevertheless, WPF was slow to take off. Issues included the large memory footprint of a WPF application, deployment of the latest .NET runtime, and lack of pre-built components; in fact, for a long time Microsoft itself advised against using WPF for line of business applications.

There was another factor too. Long-term Microsoft platform users have learned to be cautious about any technology that is not much used within Microsoft itself. WPF was a great example, with little obvious use beyond the Expression tools themselves. In this context, it was fascinating the hear the talk from Principal Software Engineer Paul Harrington at PDC in November, about how Visual Studio 2010 has been rebuilt with WPF. Harrington's team has an advantage over most of us, in that they can press the WPF team to fix bugs and make changes, and that is exactly what happened. Visual Studio needed to use invisible windows for some operations; WPF did not support that, but now now in version 4.0 it does. The text rendering in the new editor was making some developers feel physically ill, apparently, because of its blurry appearance on some systems, so a new text stack was built, enabled by turning off ClearType. The Visual Studio team ran into problems with focus and activation, and new modes have now been added to WPF to fix them.

My guess is that the stress-testing of the Visual Studio team combined with other improvements in WPF, such as new business-oriented components, will make it the sensible choice for a Windows GUI application, other things being equal (which they never are), once Visual Studio 2010 is released.

The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway. WPF has good support for new Windows 7 features, for example. But Microsoft is also releasing Silverlight 4.0, which has considerable compatibility with WPF but runs on the Mac as well as on Windows, is easier to deploy, and which fits with the web model for data handling. Silverlight 4.0 now has COM support on Windows, when run out of the browser, which means you can add native code if you really need to, and integrate with other applications such as Microsoft Office.

In some curious way then, WPF is maturing to become an excellent development framework at just the wrong moment. Nevertheless, I'd now think twice before hitting the Windows Forms option on a new application.

If you want to know how to estimate without using time units, here's how I do it:

For my work, I block out half-day chunks of time. I find that I can do some tasks in that half-day chunk (1, 2, or 3), and finish enough on any one thing that I can safely mark it as done enough and go on to the next task.

Some days, I have tons of little things to do: return calls, make lists, prepare to do something. Some days I have larger tasks: write a blog entry, draft a workshop, write a ton of email. Some days I have quite large tasks: draft 1 of a piece of a chapter, draft 1 of an article, draft 1 of a report.

Most weeks, I have a mix of things that are small, medium, and large. I no longer worry or estimate how long any of these things will take. I know about how many of the small, medium, and large tasks I can finish in a week. I can make my lists taking that into account.

If you are a developer or tester or BA or technical writer or a whatever (don't want to leave anyone out :-), you can do the same thing. Here's my recipe:

1. Make sure you've taken any task larger than a half-day chunk and broken it down into smaller tasks. That's why you see draft 1's for articles. I can write a draft in less than a half-day. I can't finish all the editing and have a great article at the end of a half-day. So, I don't try to do so.
2. Be clear on what done means for a particular task. If you don't know what done means, you can't get there. You'll either "finish" without getting to a reasonable stopping point and then you worry, or you can't finish in less than a half-day chunk.
3. Do just that one task until it's done. Commit to it. Finish it.
   

Now you have a little recipe for getting the tasks done. Here's how you apply it to your estimation. When someone asks how long something will take, you look at all your little tasks. Make sure they small, medium, or large, where large still fits in a half-day. You get no more than 10 half-days in a week. How many of these tasks can you do in a week? Add them up, and there you have your estimation without having to define how many hours a given task is.

If you're part of a project team, and want to try this on a larger scale, I particularly like the Fibonacci series (1, 2, 3, 5, 8, 13, 20) for estimating how large and complex a task is. As a team, use a Delphi approach (everyone gets together and as a group agrees on a number. For me, and when I teach my estimation workshop, any task larger than a 13 means "we have no clue and 20 is as good a number as any other number." When you hear someone is a specialist and can finish something earlier,  take the larger of the two values.

Other folks use t-shirt sizing: XS, S, M, L, XL, 2XL, 3XL. I don't like that as much, because, in my experience, teams don't learn to break tasks down enough, and have too many M, L, XL tasks. YMMV.

Now, it doesn't matter if you work in iterations or not. Take a week. As a group, ask "How many of these tasks can we do in a week?" Discuss the question. Arrive at a number you can all live with. You're done!

Remember that estimates are guesses. They are likely to be wrong, especially if you use time-based units. That's because we are either optimists or pessimists and because we never have ideal hours, days, or weeks. Try this and see what happens to your estimations.

I've been traveling, at three conferences in three weeks. At some point during these weeks, a few people asked me, "What's the difference between a technical lead and a first line manager?" Given their job descriptions, which include helping people manage their careers, seems to me that the answer is $10,000-$20,000. That is, the technical lead was being paid less, but doing the same work as a manager.

Ok, maybe I'm being a little cynical. Wouldn't be the first time today :-) But, I don't think anyone is restricted from being a technical leader. That person doesn't have to manage people or help them manage their careers. My opinion is that anyone who is responsible for results generate by other people is some kind of manager.

But a technical leader, is in Jerry Weinberg's words, "Leadership is the process of creating an environment in which everyone feels empowered", from Becoming a Technical Leader.

The people I spoke with did that. They also did many other kinds of work, including leading design/architecture work, which is what many of them thought the tech lead job was. But if you think about creating an environment, you can see that if you facilitate a decision, you're a technical leader. If you make it easier to ask for support or help, you're a technical leader. If you ask for whiteboards or chairs or some other tool, and that tool makes it easier for people to work and collaborate, you are a technical leader.

I wish organizations would stop using the term "tech lead" to stop paying first line managers what they are worth. I wish more people would exercise their technical leadership muscles.

Just remember, it doesn't matter what they call you, you can be a technical leader.

I'm not a fan of multitasking. There are plenty of studies that show that multitasking slows you down (links at the end). But you may not know what to do instead of multitasking. Here are some ideas:

1. Take a few minutes and write down everything you need to do. Part of speeding up is to make conscious decisions about what work to do when. If you are ever surprised by a particular piece of work, make sure you collect all the work somewhere, written down. I like to write everything down on a list on a legal tablet, just to make sure I have it all. I don't recommend stickies, unless you post them all on a wall and then transcribe them to a piece of paper. You want to make sure your list doesn't vanish onto the floor. Index cards are good because you can shuffle them, if you need to.
   
2. Now, what's your first thing to do? If you have six #1 priorities, either have a discussion with your manager in a one-on-one, or decide. I usually decide, because it's easier to ask forgiveness later than permission before.
3. Now you can do some work. For each piece of work, is it a task? If so, fine. Make sure you break your tasks down into very small chunks. You want to get to the point where, if you have five minutes, you can accomplish something, even if it's not very much. You want to finish something so you don't have to remember where you were on that task.
4. If the work is not a task but a small project, what's the first thing you need to do? How long will that take?
   

My rule of thumb is to use inch-pebbles or tasks that are even smaller, to make headway. You want to get to the point where you are in a wait state on a project so that you can move to another project, do some work on that, get to a completion/wait state there. The more wait states you get to, the more options you have as to what to do next. That's what allows you to speed up and not multitask.

Whatever you do, don't multitask. If you don't believe me, here are some links about the uselessness of multitasking: http://www.umich.edu/~bcalab/multitasking.html

In addition, here's a recent article discussing how people who think they are good at multitasking actually are not:
http://news.bbc.co.uk/2/hi/8219212.stm

More about multitasking: http://idiacomputing.com/moin/ContextSwitching

If you're part of an agile team or a manager, or in a technical leadership position, or you work with people, you'll be in a position to coach at some point.

When you start thinking about coaching, remember this:

Coaching is offering options with support

Coaching is not just teaching. Sometimes, coaching is listening, sometimes it's offering an example, sometimes it's helping other people see that there are other options. Once you get past sports coaching, coaching is much more than teaching.

So, how do you offer options with support? Consider these ways:

1. Help the other person see that there are at least three alternatives for each problem. There are more, but three is the minimum. Once you get past the third option, it's easy to generate more options for the solution.
2. Help the person work through the results/consequences of each choice.
3. Suggest a timebox in which to try the solution and see what happens.

These are all supporting actions.

Here's how I did this once as a manager. I managed a sharp guy who asked our management embarrassing-to-them questions at all-hands meetings. My manager told me I needed to fire him. I said no, that I would give him feedback and see if he wanted coaching. When he said he wanted coaching, and that he wanted coaching from me, I first asked, "Can you see three alternatives to how you ask questions now?"

He replied, "Well, I could quit going to the meetings." I asked, "Will that work for you?" "Not really." "Ok, that's one option, but it's not the best one. What's another option?"

"I could write down my questions at the meeting, and ask you later." I agreed that might work. I asked, "How frustrated do you think you might be by not asking questions right then and there?" "Very!" "Ok, so that's another option. Can you think of a third alternative?"

"I could sit next to you and whisper my question in your ear and you can tell me whether it's ok to ask." I agreed I would do that, as long as we would discuss why I said no to some questions at our next one-on-one. He agreed.

There were probably other options, but that one worked well for us for several months. I wouldn't say my colleague is the most tactful guy now, but he has a better idea of what works in public and what doesn't work.

Helping him think through the alternatives was a much better idea than telling him what to do or not to do. When it's time for you to coach, help the other person consider multiple options and support that person through the thinking and doing.

I've been mulling over the implications of the news that Sun's JRuby team leaders, Charles Nutter and Thomas Enebo, are leaving Sun because of uncertainty about the future of their project after the Oracle acquisition. They will be joining Rails specialist Engine Yard. This is the key quote from Nutter:

To be honest, we had no evidence that Oracle wouldn't support JRuby, but we also didn't have any evidence that they would.

JRuby is by all accounts excellent - I'm aware that developers at ThoughtWorks use it, and Ruby advocate Martin Fowler (who works there) told me that it works very well for them, observing that some enterprises who would be reluctant to deploy the native Ruby runtime are more comfortable with running Ruby applications on the JVM (Java Virtual Machine). It is foolish of Oracle to let the JRuby guys slip away, particularly bearing in mind the trend towards dynamic languages (like Ruby) rather than static-typed languages (like Java).

What does this suggest about the future of Java itself under Oracle's stewardship? If Oracle could have done more to reassure Nutter of its continuing commitment to JRuby, so too it could do more to reassure the rest of us that investment in Java and its community will continue as strongly under Oracle as it did under Sun. Maybe it will, maybe it won't; though culturally I suspect the new company will be averse to Sun's habit of investing heavily in projects with little obvious potential for direct revenue. The failure to monetize Java fully, along with the failure of its bold experiment in open source, is one reason for the acquisition itself.

That does not imply that Java will go away - Oracle itself is a heavy user, and defending its future was likely a factor in its willingness to purchase Sun. Still, it would not be surprising if the community is a little less warm, and Oracle's investments more focused on its own needs rather than those of the wider platform.

Despite Oracle, there is no reason to be gloomy about Java's future. There is another way to look at the move of the JRuby team, which is that they've found a way to continue working on the project with or without Oracle's support. Java is bigger than Oracle, just as it was bigger than Sun. 

IBM worked tirelessly to free Java as far as possible from Sun's control, developing its own JVM and creating the Eclipse tools project to foster alternative tools and frameworks. Those efforts will have a new context and relevance.

Maybe Oracle will do great things for the Java platform. Maybe it will do little, and momentum will shift to those outside the home company. Either way, investment in Java development is as safe as anything can be in our uncertain industry.