How secure are your networks? Not very, if new data from Symantec is to be believed. The organisation released its April Internet Security Threats Report (ISTR) last week, and the news was not good.

One of the things that the report outlined was a high profile in the targeted attacks on enterprises. Operation Aurora, discovered in January, involved attacks on well over 30 organisations from servers located in China. The attacks were highly sophisticated, and appeared to target companies' intellectual property. Google, which has been most public about the attacks that it suffered, was attacked via a zero-day vulnerability in the Internet Explorer browser (now patched) that enabled attackers to compromise machines. Reports in the New York Times suggest that the attackers stole the source code for Gaia, the search engine giant's single sign-on password system.

This isn't the first targeted attack campaign that we've seen. Last year, researchers at the Information Warfare Monitor, a joint collaboration between security research group SecDev and the University of Toronto, found a targeted botnet called GhostNet, which had been silently stealing information from organisations of particular political interest to the Chinese. This botnet, which consisted of around 12,000 machines, targeted computers including those of the Dalai Llama. Again, the servers controlling the network were largely hosted in the PRC.

Just a couple of weeks ago, working in collaboration with research organisation the Shadowserver Foundation, the same researchers uncovered yet another network, called Shadownet. Again, it targeted enterprises, rather than taking a scattergun approach and targeting computers indiscriminately, as many botnets do.

Things appear to be getting worse for Adobe in terms of security. The organisation, which has had to issue several out of band patches for its products in the past year, is having to cope with an increasing number of attacks against its Portable Document Reader. Most recently, security researcher Didier Stevens found a fundamental design flaw in the Portable Document Format, which attackers could use to manipulate any file into opening another file when launched, and in which a warning dialogue box could be altered, socially engineering the victim into accepting the file.

Attacks targeting companies using flaws such as this show no sign of stopping. What does it mean for IT professionals? It means that a course in ethical hacking (often called penetration testing) or network security could set you on the path to a new career. One of the most acclaimed certifications for pen testers in the UK comes from the Council of Registered Ethical Security Hackers (CREST). The chances are that in an increasingly paranoid industry, professionals certified in something like this are rarely likely to be out of work. 

I've been working with some clients transitioning to agile. The senior managers want to know when the project will be done.

I can understand why they want to know. But before you start a project, you can't know with any certainty! What you can do is use rolling wave planning to know more as you proceed.

The way to use rolling wave planning for agile is this:

1. Lay out the major features you want in a product roadmap. You can organize the product roadmap by week, month, or quarter. I recommend no longer duration than one quarter.
2. Now, create the stories that go with the features in the order in which you want them done.
3. Work with the team to further refine the stories as they plan the first iteration.
   
4. The team completes the first iteration.
5. Now, assuming the team has worked together before, and that the product owner has refined the user stories as much as possible in the previous iteration, the team takes the time to do a gross estimation of all the remaining features in the roadmap. If the team has not worked together before or is new to agile, they need a few more iterations to practice estimating before they can provide a gross estimate that's at all useful.
6. Lay out, on a timeline, approximately when the team thinks they can finish the features, based on the gross estimate.
7. Now, lay out the major milestones (when you will have finished features) on a timeline. Every iteration, you note what you actually completed. When it makes sense, say every 4 weeks, re-estimate the entire backlog, if you need to provide a more accurate estimate. Since you'll be within +/- a few iterations at the beginning, I don't normally suggest you re-estimate all that often in the beginning. But you could.

Now, you have a rolling wave of what you think you can accomplish when. And, you are closing in on a date for your managers.

I've been testing Microsoft's new Office 2010, along with its equally important companion SharePoint 2010, and trying to decide where it lies between brilliance and disaster. It's certainly an improvement on Office 2007. I was relieved to find that Outlook 2010 performs much better than Outlook 2007 did on its first release. Still, the perenniel question with Office is whether you will actually notice the difference, other than a slightly changed colour scheme, as you get on with typing documents in Word and calculating spreadsheets in Excel. While there is the usual laundry list of new features, there's nothing here as dramatic as the switch from menus to the Ribbon in Office 2007.

The real difference lies elsewhere, in how Office is entering the realm of cloud computing. The likes of Google and Salesforce.com have a straightforward proposition: ditch your desktop applications, store everything on our servers, and run your applications in the browser. Microsoft cannot afford to take that line, since Office is its biggest source of income after Windows itself. It has come up with something more nuanced, offering what it hopes are the most beneficial aspects of the cloud without displacing desktop Office.

Therefore we have Office Web Apps, with in-browser creation and editing of Office documents, but still tied to the desktop applications if you need to go beyond basic features. Office Web Apps can live on Microsoft's servers, such as SkyDrive and the recently announced Facebook tie-in docs.com, or on your own servers as a feature of SharePoint 2010. You can use them from various browsers on Windows, Mac and Linux. Suddenly, opening and editing that .docx or .xlsx - these being the controversial Open XML formats - on Linux is not such a problem. I was pleased and surprised by how much the Web Apps improve SharePoint and change the way I use it.

At the same time, as I dug into the Office Web Apps, I found more and more frustrations. The Office Web Apps use the very same formats as desktop Office, but not all their features are available. For example, you cannot insert a new sheet into Excel via the Web App. In fact, there are so many things you cannot do that listing them would take many pages. That doesn't mean the web apps are useless, they are fine for the basics. Microsoft's solution if you need an unavailable feature: just open them in desktop Office. But what if I'm on Linux? Tough.

