I'm at the PNSQC conference this week, and gave a talk where I said pragmatic project managers select a life cycle that manages the big risks for them, so they can pay attention to the other risks. At some point, I said, "If you ever hear:"

• If we could just get the requirements right
• If we could just get the architecture right
• If we could just get the design right
• If we could just get the testing right
• ...

Anything you hear that starts "If we could just" and ends in getting something right means you are not choosing a life cycle that manages the risks you have. That's a project smell.

Some projects are big, risky, complex, scary, whatever. You still have to do them. But you can choose which risks you can allow your life cycle to manage for you.

At the Future of Web Applications conference earlier this month I spoke to Microsoft's corporate VP of the .NET Developer Platform, Scott Guthrie about ASP.NET MVC. Guthrie is a co-inventor of ASP.NET along with Mark Anders, now at Adobe. A few months back I wrote a piece entitled ASP.NET MVC rescues Microsoft's web platform, but I wanted to hear from Guthrie how he sees the framework evolving, and to explore whether it is time to abandon the older Web Forms approach. How does he see the future of the platform?

"The amount of buzz and religious fanaticism about [ASP.NET MVC] is amongst the highest I've been involved in, certainly since .NET 1.0 and Silverlight. Some people prefer the Web Forms model  and I emphasise that Web Forms is not going away, there's all the new stuff that's coming for Web Forms 4.0.

"MVC is an alternative way to do UI and still leverage ASP.NET. For crowds like the one here at FOWA that wants total control over the markup, and who like test-driven development, it's a dream framework. Those folk tend to be more online, so they communicate better which is part of the reason you hear the buzz. I think we'll have more than a million developers using ASP.NET MVC within the first twelve months."

In your talk you mentioned the stackoverflow site which performs very well but runs on not very much in terms of hardware? Is ASP.NET MVC more efficient than Web Forms?

"ASP.NET itself has always been really fast, we've had a lot of success with large sites. One of the things people like about ASP.NET MVC is that the model fits to what they are expecting, for the large LAMP contingent which is heavily represented at this conference.  And when they do the performance testing they say 'Holy cow, this thing is fast.'  Stackoverflow is a great example, written I think within three weeks and scaling to that level with two machines. Performance is a feature, and one of the reasons StackOverflow works as well as it does is that it's instantaneous response time.

"Conchango just did a site, implemented in 20 weeks, a giant ecommerce project, it's 100% ASP.NET MVC. The SEO is phenomenal, the YSlow rating is phenomenal, they're just blown away. It was fun talking to them last night - the guy was jokingly saying, 'I can't believe it works so well'. It's like the best marketing literature in the world times ten. More and more when I give talks I'd say half the people are new to ASP.NET MVC, and the other half come upand say, 'by the way we've done five sites on it.' That's great to hear."

On equivalent hardware and leaving aside different coding styles, is ASP.NET MVC going to scale that bit better than Web Forms?

"No. The reality is you can build hugely scalable sites with each. Where it does help a little bit is that there is smaller page size and there's a bit more control. There's less abstractions."

And the page lifecycle is shorter?

"It is shorter. I don't think that's making any measurable perf difference. It's more that it naturally flows to what they're doing. I do think it's fast, in the same way that web forms can be fast too. But it promotes a certain way of working that, if you know what you're doing, you tend to build really fast apps."

What about the open source aspect? Are people contributing code?

"People are not contributing code directly to ASP.NET MVC, but we're shippling JQuery and we're shipping JQuery validation which are open source projects, and we are integrating them into our code. With JQuery in ASP.NET MVC version 1.0 we just shippped it, whereas in version 2.0 we have helper libraries that are making big usage of it.

"I'd say that's a first for Microsoft, we're actually taking open source software that has multiple contributors, and using it in a deep way within our own product.

"We ship the ASP.NET MVC source code under an OSI Licence. You can take the code, you can modify it, you can do builds. I know a few people that have done customer tweaks, but for the most part it's that people like being able to learn the product through the code. There's also the reassurance of knowing that if they ran into something, they could fix it."

