BYOD can be easy with tablets

The "bring your own device" movement has caused quite a bit of heartburn among the corporate IT and security folks. More than is necessary, I think.

For those unfamiliar with the term "bring your own devices" (BYOD), it means this: employees select their own devices, bring them to the office, and use them for work. Such a notion causes panic for IT. It upsets the well-balanced apple cart of company-supplied PCs and laptops. Corporations have invested in large efforts to minimize the costs (purchase costs and support costs) of PCs and laptops. If employees were allowed to bring their own hardware, the following would happen (in the thinking of the corporate cost-minimizers):

• Lots of employees would have problems connecting to the company network, therefore they would call the help desk and drive up support costs
• Employee-selected hardware would vary from the corporate standard, increase the number of hardware and software combinations, and drive up support costs

And in the minds of IT security:

• Employee-selected hardware would be vulnerable to viruses and other malware, allowing such things behind the corporate firewall

But these ideas are caused by misconceptions. The first is that employees want to bring their own PCs (or laptops). But employees don't. (Or at least not the folks with whom I have spoken.) Employees want to bring cell phones and tablets, not laptops and certainly not desktop PCs.

The second misconception is that smartphones and tablets are the same as PCs, except smaller. This is also false. Yes, smartphones and tablets have processors and memory and operating systems, just like PCs (and mainframes, if you want to get technical). But we use tablets and smartphones differently than we use PCs and laptops.

We use laptops and PCs as members of a network with shared resources. These laptops and PCs are granted access to various network resources (printers, NAS units, databases, etc.) based on the membership of the PC (or laptop) within a domain and the membership of the logged-in user of domain-controlled groups. The membership of the PC within a domain gives it certain privileges, and these privileges can create vectors for malware.

Smartphones and tablets are different. We don't make them members of a domain. They are much closer to a browser on a home PC, used for shopping or online banking. My bank allows me to sign on, view balances, pay bills, and request information, all without being part of their domain or their security network.

How is this possible? I'm sure that banks (and other companies) have security policies that specify that only corporate-owned equipment can be connected to the corporate-owned network. I'm also sure that they have lots of customers, some of whom have infected PCs. Yet I can connect to their computers with my non-approved, non-certified, non-domained laptop and perform work.

The arrangement works because my PC is never directly connected to their network, and my work is limited to the capabilities of the banking web pages. Once I sign in, I have a limited set of possibilities, not the entire member-of-a-network smorgasbord.

We should think of smartphones and tablets as devices that can run apps, not as small PCs that are members of a domain. Let the devices run apps that connect to back-end servers; let those servers offer a limited set of functions. In other words, convert all business applications to smartphone apps.

I recognize that changing the current (large) suite of business applications to smartphone apps is a daunting task. Lots of applications have been architected for large, multi-window screens. Many business processes assume that uses can store files on their own PCs. Moving these applications and processes to smartphone apps (or tablet apps) requires thought, planning, and expertise. It is a large job, larger than installing "mobile device management" packages and added new layers of security bureaucracy for mobile devices.

A large job, yet a necessary one. Going the route of "device management" locks us into the existing architecture of domain-controlled devices. In the current scheme, all new devices and innovations must be added to the model of centralized security.

Better to keep security through user authentication and isolate corporate hardware from the user hardware. Moving applications and business processes to tablet apps, separating the business task from the underlying hardware, gives us flexibility and freedom to move to other devices in the future.

And that is how we can get to "bring your own device".

The Microsoft Surface is an Office tablet

People compare Microsoft's Surface tablet to Apple's iPad. Some favor the Surface, others favor the iPad. But this is a false comparison.

Both the Surface and iPad are tablets. But they serve two different markets. The iPad is designed for consumers; the Surface is designed for businessmen.

The iPad is easy to use. It has lots of games and consumer-oriented apps. One can play music, read books, and play games. One can get apps for banking, for reminders, and for adjusting photographs. But it doesn't have apps for the workhorses of today's office: the Microsoft Office programs.