This same issue leads to problems which are close to being bugs. Let's say I'm in an Internet cafe using a machine that does not have Office installed, you are in the Office, and we are happily collaborating on an Excel spreadsheet - Office Web Apps even lets us edit it simultaneously. The spreadsheet is nearly done, you feel it needs a little jazzing up, and you open it in Excel to add some Word Art. Oops. Not only is the Word Art invisible to me, but I can no longer edit the spreadsheet. Sorry, says Excel Web App. Incompatible features.

It's something that cannot happen in Google Docs, or Adobe's Acrobat.com, where the web application is the only one that you use. I can see this kind of thing causing endless frustration. Note too that you get no warning when editing a document in a way that introduces web app incompatibility.

Office Web Apps is something we did not have before, and you can see it as glass half full, or glass half empty. Personally I expect to use the web apps, and if they help bring an end to the terrible practice of collaborating by emailing documents to all and sundry, I will be grateful.

Nevertheless, as a cloud offering the Office Web Apps are somewhat broken. It will be fascinating to see how this evolves. My guess is that the Web Apps will improve over time, to the point where installing desktop Office becomes unnecessary for many of us. Microsoft may not like the sound of that, but it is better for the company than the alternative, which is not using Office at all. Never bet against the cloud.

Yesterday Microsoft launched a new version of Visual Studio. It's stuffed with new features, has a new shell, and introduces a major new release of the .NET Framework, so there is plenty to take in if you work on Microsoft's platform. In fact, with so many things clamouring for attention it would be easy to give little attention to the brand new language that comes in the package - Microsoft F#. Admittedly the language is not entirely new; it's been around for anyone to try for some time. Nevertheless, it is new to Visual Studio, and giving it the status of a fully-supported language alongside C# and Visual Basic is bound to have an impact.

So why bother with F#? As it happens, I'm writing this from Intel's software conference in Barcelona, where the topic under discussion is parallel programming. We've heard nothing about F# (even in Microsoft's presentation); yet F# is a functional programming language and inherently well-suited to concurrency. One of the key features is that variables are immutable by default, whereas in imperative languages like C# and VB the opposite is true. Immutability makes multi-threaded code much safer.

Here's what F#'s inventor Don Syme told me when I asked him what F# brings to concurrent and asynchronous programming:

There's three things. The first is a real focus on reducing the amount of mutable state in your programming. This means in essence that your mutable state is to be boiled down to the absolute essentials of what has to be mutable. If you do have some mutable state it's local to the user interface thread or local to an agent. But in general you can often completely eliminate the mutable state through this consistent set of functional programming techniques, often by passing some data around explicitly, rather than propagating the data everywhere implicitly by these sort-of global mutable tables. So a focus on immutability first is a major factor.

The second is this Async programming feature which essentially allows you to add lightweight reactions to the system, so you can have many objects waiting to be activated by a callback of some kind, and you can program these objects without doing what's called inversion of control. You can program a series of sequential execution, a series of web requests for example, go to one web site, go to the next web site, go to the next web site and so on, and you can write what we call asynchronous workflows to express this logic which would otherwise be encoded as a set of callbacks all the way through your code. This is extremely important when you're talking about handling errors in a series of asynchronous calls or perhaps accumulating a set of resources across the calls and making sure we clean up file connections and other things that happen during a computational process.

The last thing we bring is an Agent-based programming model built on top of the asynchronous model. This lets you define many hundreds of thousands of agents in memory, in a single process. And this is critical if you're reacting to many different external events such a web crawler having many different i/o requests outstanding at the same time, or processing many different images in parallel.

It's a compelling story; and there are other nice things about F# as well, like the succinct, easy to follow programming style it encourages.

Let me now put this together with a conversation I had yesterday with Intel's Chief Software Evangelist, James Reinders. I asked him about functional programming and he sighed, telling me that yes, languages like F# make parallel programming much easier, but that there was no sign of developers switching to them. In addition, he said, there is so much existing code out there that no functional language can succeed unless it can extend applications written in other languages.

It then struck me how well Microsoft has ticked that box with F#. It is a .NET language, so integrates easily with C# or Visual Basic, and it is presented as a language with which to create libraries for specific tasks, rather than as something you are likely to use for an entire application. It seems to me that it can deliver real value and is well worth exploring.

There's more on F# here; and look out for more from my interview with Don Syme soon.

I recently led a project portfolio management workshop. Before we started, the senior manager had sent me a lovely spreadsheet with all the projects--all 15 of them. I was concerned. I was sure they had more projects based on our earlier conversations. But, ok, maybe they only had 15 projects.

During the workshop, I asked each of the managers to write down all their projects, one to an index card. We would deal with overlapping projects (people in one group working on another group's project) once we got all the cards down.

They started writing. We got to about 55 projects, including the 15 on the original spreadsheet. That's more what I expected.

Now, they started to rank the projects. Every time they had a question about how to staff a project, the senior manager would pick up the card and "worry" it. He waved it around. He flipped it over, side to side. He put it down. He picked it up.

At one point he turned to me and said, "You know, if we didn't have these index cards, I could have ignored this project now, and not have to make these difficult decisions." He paused for a few seconds, and finished with, "But I get paid to make these decisions, don't I?"

He does. And, now he has the tools to make those decisions. One of the tools is making all the work transparent, which is what writing the projects on index cards does. 

Start with index cards (or stickies) whenever you can, to make the work transparent. Then, if you need to, such as if you have a geographically distributed team, move to some form of electronic too. But remember, the tool will always be a second-best tool.

Index cards have a powerful effect on how we think about the work. The power of the index card is in the way it makes the work transparent to you, and in our ability to easily move them around. Use that power to see and manage the work