Microsoft released Windows 8 in October 2012, with its key feature being a new tablet-friendly user interface and store-driven app model, though a slightly improved desktop lives alongside it.

It is not going well. Here is a user comment on Gizmodo that says a lot about the majority reaction to Windows 8:

Im still using a computer with win7 on it, so I had not had much experience with win8. That changed when I helped my girlfriend buy a new computer for her mom. In all honesty, we found the win8 interface a huge pain. It took forever to figure out how to use it, and in the end we did everything we could to get back to a normal non-tile setup. Heck, it takes like 3 menus just to get to the shut down screen! Its insane, and the overall experience for the 3 of us was negative (two of which are very experience computer users).

Spelling and grammar left as-is! Note a few features of this comment:

  • The person who wants the new Windows machine is the parent. I notice this frequently: a significant part of the Windows market is older (I am not saying elderly!) people who are less interested in the latest shiny new thing and more interested in sticking with their existing trusted apps and familiar user interface. The changes in Windows 8 are not welcome to this kind of user.
  • The new features in Windows 8 are perceived as obstructive.
  • There is no mention of touch control or new-style apps. It is a guess, but since the largest market for Windows is low-end laptops without touch screens, it is a fair bet that this is what it was.

The business world is different, of course, and here things like Hyper-V virtualisation or Windows To Go secure deployment are more likely to be appreciated. People are not so different though, whether they are at work or at home, and given that most Windows users spend most of their time on the desktop (hard to avoid however much you like the "Modern UI") I've noticed similar reactions from business people trying out Windows 8.

That is, if they have tried it at all. Most businesses I encounter are sticking with Windows 7.

With PC sales in probably permanent decline, in favour of other computing form factors, is Windows now set to become a legacy workhorse operating system? Will it ever break through on tablets?

Microsoft's official position, as far as I can tell, is that everything is fine. Leaked builds of the next major update, known as Windows Blue, show only minor changes:

  • New 50-50 Snap view for modern apps
  • Easier and richer Start screen customization
  • New tile sizes for the Start screen
  • Internet Explorer 11

Of course there will be more to come; the recently announced Build conference in June is when we will find out more. The stage is set for Blue to be generally available by the end of the year.

I am guessing though that Microsoft does not intend to implement what many users would like, things like:

  • Making the Modern UI easier to ignore, by booting straight to the desktop and having file associations set by default to desktop rather than Metro apps
  • The ability to run Windows Store apps in a desktop window
  • An option to use the old Start menu

I do see Microsoft's thinking here. There is not much point in making a brand new platform, and then designing it so users can easily ignore it.

It is also true that if Windows 8 had simply been like Windows 7, but a bit better, that would have done nothing to stem its decline.

On the other hand, Microsoft's attitude to the problems people have with Windows 8 seems to me denial. More could be done to help desktop (that is, most) users get to grips with Windows 8. For example, I would like to see small visual clues to the presence of menus and "Charms" features (the right-hand menu which hides many settings, search and sharing features), an easier way to raise the Charms menu with the mouse, and a visible Start button on the desktop.

Windows 8 usability is fine if you make the effort to learn it, but making that effort is hard to justify when the world of modern apps is uninspiring. This is the second and most important area that must be improved, if the world is ever going to want versions of Windows beyond 7. There are few delightful apps, and a large part of the reason is that the built-in controls available to developers for building apps tend to be blocky in appearance, inefficient in use of screen space, and short on important features.