The Surface is designed for the office. It comes with 'home' versions of the Microsoft Office products, and 'real' versions are promised. (I suspect that the difference is mostly one of licenses.)

The Surface is less a general tablet and more a "tablet for running Office". It also happens to run other programs, but don't let that fool you. It's primary purpose is to be the tablet platform for MS Office. The innards of Windows RT use a number of old Microsoft technologies -- just the things needed to run the Microsoft Office suite.

As a specialized tablet, I expect that MS Office and the MS Surface will grow in parallel. New versions of MS Office will take advantage of new features in Windows RT and Surface tablets. Enhancements to tablets will be designed to support new versions of MS Office.

Heck, using this logic, Windows RT is simply a platform on which to run MS Office. It is an "Office operating system".

Tablet fever? Take two tablets and call me in the morning

Microsoft announced their first tablet offerings, and the response has been positive. Enough people have submitted orders for the low-end model to sell out.

This shows two things:

First, it puts Microsoft in the top tier for the tablet market, and shows that people take Microsoft seriously. A number of manufacturers have produced tablets (Motorola, Acer, Dell, and even HP) the sales of non-Apple tablets have been tepid. By providing a tablet that sells out (even before it is for sale), Microsoft joins Apple and Google in the ranks of "suppliers of desired devices".

Second, that the interest in tablets is not an Apple phenomenon. Apple fanboys may lead the way for iPad sell-outs, but they had nothing to do with the Microsoft Surface sales. That interest is coming from a different part of the market.

Perhaps I am putting too much weight on this one event. It may be that Microsoft produced a small number of the low-end Surface tablets (the higher-end Surface tablets are still available). It may be that people are buying the Surface tablets as an experiment, or for corporate pilot projects, and the initial demand is higher than the "true market".

People (rightfully) point out the failures of Microsoft's phones, Zune, and Kin offerings. But those products never gained traction in the market, and none sold out -- much less prior to shipping.

There is interest in the Microsoft Surface tablets, and I believe all tablets. Apple and Microsoft get a lot of attention from brand recognition. Google does too, when it ships devices.

I think we are about to undergo a case of "tablet fever", with tablets becoming the most desired device. It should make for an interesting ride.

No more PCs for me

This week I decided to never buy a PC again. I currently have four, plus a laptop. They will be enough for me to transition to the new world of tablets and virtual servers.

This is almost a bittersweet moment. I was there prior to the PC, when the Apple II and the Radio Shack TRS-80 were dominant (and my favorite, the Heathkit H-89 was ignored). I was there at the beginning of the PC age, when IBM introduced the PC (the model 5150) and everyone absolutely had to have them. PCs were the new thing, a rebel force against the established (IBM) mainframes and batch processing and centralized control. I resented IBM's power in the market.

I saw the rise of the PC clones, first the Compaq and later, everyone. I saw IBM's attempt to re-define the standard with the PS/2 and the market's reaction (buy into Compaq and other PC clones).

I saw the rise of Windows, and the change from command-line programs to GUI programs.

Now, I have seen the (Microsoft Windows) PC become the established computer, complete with centralized control. The new rebel force uses tablets and virtual servers.

I am uncomfortable with Apple's power over app suppliers for iOS devices, and Microsoft's power over app suppliers for Windows RT devices. I am leery of Google's power, although the Android ecosystem is a bit more open that iOS and Windows RT.

