Well, Apple's iPad was something of a letdown, wasn't it? The most anticipated product since the iPhone launched onto the global stage not with a bang, nor with a whimper, but with what can only be described as an embarrassed shuffle.

You could tell that things were starting to go awry even as Steve Jobs sat down in the comfy chair onstage to carry out the demo. He was scrolling happily through several web pages, blissfully ignoring the fact that the first one he went to - the New York Times - simply didn't work as it was intended. Why? Because apparently, just like its smaller brother, the iPad doesn't support Adobe Flash.



Tim Anderson wrote recently about the need to develop for the mobile Internet. Mobile search and location-based services will drive the mobile web. Mobile advertising has been growing slower than expected -- recently, research firm EMarketer anticipated a $1.1 billion spend by 2012. The financial downturn has slowed developments, but the potential for mobile Internet revenues is staring us in the face, nevertheless.

This is why Jobs' demo last Wednesday is so significant. The iPad is flawed in many respects. It has no camera. There are no standard ports on the thing. It costs more than many net books, and yet its operating system is locked down. But one of the biggest flaws is that without Flash, many of the sites that we would like to visit are not available.

Such is Adobe's chagrin that its platform evangelist Lee Brimelow published a list of websites including Google Finance, Disney, CNN, popular American media streaming site Hulu, and Facebook application Farmville. None of them were without Flash, meaning that none of them will work on the iPad.

Apple's decision to eschew Flash on the iPhone was irritating enough for Adobe, but to do it on a tablet device that Apple hopes will replace the laptop for many consumers sitting on the couch in the evenings is no less than a declaration of war. Adobe needs to promote itself in new markets like this one, where everything is at stake, and Apple is making it very difficult.

Adobe definitely has cause to worry. Apple's share of the mobile market is only 2.7%, according to research firm Strategy Analytics. On the other hand, it sold 99.4% of all mobile applications last year. People buying Apple's mobile devices use them in ways that users of other mobile platforms do not, and Adobe will be well aware of this, as will Microsoft, which offers the competing Silverlight technology.

And looming on the horizon is a potential game changer: HTML 5. This as-yet unratified technology is nevertheless being supported in its unratified perform in many browsers. It is vastly more functional than HTML 4. Web developers can display video using it, without having to resort to Flash. They can produce HTML-only pages that enable you to drag and drop anything, and edit any content. This is why Google Wave, the search engine giant's revolutionary new online messaging system, was built in HTML 5. It looks and feels like a desktop application.

HTML 5 cannot claim to do as much as Flash can, but it may do enough. Apple, which itself likes to dominate all aspects of its business, doesn't like it when other companies like Adobe dominate a single part of the online experience. What Jobs may have been imagining when he scrawled through that broken site last week was a world in which it used HTML 5 -- and in which Adobe was increasingly irrelevant.

What does that mean for IT professionals and web developers today? It means that understanding HTML 5 as it develops, and honing your skills in this exciting new technology, might not be a bad bet. As this new decade rolls on, you will find it looking more and more attractive on your CV.

Few assumptions are safe in the IT industry. A few years back, it was obvious that that PCs running Windows were beating the Apple Mac into a tiny niche. Things look different now. If you planned your IT strategy on the earlier assumption and have not changed, you are now getting it wrong.

Another not entirely unrelated area is the significance of the mobile web. Mobile phones have had web browsers for as long as anyone can remember; but for most of that time actually using them has been frustrating and slow. Remember trying to scroll a tiny window around some web page broken by non-functioning Javascript or CSS, looking for a critical piece of information such as an address or schedule?

In consequence, the extent of mobile browsing was small and mainly focused on niche areas like travel.

It all changed with the iPhone. Those contracts are expensive, but once you buy in you generally get an unlimited data connection, and more important, a decent browser which is a version of Safari, built with WebKit. That same engine is now used in many other devices, not least those running Google Android. Suddenly, users do want to use their mobiles to browse the web; and they will be hitting your web site or application and trying to use it.

Check your stats. I run another blog at itwriting.com, and when a reader complained about its appearance on a mobile, I added a wordpress plugin which both fixes the layout and reports the traffic. According to the plugin, 5% of the traffic was from mobile users. Once the site was fixed, the figure grew dramatically, to over 15%.

A tech news blog is just the sort of thing that appeals to mobile users, so those figures will not apply in every case. The point though is this: all those assumptions about limited mobile usage which once seemed safe now no longer apply.

Here's another line I often hear. There's no need to optimise your site for mobile, since the more advanced mobile browsers work fine with normal web sites.

Unfortunately that is not the case. They work much better than older ones, true. However, the displays are very much smaller and the connection speed often much slower than on the desktop. If you want your site to be a pleasant experience for mobile users, you will likely have to deliver customised content for them.