Would you consider accepting community contributions to the code?

"We've thought about it. I think a lot of people interpret open source as 'hey, anyone can just submit stuff'. The reality is that pretty much every open source project has a closed set of contributors. They come from multiple organisations or backgrounds, but you don't check anything into the Linux kernel without Linus or Andrew signing off on the fix. That would be true of ASP.NET MVC, in that there would be a core set of contributors. At some point I think we will probably open it up to let people to contribute code, or at least patches."

What's new in the latest ASP.NET MVC 2.0 preview?

"The ability to easily do forms validation for input, server-side and especially client-side in a very declarative, easy way, is a huge productivity win.

"'Areas' provide a way to take a large project and easily structure it into multiple small projects.

"New form helpers and what we call editor and display templates for customising them  is an innovative way to get strong typing, intellisense and debugging support, and a lot of flexibility in terms of UI generation.

"Asynchronous controllers allow you to call call services on the web, the Twitter, the Facebooks of the world, and  much more efficiently  scale your web server. The classic problem if you're calling Twitter is what's the response time of Twitter? What's the response time of Facebook? Most web servers are multi-threaded so they're processing multiple requests, but say they have 10 threads running and 15 requests come in, and each of those requests need to go and access Twitter, you're going to block 5 people while nothing is going on on the server. With the Async support we provide a way that you within your app can say, I'm going to wait for a while, yield back the thread, and when the data comes back reschedule me. It can dramatically improve the scalability of the site.

"We're doing a bunch of work around helpers for caching, paging, and a other things. In general it's a compatible release, we're trying to listen to the community, keep it a very transparent, Agile-based development process and knock off the top asks.

"We ship the source to every preview, take lots of feedback. That's the other thing people have really liked about the project, this open feedback. They don't feel like we're telling them, here's the way it is, take it or leave it. They like the fact that we've been iterating with them."

Guthrie is diplomatic about the question of Web Forms versus ASP.NET MVC, and even though I pressed him, would not quite agree that it performs much better. Clearly Web Forms is not going away. Take a look though at some of the comments from practitioners like Howard van Rooijen of EMC (formerly Conchango):

One of the great aspects of ASP.NET MVC is how lean and clean the architecture is - there is so little background noise compared to WebForms; possibly the best illustration of this is the difference between the MVC Request Pipeline vs. WebForm Page Lifecycle. The number of hoops you are forced to jump through in WebForms, compared to MVC is quite staggering.

Overall I heard nothing to change my general opinion, that if you can use ASP.NET MVC rather than Web Forms, you probably should.

I meet managers all the time who they they are responsible for other people's work. "It's my job to make sure the work gets done."

Oh, boy. Those managers are wrong. Managers are responsible for:

• Creating an environment in which people can do their best work. This includes deciding which work to do now and which work to postpone or never do.
  
• Providing a system in which people can get and give feedback.
• Building capacity in the organization.

That's it. That's why I say managers manage the system.

Knowledge workers manage themselves. They learn how to break their work down into smaller tasks, so they can make progress. If people don't know how to do that, the manager or colleagues provide feedback, and someone might teach or provide coaching. But it's not the manager's job to manage the people. It's the manager's job to manage the system.

If you're a manager, think hard about the system in which your technical staff work. Are you creating an environment in which people can deliver good work? Can people give and receive feedback? Are you thinking strategically so you can build capacity in the organization?

If you're not a manager, and your manager doesn't know how to do these things, consider coaching the manager. It's likely your manager doesn't realize what his or her job is. Provide a little feedback and a little coaching.

When you think about management, remember that managers manage the system, not the people. The people manage themselves and their work. Just wanted to make that clear.

Mobile devices are today's development battleground. Timing is everything: I recall Borland's 2003 conference when it introduced an extensive mobile development strategy based on the ill-fated C++ BuilderX, with SDKs from Nokia and Symbian. The sessions drew sparse attendance and Borland later abandoned the product, returning to the Windows-oriented C++ Builder.