Yet I am swept along with the changes. I use an Android tablet in the morning, to check Facebook, Twitter, and news sites. (A Viewsonic gTablet, which received poor reviews for it's non-standard interface, yet I am coming to like it.) I use an Android smartphone during the day. I use a different Android tablet in the evening. (Although I am typing this on my Lenovo laptop with a Matias USB keyboard.) While I have not moved everything to the tablets, I have moved a lot and I expect to switch completely within a few months.

My existing PCs have been converted to the server version of Ubuntu Linux, with the one exception of a PC running Windows 7. I suspect that I will never convert that PC to Windows 8, but instead let it die with dignity.

I was there at the beginning, and I am here at the end. (Of the PC age.) Oh, I recognize that desktop and laptop PCs will be with us for a while, just as mainframes stayed with us. But the Cool New Stuff will be on tablets, not on PCs.

Unstoppable cannon balls and immovable posts

There is an old riddle: what happens when an unstoppable cannon ball strikes an immovable post?

The unstoppable cannon ball is a hypothetical construct. It is a cannon ball that, once in motion, stays in motion. (It's ability to defy friction comes from its hypothetical nature.)

The immovable post is also a hypothetical construct. It is a post that, once placed, cannot be moved.

While the riddle is entertaining, a real-world version of it is emerging with software development methodologies. Instead of an unstoppable cannon ball and an immovable post we have the waterfall methodology and the agile methodology. Perhaps the agile method is the equivalent of the cannon ball, as both emphasize motion. It doesn't really matter, though.

What matters is that the two methodologies are incompatible. One can develop software using one methodology, or the other, but one cannot use both. For small shops that have only one project (say a start-up), this is not an issue. Larger shops (any shop with multiple projects) must choose a methodology; you cannot use waterfall for some projects and agile methods for another. (Well, you can, provided that the two sets of projects have no interaction. But that is unlikely.)

The waterfall and the agile methods make two different promises. Waterfall promises a specific deliverable, with a specific set of features, and a specific quality, on a specific date. Agile promises that the product is always shippable (that is, very high quality), and promises to implement the most important features first, but makes no promises about a complete set of features on a specific date.

It is easy to dismiss these differences if we think of these approaches as methods of developing software. It is harder to dismiss them when we realize the truth: waterfall and agile are not methods for building software but philosophies for managing projects.

Managing projects is serious business, and is the core of most IT shops. (Projects can by managed by non-IT shops, too, but I will stick with the IT world.)

One cannot run a business (a successful business) with multiple coordinated projects that use project practices which differ to the extent that waterfall and agile differ. Waterfall, with its "big design up front" and locked-in delivery dates cannot mesh with agile, with its "choose as you go" method for selecting features. The rise of agile methods -- agile project management -- means that companies must choose one or the other. Which one is important, too, and depends on how the managers of the company want to run their company.

This schism has far-reaching effects. It can be felt in the acquisition of other companies, when one merges the management of project teams. It affects the hiring of new employees: are they familiar with the practices of the hiring company? It can even affect joint projects between companies.

I don't claim that one is better than the other. My preference is for agile project management, based on my experience and projects. It may be the right methodology for you. Or waterfall may be the better methodology for you. Managers must evaluate both and consider the benefits and costs.

My advice is to learn about both and make an informed decision.

How I fix old code: I use the wisdom of those before me

I am often called in to a project to improve the code -- to make it more efficient, or more maintainable.  It seems that some programmers write code that is difficult to understand. (And luckily for me, a large number of them.)

I use the maxims provided by Kernighan and Plauger in their book "The Elements of Programming Style". Written in the 1970s, it contains wisdom that can be used by programmers today.

One of my favorites (possibly because so many programmers do not follow it) is "Each function should do one thing well."

Actually, Kernighan and Plauger wrote "Each module should do one thing well"; I am taking a (reasonable, in my mind) liberty to focus on functions. With today's object-oriented programming languages, the meaning of "module" is somewhat vague. Does it refer to the class (data, member functions, and all?) or does it refer to a separate compiled file (which may contain a single class, multiple classes, a portion of a class, or all three)? But such questions are distractions.

When I write code, I strive to make each function simple and easy to understand. I try to build functions of limited size. When I find that I have written a long function, I re-factor it into a set of smaller functions.

But these techniques are not used by all programmers. I have encountered no small number of programs which contain unreadable code. Some programs have large functions. Some programs have poor names of variables and functions. Some programs have complicated interactions between functions and data, otherwise known as "shared mutable state". It is these programs that I can improve.

Many times, I find that the earlier programmers have done a lot of the work for me, by organizing the code into reasonable chunks that just happen to be grouped into a single function. This makes it easy for me to create smaller functions, each doing one thing well.

I do more than reduce functions to maintainable sizes. I also move functions to their proper class. I find many functions have been placed in improper classes. Moving them to the right class makes the code simpler.

How does one know the proper class? I use this rule: When the function modifies data, the class that holds the data is the class that should hold the function. (In other words, only class functions can modify class data. Functions in cannot modify data in other classes.)

Functions that do not modify data but only read data belong to the class that holds the data.

If a function reads data from two classes, it is most likely doing too much and should be re-factored. If a function is changing data in two classes, it is definitely doing too much, and should definitely be re-factored. (These rules are for direct access of data. I have no problem with functions that invoke methods on multiple objects to retrieve or modify their data.)

These two simple rules ("each function should do one thing well" and "each function in its proper class"), give me guidance for most of my improvements. They have served me well.

I succeed because I simplify code. I simplify code by using not my own rules, but the maxims laid out by those who came before me.

The return of thin client for desktops, brought to you by zero-configuration

Some time ago, the notion of a "thin client" for desktop computers (mostly Windows PCs, as this was before the rise of Apple) got some attention but little traction. The "thin client" applications of the time evolved into "web applications" and people kept their desktop applications as "thick client" apps.

We may see the return of "thin client" apps for desktop computers, combined with a return of "zero-configuration" applications. Apple's iOS manages apps with close to zero configuration, as does Android and Windows RT. Apps are easy to install -- so easy that non-technical people can purchase and install apps. The experience is a far cry from the experience of the typical Windows install program, which asks for locations, menu groups, and possibly registration codes.

The success of smartphones and tablets is also due to the managed environment. Apps on smartphones have less control than their desktop PC counterparts. An app on a smartphone responds to a select set of events and the operating system can shut down the app at any time (say to allocate memory to a different app). On the PC (Windows, Mac, or Linux), the application once running has control and "takes over" the computer until it decides that it has finished. (Yes, all modern operating systems can shut down applications, but in general the operating system attempts to keep the program running.)

Will we see a managed environment for desktop PCs? Such an environment would be a program running on the computer that performs the same tasks as iOS, Android, and Windows RT. It would allow apps to be "installed" in its environment (not on the native OS) and these apps would respond to events just as smartphones apps respond to events.

Who would create such a product (and ecosystem)?

Well, not Apple. Apple has nothing to gain by extending iOS apps to the Mac OSX (or Windows) desktop. Nor do they gain with a new (competing) environment.

And I suspect not Google. Google also has nothing to gain by extending Android to the desktop.

Microsoft? In a sense, they already have built an app ecosystem for Windows: their recent Windows 8 product. It runs apps in "Windows New UI" mode and classic applications in "Windows 7" mode. But I'm not thinking about Windows 8, I'm thinking of a different environment, possibly an Android simulator or something new.

Canonical, the providers of Ubuntu Linux, are working on their "Unity" interface and they may change Linux from an application-based system to an app-based system, but that doesn't get anything onto Mac OSX or Windows desktops.

To be sure, such an effort has challenges and uncertain payoffs. The product is a combination of virtual machine, environment manager, and distribution network. Beyond the software, one has to create the ecosystem of developers and users; no small task now that Apple, Android, Microsoft, RIM/Blackberry, and Amazon.com/Kindle have started such efforts.

Yet it could be possible, for the right players. I see them as HP and VMware. The former has WebOS, a platform that had decent acceptance at the technical level. The latter has the technology for virtual machines and a good reputation. I could see a joint project to create an app environment, with each partner contributing. Add Salesforce.com with its development environment, and one could have a powerful combination.