Does everyone get this anyway? If you have a few spare minutes, head over to mobiReady and try out a few sites; or download the Android emulator; or of course use a real device to test sites that you are involved in or interested in. I did so before writing this piece, discovering that the web still looks very broken once you go beyond the top sites.

The positive spin on this is that optimising for mobile can be a relatively easy way to gain commercial advantage.

Talking of safe assumptions, one that seems good right now is that the number of web-connected mobile devices is going to grow rapidly in the coming years. Optimising for mobile was always the right thing to do. Now it is essential.

 

It's good to talk, or so the saying goes. So, why aren't candidates for IT jobs talking to their recruiters, and vice versa? Recent survey statistics suggest that the two factions aren't on the same page when it comes to job requirements -- and that it is creating a skills gap.

The data, which came from a survey of 1560 IT professionals and 38 recruiters by CWJobs.co.uk, found a marked lack of communication between recruiters and candidates. That's going to hurt everyone, including the clients, in the long run.

The problem, according to recruiters, is that job candidates don't have the skills that they need. But job candidates feel that the recruiters are not very good at explaining what they want. 59.6% of candidates said that employers are not clear enough about the skills they expect when recruiting for technology roles. And, surprise surprise, 65.8% of recruiters felt that candidates are not clear enough about the skills they have when they apply to jobs.

This is leading to a mismatch in skills. Six out of 10 employers want C# skills, according to the survey, but 74% of technology professionals said that it wasn't an integral skill in the current market. 84.5% of them also said that ASP.NET wasn't an important requirement, and yet half of all recruiters want it.

So, in addition to some better communication skills, there clearly needs to be some retraining. IT professionals say that they need to retrain in SQL, .NET, Java, Oracle, and Linux. Recruiters said that SQL, .NET, and Java will be important skills over the next one to two years, in addition to C#, and PHP (which still didn't feature highly on job candidates' lists).

One interesting snippet is that recruiters cited soft skills such as business acumen and understanding user requirements as an important skill in the future. Perhaps this would also enable job candidates to communicate their skill sets more effectively. But recruiters need to do the same, and learn how to articulate what they want.

This is something we clearly need to fix. This IT skills gap has arrived just at the point when the economy is beginning to recover (if the Bank of England is to be believed). Companies are starting to invest in new projects, and will need the technical expertise to implement them. The jobs are apparently waiting to be filled, but the whole situation is like a bad date; although each party is looking for someone else to be with, they can't seem to hit it off, because they are not on the same wavelength.

Every project needs a project vision: the reason the team is working on this project.

When you define the project's value early in the project, the more the project team is likely to tell you whether the project makes sense--or whether you're starting an impossible project. If you can't articulate the vision, chances are good that you're starting on an impossible project, because there's no way to end a project with no vision. A useful vision is compelling to the project team. And it helps the team make decisions about what's in or out of the project.

Here's how you create the project vision:

    1.    Define who the primary customers of the project are. They could be the mass market, existing customers, new customers, or a specific market segment.
    2.    Define the one major focus of the project. This could be a specific feature, or the general approach. If you're new to agile and you're starting a pilot project, you might want to say, "Use agile techniques to see how to adapt them here." A project doesn't focus on five things; it focuses on one overall vision. If your project requirements are too broad to encompass in one vision statement, maybe your project is really a program.  A project has one deliverable. A program has one overall deliverable and is composed of sub-projects, each of which has a deliverable.
    3.    Write as much as you need to, and then edit until you're down to two to four sentences. If your vision is longer than four sentences, you haven't described the project focus yet.

Here's how I do this. With the project team, we decide who the primary customers of the project are. Now, if I know the major focus, I explain it. Otherwise we try to define it together. Now, as individuals, we write our sentences, on stickies. We post them on the wall, and read them out loud, seeing which sentences make sense. We choose sentences and edit. Once we're down to no more than 4 sentences, we are done.

If you're on a project without a vision, stop right now. Take 30 minutes, define it, and get back to the project work. The whole team will benefit, as will your customers.

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.

I teach project management and estimation workshops. Every time I teach estimation, someone asks, "How can we get the perfect estimate?"

You can't. Estimates are guesses. And, if you are multitasking, every estimate you have is wrong. Guaranteed.

But you still need to figure out when things will be done. Instead of estimating how long a task will take, I prefer to estimate how many small things I can complete in a week. And, I make sure I get to done on each task before I take on another task.

One of the problems of estimating large tasks is that we tend to estimate in units that are too large. If you estimate in weeks, you'll be off by weeks. In days, you'll be off by days. In hours, you'll be off by hours. Over the course of a project, even estimating in hours can obscure the actual duration remaining for the project.