So what changed? In part, devices have become more powerful and mobile internet access faster and more pervasive, making the platform more attractive. A bigger factor though is Apple's iPhone. In hindsight, the mobile vendors and operators made mobile development too difficult, with fragmented platforms and locked-down devices. Microsoft has had some success extending Windows to mobile devices, for enterprise development in either C++ or .NET, but its market share is too small, the devices insufficiently well liked, and the deployment obstacles too great. Java had some success too, but write-once, run anywhere never really worked for mobile.

Enter iPhone, with a single platform and easy deployment through the App Store. The "easy deployment" part has to be qualified, since developers have been confronted with limited access to the device, restrictions on what they can develop, and an opaque approval process; but it has worked, and the potential of the mobile platform - about which we have known for years - is now being unlocked.

Other vendors are belatedly rising to the challenge. I'm just back from Nokia's Qt Developer Days, and saw the energy the company is putting into creating a cross-platform, open source mobile development framework. Windows Mobile, Maemo and Symbian are on the immediate roadmap. On the deployment side, Nokia has the Ovi store. I've also been at Adobe's MAX in Los Angeles, where broad mobile support for the Flash runtime was the big story. The Flash runtime is not coming to iPhone yet, but Adobe has a native compiler for Flash applications which targets iPhone. Adobe also has app store plans. Google Android is another platform where all the pieces are in place, and Palm Web OS a new hopeful on the scene.

This means developers now have numerous choices for mobile development, as well as more pressure to create or extend applications to embrace mobile clients. It is not an easy choice. An AJAX application will work on the iPhone and elsewhere, but there is no offline support or access to device features, and the capabilities of mobile browsers vary greatly - though Webkit is becoming a standard on non-Windows devices. Native iPhone works great on Apple's device, but nowhere else. Flash is becoming interesting, but devices with 10.1 will not be around until next year and it is an unproven platform in a mobile context. Windows Mobile will trudge on, though Microsoft's mobile story seems particularly incoherent at present and I expect declining market share. Java on mobile has not gone away either; and Google Android is pretty much a Java platform. C++ will always be attractive for lean, fast applications.

It is fun to pick winners and losers, but impossible to tell how all this will shake out. Here's two safe bets. The first is that mobile, internet-connected applications are in many ways the future of the client. The second is that focusing on a strong web services API (of whatever flavour) is the right place to start. What's your mobile strategy?

While the UK economy has always experienced its share of ups and downs, the effects of the recession have undoubtedly led to a significant shift in the way IT workers think of their industry. Results from Computer People's annual IT Salary Review Survey have shown that there is still uncertainty within the industry - however, for those employers that are willing to make a dedicated effort to engage and retain IT workers, there are still opportunities to attract the best talent.

 

The most surprising finding was that over 70% of respondents said that they were considering working abroad in search of perceived increases in job security and opportunity. What's more, even those looking to carry on working in the UK seemed predominantly unsettled in their current role with 92% admitting that they are either actively seeking work or at least keeping an eye on the job market.

 

In addition, a significant proportion of respondents (over 35%) said that they were considering work completely away from the IT industry.

 

What these findings demonstrate is that uncertainty still dominates the UK IT industry; employers are under increased pressure to achieve efficiencies and employees are starting to feel the impact of such pressures and constraints. As a result many are looking abroad or in some cases, deciding they have had enough of the IT industry all together - something which needs to be addressed.  

 

As has been widely reported, the UK has faced an ongoing concern over skills shortages within the IT industry so losing further intellectual capital to other markets is a situation our economy cannot afford, especially as we look ahead to the prospect of economic recovery in the short-term. However, for those as closely involved with shaping and managing employment across the UK economy as we are, these research findings reflect real opportunity as well as highlighting potential concerns.  

 

Employers who are willing to demonstrate a commitment to their employees and a progressive approach to the challenges of today's working environment have the potential to retain and attract the best candidates as they prepare for the upturn.

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