Miguel de Icaza, of Mono, Gnome and Xamarin (C# for mobile) fame, said on The Register that "the new Windows basically has no style. The style is DOS with large fonts." A little unfair, but he has a point.

We also need to see further unification of Windows 8 and Windows Phone 8. The phone side does have some momentum now, and the app story is better. Why not enable Phone apps to run on Windows 8, as iPhone apps do on the iPad, as well as making it easier for developers to target both phone and tablet with new projects?

Finally, it is time Microsoft came up with inspiring examples of Windows Store apps that really are a joy to use. There are a few good ones. I still like the weather app, and Fresh Paint is a good effort though sadly has not made me into an artist. More is needed though, and I am guessing that Microsoft's own developers have the same problems that third parties have faced in trying to code for the new platform.

Yes, Microsoft does need to fine-tune the Windows 8 user interface to make it more enjoyable for upgraders; but what is even more important is that Windows "Blue" needs to improve the Windows Runtime platform. That is the thing to watch for at the forthcoming Build.

How to teach our kids to code

March 25, 2013 3:31 PM
Danny Bradbury

How are we doing at teaching our kids how to code? Until relatively recently, the answer was 'not that well'. Hopefully, things will improve now that the UK government has seen fit to include computer science as a key skill. From next January, it will be part of the English Baccalaureate, and will be counted as a science in school league tables. In the long run, the Baccalaureate certificates could replace some GCSEs.

For a long time, kids in the UK were taught ICT, rather than computer science, as a part of the science curriculum. ICT concentrated on teaching kids how to use technology, but didn't necessarily talk about how to understand it. It's one thing to learn how to create a Word document, and move things around in it. It's all very well practicing how to put it in an email attachment and send it to someone. But this is a far cry from understanding the underlying mechanics of technology.

In his book Program or be Programmed, Douglas Rushkoff talks about how, when any important information revolution comes along, power tends to be divided along the lines of those who consume, and those who control. When the alphabet was developed, those in power used it to articulate themselves in writing, while everyone else listened to them read. By the time the printing press was developed, more of the hearers were able to read, but publication was a privilege enjoyed by a select few.

Now, in the digital revolution, Rushkoff suggests that we face the same challenges. We are in danger of creating a nation of workers who use technology without really understanding it, and who therefore can't manipulate it outside of carefully designed parameters.. We can watch countless dogs on tightropes on YouTube, just so long as we're willing to work within the confines of Google's system. We can create Powerpoint presentations, as long as we're happy to accept what Microsoft gives us.

Coders move beyond those confines, and are able to create and manipulate, rather than blindly use. Coders don't have to be content with the same old mousetrap; they can build a better one

Now that computer science has been promoted to a first class citizen, we may see students getting more interested in programming. This will be a major boon to an industry that finds itself perennially short of coding skills.

There's just one problem: we're not starting early enough.

The computer science component that the government is including in the baccalaureate covers GCSEs, making it applicable to teens. What about kids in elementary school, where interests are first realized, and inspiration can take root at an early age?

We need to show children what technology can do at an early stage, rather than leaving it until later, not simply by exposing them to video games but by showing them how to make their own programs. 

The tools for this are already available. MIT produces a wonderful program called Scratch for young children, designed to show them the basics of programming structure through the use of graphical aids. I tested it on my kids, and they were creating a 'play' featuring two separate programming objects within half an hour.

If we don't start our kids early and get them truly fired up about coding, where will our next generation of web designers, coders, and system architects come from?  

I volunteer for the Agile conferences, and have for a number of years. For several years, I was a stage producer, which is similar to a track chair at other conferences. I've been a stage reviewer for several years, and starting two years ago, I was an experience report shepherd. I was even the conference chair for Agile 2009. The conference is near and dear to my heart.

So, this year, when the experience reports stage and the projects, program, and portfolio stage asked me to review for Agile 2013, I said yes. How could I say no? I started reviewing submissions in January, and before I had a client engagement the last week of January, I was caught up. I had reviewed almost everything on both stages.

We were four days away from the end of submissions. I was doing an assessment, which for me is a highly intensive engagement. I barely keep up with email, never mind reviews. And, while we expect many submissions at the end of the submission period, I don't think any of us expected that 70% of the submissions would come in during the last 48 hours.

Yes, you read that correctly. 70% of the submissions came in during the last 48 hours.

We had a goal of providing each submission with a review within one week. Well, we are all volunteers. We all have jobs. How can we provide all of these people with useful feedback when we are slammed?

The great thing about this new submission system is that it emailed me with a timestamp of when the submission was entered. I could use that timestamp and review by new submission. I didn't have to look at the comments people made on their old submissions. I could look at just the new submissions first.

Here's what stood out for me about the people who submitted in the last 48 hours: Many of their submissions were much less coherent and less organized than the people who submitted earlier. Even the people who submitted earlier in the last week. Some people even just put TBD for significant places in their submission. Or "see my blog". I can't review that.

I felt under pressure to review faster. I felt frustrated by my need to live up to the service level agreement of "deliver a review in a week" to each submission. My later reviews are not as empathetic as my earlier reviews. I didn't help people as much as I did earlier.

I learned that the power law distribution, applies to the submissions for a conference, too! If you see the hockey stick as you finish features in iterations, that's the power law distribution at work. Make your stories smaller. Reduce your work in progress. That's what happened to me. My stories were small, but my backlog was humungous.

What will I do going forward? Well, I certainly won't agree to review more than two stages! Will I restrict myself to one stage? I don't know. I love these two stages. The problem is this: I learn from reviewing. This is why I review. How can I turn down such a wonderful opportunity to learn?

I learn from writing. I learn from reviewing. One of the things I got to suggest to other people, and do for my own sessions (face-palm) is use OneStartlingSentence, as a suggestion for their abstracts.

It's hard to write a great abstract. You have to make that first paragraph sing. My colleague last year, Lisamarie Babik, showed me OneStartlingSentence, and I have been trying to use it. Talk about a challenge. You try to write a four-sentence abstract. It's difficult. And when you make it work? Oh, you have a winner!

So I had a chance to practice my coaching skills in my writing. I learned a lot. I made connections with people and asked them to write for agileconnection.com, where I am the technical editor. I learned more about the power distribution law and how it shows up in the most amazing places.

My reviewing is not over, which is why this is an interim retrospective.

If you have a chance to submit a session for any conference, here are my suggestions:

  1. Submit your proposal/abstract early. If not the first week, do it the second. You will get better feedback. Yes, I submitted mine the second week and got great feedback. I was able to get multiple rounds of feedback on all my sessions.
  2. Try OneStartlingSentence as a way to write the first paragraph of the abstract. You can always write more paragraphs if you have room. This will allow you to grab the reviewers. 
  3. If you have a chance to be a reviewer for that conference (or any other conference), grab that chance. You will learn from your reviewing. You will also grow your network, which is a great thing.

One thing I can guarantee. Agile 2013 will be great. At least, the two stages I'm reviewing will be great :-) Not because I'm reviewing them, but because the *teams* of reviewers is doing such a great job. I suspect the other teams are also doing a great job.

Ok, back to my other work and more reviews.
Enhanced by Zemanta

Why Marissa Meyer is right to rein in employees

February 28, 2013 5:00 PM
Danny Bradbury
Marissa Mayer has stirred up a storm this week. People - including business leaders - have criticised the Yahoo CEO for calling employees back into the office - but she's resolute. 

Remote working has been a mantra for tech companies for years now. An awful lot of them sell you the means to do it, either by flogging you tablet devices and smart phones, or by running cutting-edge high-speed commnunications networks, or by developing software that you can use from anywhere in the world. Mobility is the tech world's mantra. So why would a tech firm turn its back on the idea?

Insiders suggest that Yahoo's remote workforce was spinning out of control, with workers routinely hiding, and in some cases practically forgetting that they worked for the firm.

But this doesn't fit with the prevailing rhetoric around remote working. Studies have found remote workers to be more engaged, rather than less. This Harvard Business Review post argues that being close to someone geographically can make you complacent, whereas people who are further apart from each other will often try harder to connect, while using collaboration tools more intelligently. 

Stanford researchers found last year that Chinese workers who worked from home performed an eighth better on average than their office-bound counterparts. That's a significant enough difference that management types should sit up and take notice. 

But the management types are probably the issue. It can be difficult to keep people accountable when they're working remotely. It takes a certain management maturity to keep track of what everyone is doing even when they're not in the office. Mid-level managers have to understand how to set goals to accomodate remote working, rather than simply relying on time-based billing.

If a company lets remote working practices run away from it without keeping its eye on these management goals, then it risks plummeting productivity, a lack of cohesion, and, ultimately, a loss of identity. Things will fall apart. The centre will not hold.

More than that, employees need to feel an emotional affiliation with their employer to be self-motivated. They need to feel as though they're working for an organisation that's going somewhere, and that has a solid vision. They will want an organisation that they can get behind. That's something that Yahoo lacked for a long time, and which was already affecting employee morale.

So perhaps Meyer is doing the right thing, in spite of employee whinging. She's taking a legacy of many disaffected, listless employees, and sifting the wheat from the chaff. Once she's completed that task, and the hangers-on have resigned of their own accord without incurring an expensive redundancy package, she can focus on building up a cohesive culture with those who are left - and then open up remote working and collaboration again, on her terms. 

Smart move, I'd say.

How life emulates code

February 25, 2013 9:00 AM
Danny Bradbury
I'm starting to code again. 

I hadn't typed a variable name or defined an object in years, but the other week, I remembered how much I loved it. I used to code in PHP, but this time, I sparked up a Linux VM and started to learn Python. I hadn't even entered a BASH command for a while, so I'm relearning everything from the beginning. 

I found myself painfully tapping commands into the Geany graphical editor, saving .PY scripts, and running them to see what happened, only to get the inevitable syntax errors and warnings. For the inexperienced, coding is a frustrating series of stops and starts, like turning over an engine that doesn't want to go. 

It's delightful too, when a script finally sputters to life and does what you wanted. Mine processed an HTML file, finding domain names and converting them to IP addresses. When it was finished, it ran smoothly, churning out hundreds of lines of beautifully formatted results and saving them off to another file.

It ran smoothly, but it used far too much fuel. The best way to learn a language is to go over what you've just done and try to make it more elegant. I began refining it, looking for better commands to do more with fewer lines. 

I gradually reduced the code, like a good sauce, consolidating commands, replacing five instructions where one carefully thought-out one would do. Any good programmer's ultimate goal isn't just to do something, but to do it well. There is such a thing as beautiful code - although mine will still be ugly for a while to come. 

That's ok. Writing embarrassingly bad Python scripts is a hobby. Lord knows, no one would pay me for it, and most people are far better at it. 

Luckily, writing posts like this is my day job. That relies on 'real' language, with a far more forgiving syntax. But as the Python interpreter kept telling me where I'd gone wrong, I realised that software code and real life language are intimately linked.

We build our realities through language. The agreements that we declare with people - our loved ones, our clients, our business partners, and ourselves - dictate what comes next. A poorly-worded or incomplete communication leaves things open to interpretation, and often leaves people with the wrong idea.

What happens then? Arguments develop. Feelings get hurt. People are left with different expectations, which can be explosive further down the line. I've had business partnerships - and the friendships underpinning them - collapse because I didn't know enough to code them properly. We have to code our lives properly. We have to make every word of our language count.

So, what does proper coding look like when we communicate with each other, rather than with a software engine? It means being clear, concise, and - to quote Don Miguel Ruiz - impeccable with your word. That last part is important. Being impeccable with your word involves using positive language to describe the way you want things to be, rather than negative language that sets you up for failure. It also means following through with your stated intentions. People respect others who explain exactly what they're going to do, and why, and then do what they say. 

Being impeccable with your word requires a careful, elegant use of language. Using language as a tool requires that we keep it sharply honed. Just because the syntax of the English language is broader than our software languages doesn't mean that we shouldn't be measured, elegant, and deft with our words. Wasting less time and energy on expletives and cliches lets us concentrate on meaning and structure. It enables us to better program our world, and our place within it.   

French mathematician Blaise Pascal summed it up best in a letter he once wrote: "I have made this longer than usual," he said, "because I have not had time to make it shorter."

Smart chap. No wonder they named a programming language after him.
Enhanced by Zemanta

January was a dark month for Github. The collaborative source code management site was found to be sharing the private SSH keys of many members via its public search function.

The website, which helps programmers in far-flung locations to collaborate with each other, had just upgraded its search function with many new features. However, this caused several enterprising hackers to take another look at its search functionality.

Git hub works using a series of repositories. These are folders that hold the source code for software that a developer is working on as part of a collaborative project. A private repository on a developer's own machine is replicated with a public one on the Git hub site, enabling that developer to work on their own version of a piece of source code, before it is then incorporated into the main source code along with everyone else's changes.

Unfortunately, it turns out that many developers are not very conscientious when it comes to security. They copied over the entire contents of their UNIX machines' home directories into their private repositories, which were then copied up to the public folders. By default, UNIX stores SSH keys in the home folder.

SSH is a certificate system designed to make it easier to access remote computing services without continually re-entering passwords. When a user generates SSH keys on their own computers (which can be done with a single command line instruction), it creates a private and public key. The public key can be given to servers that the user wants to access transparently via different tools on their computer. The private key is supposed to stay with them, and never be distributed. 

If these private keys are made public, then an attacker has the keys to the kingdom, because they can access any online services that the user is logging into. What makes it worse is that the user's computer also keeps a list of these services on their machine in a 'known hosts' file.

So, until Github recognised what was happening, links to people's private SSH keys were popping up in its search results. This could have had far reaching ramifications. Developers' machines may already have been compromised without their knowledge. Their Github accounts could have been accessed, and malicious backdoor code could even have been inserted into their project code.

But who was at fault here? Was it Github, for making the search results available, or was it the developers themselves, for not understanding security well enough to protect their own private keys?

And if developers are making rookie security mistakes such as this, how much should we be trusting them to produce secure software?

Developer conferences are a great way to re-energise yourself and your work with new ideas, partly thanks to the content from the front, and partly because you get to engage with other developers. Technology changes constantly; but if I reflect on events I have attended I notice some common themes. Occasionally there are compelling technical insights - I think of the first time I heard Ryan Dahl describe the thinking behind Node.js, for example - but more often the most acclaimed talks are not about technology as such. Rather, they are about how we work together: communication, and simple truths about human nature.

This proved the case again at the Monki Gras recently, an unusual London event run by analysts Redmonk.

Craig Kersteins and Matt Thompson from Heroku asked a question: how often are you interrupted at work? Software development is partly about keeping a lot of information in your head so that you can see patterns and make connections, and avoid bugs by remembering exactly how the code you are working on fits into the application. Getting a summons to a meeting or a call from a colleague in the midst of that kind of concentration is costly. They even put a figure on it. 76% of the worst-performing engineers are frequently interrupted, they said.

How often is frequent? That was not stated; but they did suggest aiming for 4 hours of uninterrupted work each day. That still leaves plenty of time for meetings; and I have little doubt that 4 hours of good work counts for more than 8 hours of choppy work that leaves you feeling that you should not have bothered to turn up.

More human factors: Mazz Mosley and Nick Stenning from the UK Government Digital Service advised us not to recruit "rock star" developers who become a single point of failure, as everything stops if they become unavailable. A team with collective intelligence is better.

Ted Nyman from GitHub weighed into managers. They do not have any. I was reminded of a comment from Joyent's Bryan Cantrill at Monki Gras 2012: "it is very hard for middle management to add value".

Do I think that most companies remove all their managers? That is neither realistic nor likely to succeed. As another attendee observed, companies with managers generate a lot of revenue.

The point though is this: the way developers are managed impacts their productivity. That human factor matters more than whether they use Java or C#, or which tools they use.

I hear similar insights from the QCon conference in London each year. Coming up in March and recommended.

Shanley Kane from Basho spoke about honesty in software development. Roadmaps are a lie, she claims, because attempts to map features to a timeline will always fail. When roadmaps fail that erodes trust in the team. Interactive "what we're working on" documents work better, she said.

I will leave the last word to Cyndi Mitchell from Logscape and Thoughtworks, who remarked at Monki Gras that "Software is fundamentally a human, interactive activity. If you don't understand that, forget it."

When outsourcing goes too far

January 28, 2013 10:17 AM
Danny Bradbury

Ready to outsource your development job to China? One guy was doing it for months, and only got caught because he was lazy.

Verizon's security team just released a bizarre case study, describing a company that approached it after seeing some strange network traffic. It was experiencing a VPN connection from China, for no reason, which often stayed up for a day at a time. Even weirder was the fact that the person at the other end of the VPN connection was using two-factor authentication to check into the account.

While investigating the problem, the security team decided to trawl the hard drive of the account's legitimate owner, an employee inside the company. They were looking for malware that may have been planted by an attack. Instead, they found dozens of invoices from Shenyang, China. It turned out that the employee, a software developer for the company, had been outsourcing pretty much all of his job to low-cost labour on the other side of the Pacific. They were able to access the system because he had Fedexed his RSA token to them. 

The developer, who was paid a six-figure salary, was paying a fifth of what he earned to the overseas contractor. That's smart if you're someone who wants to get your job done for your while still earning a hefty salary. It's smart if you don't care about ethics, or security, or the wellbeing of your employer or the broader community that they serve. 

It's also incredibly insecure. Many security attacks have been documented as coming from China. If someone else is accessing your systems and writing your code, then they will also have carte blanche access to your infrastructure, and potentially elements of the infrastructure beyond. This company was also part of the critical national infrastructure, said Verizon. Suddenly, stories of cyberattacks on oil and gas infrastructure and malware planted in the electricity grid seem far more plausible.  

What's irritating isn't just the guy's irresponsible actions; it's the fact that he wasn't even doing anything productive with his time. The Verizon team's blog on the subject outlined his average day thus:

9:00 a.m. - Arrive and surf Reddit for a couple of hours. Watch cat videos

11:30 a.m. - Take lunch

1:00 p.m. - Ebay time.

2:00 - ish p.m Facebook updates - LinkedIn

4:30 p.m. - End of day update e-mail to management (ironically, he got consistently excellent performance reports). 

5:00 p.m. - Go home

He was also lazy enough to have the Chinese works connect directly with their VPN, rather than running a proxy at his house and having them connect to it first. That's what got him caught - thankfully for the company concerned, which presumably would now want to audit its internal network and pull a full static analysis of its code, to see if there are any security holes.

This is the darker side of the extraction theory proposed in Tim Ferris's book The Four Hour Work Week. In that book, he advocates distancing yourself from your company and working from home where possible, so that you can be more efficient with your time and start your own lifestyle business. He also suggests using a virtual assistant to take on mundane tasks. It seems our enterprising developer skipped the lifestyle business part, and just got someone else to do his job. 

Or perhaps this was his version of a lifestyle business. The Verizon team said that evidence suggests he was pulling the same scam in multiple companies.

There are most certainly things you can do to make your job easier as a sysadmin or software developer. I know of one tech expert who took a job as a sysadmin for a US company, demanded to work from home, and then scripted 80% of his tasks. His job ran smoothly, there were no security risks, and he was free to get on with other things. But that takes real smarts. 

Lessons learned here? For companies: watch your system logs more closely (this had been going on for over six months). For employees: sure, work efficiently, do what you can to automate your job and make it easier - but never, ever step away from your work ethic or basic trustworthiness.


Could 2013 be the year that RIM recovers and BlackBerry becomes an important mobile platform again? January 30th is the key day, when the new BlackBerry 10 smartphone platform is launched.

We have seen a kind of preview of BlackBerry 10 in the unsuccessful PlayBook tablet, released in April 2011. This is the first RIM product based on the QNX operating system. QNX Software Systems was acquired by RIM a year earlier, in April 2010. That said, the PlayBook runs the PlayBook OS, not (yet) BlackBerry 10. BlackBerry 10 SmartPhones will have a new user interface and many new features.

I spoke to William Vablais, Head of Developer Relations EMEA for RIM. "We've been very successful in changing the sentiment of developers," he claims. "The interest level has been rising significantly."

One would expect him to say nothing less. But what is distinctive about the BlackBerry 10 platform; what does the it give you that couldn't easily be done on iOS, Android or something else?

Vablais points first to the diversity of development approaches it supports.

"We have SDKs for C/C++, we have entry points for designers and developers for HTML and CSS, we have entry points for Adobe AIR," he says.

There is also an Android runtime which makes it possible to repackage Android apps. Vablais observes that it can pay to offer your app on a minority platform.

"There's a community out there that developed for Android who don't have any exposure or visibility in that world because it's such an overcrowded market," he says. "They can take their application, port it to our platform, and suddenly they get visibility, generating revenue."

Fair enough, but what does the BlackBerry 10 platform give you that cannot easily be done on some other platform?

Vablais points to two key BlackBerry 10 features that he believes will draw users to the platform. One is social netwok integration. "We have the social network capabilities built into the OS," he says, referring to BlackBerry Flow and BlackBerry Hub:

BlackBerry® Flow is a new user experience that allows seamless navigation across open applications and the BlackBerry® Hub. All messages, notifications, feeds, and calendar events come into the BlackBerry Hub and no matter what the user is doing with the device, with a simple gesture, they can peek into the Hub at any time.

says the press release,

More important to business users though is security. "What no-one else has is that the OS and the framework has been based on security. The user interface and some of the components allow you to split out work related data from your personal related data."

This is the feature called BlackBerry Balance. Again, here is the official description:

BlackBerry® Balance™ offers the most elegant way to satisfy both customer and corporate needs without compromising on either. With BlackBerry Balance, personal apps and information are kept separate from work data, and the customer can switch from their personal to work profile with a simple gesture.  The work profile is fully encrypted and secure, enabling organizations to protect their content and applications, while at the same time letting customers get the most out of their smartphone for their personal use.

In the era of BYOD (Bring Your Own Device), this does sound like a great feature. The industry is only just coming to terms with the idea that smart devices are personal; they do not live in the office and they will be used as home as well as at work. If BlackBerry 10 makes sense of maintaining work and personal data on a single device without compromising security or the user experience, then it could indeed be a game changer.

The success of the original BlackBerry phones was primarily based on its appeal to business users, and RIM already has tools for deploying internal apps in a managed and secure manner.

Even an excellent platform counts for nothing if you cannot market it successfully in a world now dominated by iOS and Android, as Microsoft has discovered with Windows Phone. Whether RIM has enough resources to establish yet another mobile ecosystem must be an open question.

At the same time, there is a lot to like. QNX has long been an excellent embedded operating system, and if the devices are excellent and the security lives up to its promise, BlackBerry 10 could be a significant platform for mobile buisiness apps.

Mark January 30th in your diaries and watch with interest.
 

Do we live in a 'brogramming' culture?

December 10, 2012 5:13 AM
Danny Bradbury
Do we live in a 'brogramming' culture? A few weeks ago, a row exploded over the cancelling of a UK Ruby programming conference, Britruby. The lineup for the Manchester-based conference was criticised by another conference organiser for its 100% white male lineup. The online discussion quickly escalated, resulting the cancellation of the conference, for what the organiser said were financial reasons.

The whole affair left many disappointed, and regretful, and it also raised a simple question: should the organisers have included a specific mandate to invite a percentage of women and people of colour to speak at the conference? There are some noted Ruby programmers who fall outside the white male category after all. 

This blog post from Avdi Grimm, a speaker scheduled to speak at the conference, suggests that the people he asks who are not white or male were not invited.

Grimm also attended at least one other conference with a diverse set of speakers.

"Does encouraging diversity actually make a difference to the quality of a conference?" he asks. "My answer, based on that experience, is oh hell yes."

The signs are that we need diversity in our skill set when it comes to programming. The European Commission says that Europe will have a skills gap of up to 700,000 professionals within the next two years. 

And yet, in the UK, we're training relatively few women in IT. According to statistics from the UK's Higher Education Statistics Agency, 3465 women received undergraduate qualifications for computer science in 2010/11. 4.5 times as many males qualified.

Encouraging more women into undergraduate computer courses could help by bumping up numbers, but that's also going to take considerable time. There's also evidence that traditional academic courses aren't necessarily producing the kinds of skills necessary to excel at IT jobs in the real world.

Can we short-circuit the process, encouraging under-represented groups into IT jobs even when a person doesn't have an academic record in the sciences?

The Hackbright Academy thinks so. It is offering a relatively short, ten-week programming course exclusively for women to help introduce more gender balance into computing. Women learn a range of solid computing topics including Python, Git and source control, SQL, and front-end web subjects including HTML, CSS, Ajax and WebSockets.

Becoming an expert in these technologies in ten weeks is a tall order, but it could give women who haven't been involved in IT enough of a grounding to at least secure a commercial job where they could develop a subset of those skills further - and graduates from the course are already getting hired.

Could an active policy of diversity in IT professionals, combined with short, sharp kickstarter courses in specific skills, help to redress some of the skills shortages in IT?

Current Vacancies from CWJobs

(* Required field)










Preferred format