Instead of using scope as the base, I use a timebox. Instead of asking, "How long will this take?" I ask, "What are all the small tasks required to complete this piece of scope?" Then I see how many of those will fit into a week.

If you're working with other people, and are using a Delphi method for estimation, you'll discuss your estimate. You'll hear things like "If Danny does it, it's only a 3. If I do it, it's a 5." I always take the upper estimate. Why? Because if Danny is so good, he's not going to be available. He'll have questions to answer or some other task that's a higher priority. I'll do it anyway. And, if I practice doing these tasks I'm not so good at now, I'll get better pretty quickly.

Think hard about whether you want a good estimate or if you want the work done. Estimating at the beginning of the project is often a waste of time. The more work you get done, the better your remaining estimate will be. 

I attended Microsoft's Professional Developers Conference last month, with one of my goals being to learn more about Azure, the company's cloud computing platform. I have been meaning to write a post on the subject for some time, but it did not come together until this week, when I listenened to Marc Benioff expounding the Salesforce.com version of cloud computing.

Benioff is ebullient and outspoken; a contrast to Microsoft's Ray Ozzie who gave the Azure keynote at the PDC and conveyed little excitement. Of course, it's easier to be ebullient when your company is growing at 20% per year; but another factor is that the Saleforce.com vision is easier to articulate. Throw out your servers, says Benioff, and move everything to the cloud, that is, to us.

In reality Salesforce.com has a significant integration story, so you can have your on-premise applications talk to your cloud applications, but it is not something Benioff talks about much. Why should he? His company profits when you migrate stuff to his platform; the integration piece is merely an enabler.

Microsoft by contrast makes its money from on-premise software. Its internet services lose money, according to its own accounts. It also has a vast partner infrastructure that is sustained by installing and maintaining its products.

Still, Microsoft knows that it has to do cloud, because the economic benefits to its customers are unavoidable, and because any IT company without a cloud strategy will be punished by the financial markets. In consequence, there is an array of consumer services under the Live brand, and an emerging platform of enterprise services under the Azure brand.

Azure is Windows server in the cloud. You get SQL Server; you get IIS; you get ASP.NET; and it is all pay-as-you-go. So is Microsoft suggesting that we throw out our servers? Considering the profitability of its server division, that would be madness; and indeed, the PDC presented mixed messages about the company's cloud strategy.

This was brought home to me by a session I attended on Bridging On-Premise and the Cloud, given by Windows Azure Distinguised Engineer Yousef Khalidi. Cloud computing, said Khalidi, is a "style of computing with dynamically scalable and virtualized resources provided as a service through the network ... this definition doesn't even say if it has to be on the internet or not. It's a way to think about how an application is structured to fit in a cloud-like model."

Khalidi went on to describe a "spectrum" of computing platforms, from the traditional server or datacenter to private and then public clouds. The forthcoming AppFabric Server will make it easier to run cloud-like applications (according to the definition above) on your internal network, with the option to move it to Azure later should you so desire. "Our strategy, our basic thesis guys, is that there are benefits across the whole spectrum and we'll continue to support the whole spectrum," he said.

The snag is that co-ordinating cloud and on-premise gets complicated, as a glance at one of his slides illustrates.

Well, computing is a complex business and I can understand the appeal of this model to Microsoft-platform companies that require some specific benefit, like pay-as-you-do scalability. As an overall proposition though, it is less attractive than the kind of thing Benioff talks about; it can feel like adding complexity rather than reducing it.

Another issue with Azure is that while it lifts much of the IT administrator's burden, it does little to speed development. You still have to write the code, test it, debug it, deploy it, maintain it. Saleforce.com on the other hand is not only a multi-tenant platform, it is a multi-tenant application. If you are lucky, a little bit of customisation is all you need.

You might not be lucky. You might end up having to write mountains of non-portable code in Apex, the Force.com language. You might run into limitations of the platform, like its difficulty with long-running data processing operations that can interfere with the responsiveness of the system. Salesforce.com is also an expensive platform, with per-user per-month fees for ever.

Still, at least Benioff has a coherent story. I'm not sure that Microsoft does.

The latest news is that Microsoft has re-organized Azure into a new Server & Cloud Division. So now the internal division that has most to lose if Azure succeeds is running the whole show. Technically that makes sense; but the marketing message is going to be even harder to articulate.

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'm just back from Microsoft's Professional Developers Conference in Los Angeles, where the star of the show was the latest update to the Silverlight browser plug-in that lets you run .NET applications cross-platform and within the browser. The pace of development is remarkable. It is only 9 months ago that we were first shown the beta of Silverlight 3, at the Mix conference in March. Silverlight 3 was fully released in July; and now we have version 4.0 beta, with release promised for the first half of 2010.

It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.

In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.

Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.

The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.

Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.

I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.

What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.

The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.

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.