Software subscriptions

One of our current debates is the change from traditional, PC-installed software to web-based software.

Even Microsoft is switching. Microsoft in addition to its classic PC software "Office 2013" which is installed on your local PC, now offers the subscription package "Office 365".

It's a big change, and many folks are concerned. System admins worry about the new procedures for signing up with new software services. Managers fret that an update could change file formats, and locally stored documents in old formats may become unreadable. Ordinary users find the concept of renting, not owning, their software a bit disconcerting. A few folks are aghast to learn that their software could disappear after failing to pay for the subscription, and have railed against the increased cost and the greed of software vendors.

Yes, I know that software is usually licensed and not sold. But most folks think of current PC software as sold, regardless of the licensing agreement. It is this general understanding that I consider to be important.

Let's run a thought experiment. Suppose technology was going in the other direction. What if, instead of starting with purchased software and moving to subscriptions, we were starting with subscriptions and moving to purchased software?

In that change, people would be complaining, of course. Users would be hesitant to move from the comfort and convenience of subscription software to the strange new world of installed software. System admin types would grumble about the additional work of installing software and applying updates. Managers would fret about compatibility, fearing that some users would have old versions of software and might be unable to share files. Ordinary users might find the concept of "owning" software a bit disconcerting. I suspect that a lot of people would be aghast to learn that they would have to pay for each device they used, and rail against the increased cost and the greed of software vendors.

Such a thought experiment shows that the change from ownership to rental is big, but perhaps not a bad thing. The decision between PC-installed software and web-based software subscriptions (or mobile/cloud subscriptions) is similar to the decision to own a house or rent a condominium. Both have advantages, and drawbacks.

My advice is to experiment with this new model. Start using web-based e-mail, word processing, and spreadsheets. Try the file-sharing services of SkyDrive, Google Drive, and DropBox. Learn how they work. Learn how your organization and use them. Then you can decide which is the better method for your team.

Adapt or die

Nothing says "we're a big company" like the sentence "Only resumes in WORD format will be accepted". The use of passive voice is strongly correlated to bureaucracy, as is the imperious capital letters for a (perhaps not-so-humble) product.

Demanding a single format is also arrogant. First, it says that you have a certain way of doing business, and that you are unwilling to change. Second, it says that you expect everyone else to conform to your way, regardless of their procedures or technology.

I suspect that many of these companies are using this approach from inertia. In the past, when Windows and Microsoft Office dominated the market, one could reasonably expect everyone else to use the same tools.

Times have changed. Microsoft Office is still popular, and common in corporations. Especially so for large corporations. But it is not universal. People and companies (especially start-ups) use other software and other formats. Local, desktop software now includes Open Office and Office Libre. Apple iWork is available. Google Docs (now named 'Google Drive') lets you compose and edit documents, spreadsheets, and presentations. Other formats include HTML, XML, and TeX.

Demanding a single format is so 1990.


Interestingly, firms that recruit for tech positions are some of the worst offenders. While I have seen none that ask for a facsimile, most ask for resumes in Microsoft Word format - and only that format. A small percentage deign to accept PDF.

This limitation strikes me as, well, limiting. Why accept only the one format?

I can think of two reasons.

First, a single format simplifies archiving. People can point to older word processor formats (Wordstar, Wordperfect) and claim that documents in these formats are no longer readable. They are right -- those formats are unreadable by modern-day word processors.

But the next version of Microsoft Word will (most likely) drop support for the old ".doc" format. When that happens, all of their old (non .docx) Word files will be unreadable, too.

The second reason for using a single format is for simpler internal procedures. If everyone in an organization uses the same format, then the organization can standardize on a single word processor, which reduces outlays for software and time for training.

But the extension of this internal standard to external communications seems unwise. It makes other jump through your hoops, which is at best discourteous. It may irritate your customers or candidates, or worse, drive them away. Do you want to lose business over a file format?

Tech recruiters look especially bad when they do this. It changes their image from "with it" to "stodgy" and "technically capable" to "technically limited". Demanding an old format (such as the soon-to-be-dropped ".doc" format) makes on look behind the times.

If I were a technical recruiting or staffing company, I would want the best candidates for the jobs available, not just those candidates that can jump through arbitrary hoops. (Although that may be exactly what some client companies desire.) I would want to demonstrate flexibility and adaptability to candidates and clients.

Think about your internal standards and your external interactions. Do you adapt to the world, or do you expect the world to adapt to you?

Losing data in the cloud of big data

NoSQL databases have several advantages over traditional SQL databases -- in certain situations. I think most folks agree that NoSQL databases are better for some tasks, and SQL databases are better in others. And most discussions about Big Data agree that NoSQL is the tool for Big Data databases.

One aspect that I have not seen discussed is auditing. That is, knowing that we have all of the data we expect to have. Traditional data processing systems (accounting, insurance, banking, etc.) have lots of checks in place to ensure that all transactions are processed and none are lost.

These checks and audits were put in place over a long time. I suspect that each error, when detected, was reviewed and a check was added to prevent such errors, or at least detect them early.

Do we have these checks in our Big Data databases? Is it even possible to build the checks for accountability? Big Data is, by definition, big. Bigger than normal, and bigger than one can conveniently inventory. Big Data can also contain things that are not always auditable. We have the techniques to check bank accounts, but how can we check something non-numeric such as photographs, tweets, and Facebook posts?

On the other hand, there may be risks from losing data, or subsets of data. Incomplete datasets may contain bias, a problem for sampling and projections. How can you trust your data if you don't have the checks in place?

No help for mobile apps

A big change from PC application to mobile app is the 'help' feature. Not the addition of the feature, but the removal of it.

"Help" is a distinguishing characteristic of PC and Mac applications. All modern applications have it, and most have the dual-mode 'general' help and 'context' help. The Microsoft guidelines for well-behaved Windows applications specify the "Help" menu and the "About" information. (Possibly because Apple's specifications for well-behaved Macintosh applications specify them.)

The concept of on-line help precedes Windows and Mac software. The venerable Wordstar program offered help (on-line help) in its menu configuration. Unix has provided the 'man' utility for decades.

Yet look at any mobile app and you will see no help feature. It is not a menu option. It is not a button or a hidden screen.

Apps for smart phones and tablets do not have help. And they don't need it.

This is a big change.

I can think of a few reasons that mobile apps have dropped the 'help' feature:

Single-screen focus PC help is designed for multi-window displays. Mobile apps are designed to display on the whole screen. iOS and Android enforce this; Windows RT allows for two apps to display but not an app and its help screen. When the app takes the screen, there is no room for help messages. Switching from the main app to the help app might be too much of an inconvenience.

No example There is no reference app that uses help. All of the apps run without help, and new apps copy the designs of the existing apps.

Simplicity of operation Mobile apps are designed to be simple. So simple that help is not needed. The user can operate the software without the help of help.

Of these reasons, I prefer the last. Toggling between an app and a help screen is awkward but possible. Allocating a portion of the screen to help is also possible; many apps allocate space to advertisements.

I like to think that mobile apps need no help because they are easy to use. This easy comes in two forms: ease of operations and ease of understanding the concepts. Services such as Twitter and Facebook provide easy-to-use apps that manipulate a relatively simple set of data. The concepts they use are easy to grasp.

If this is the reason, then we have an interesting aspect of mobile apps: they must be simple enough that they can be used by the average person with no help. That is, there is an upper bound on the complexity of the app. Photoshop and Visual Studio will never be mobile apps, at least not in their current forms.

As applications migrate from desktop to web to mobile, they must become simpler. (Web apps, like mobile apps, have dropped the 'help' feature.) If my theory is correct, then we should see the mobile versions of apps like Microsoft Word and Excel existing as simpler versions of their desktop PC counterparts.

I keep saying 'simpler', but that should not mean 'less powerful'. We may see some reduction in capabilities, but I suspect the big changes will be to the user interface and the techniques we use to manipulate data.

After BYOD comes BYOO

Folks are concentrating on the "bring your own device" (BYOD) change in the workplace. I'm looking ahead, to a possible next change: "bring your own office" or BYOO.

The idea of BYOD is simple: Instead of companies supplying computing equipment to employees, employees purchase equipment. Instead of supplying employees with iPads, for example, let employees purchase their own tablets (iPads, Android, or Windows) and provide them access to the needed data and apps.

BYOD is one of a number of changes that shift responsibility from employer to employee. Other changes include company-funded pensions (replaced with employee-funded 401-k plans), company-funded medical insurance (replaced with employee-funded insurance), and company-supplied training (replaced with employee-selected and employee-funded training).

I see BYOO (bring your own office) as another step in that sequence. With BYOO, the company does not provide the office to the employee. Instead, the employee makes arrangements for his own workspace. This may mean a home office, or it may mean a co-working space, or it may mean s shared hotelling space in which workers rent a cubicle, desk, and office equipment.

BYOO is possible for people who can work without being in a specific physical place. Some jobs require physical presence: waitstaff, assembly workers, plumbers, etc. Many jobs, especially IT jobs, can be done remotely. Analysis, design, programming, and testing can all be completed without physical presence.

To implement BYOO, one needs the types of jobs that are "remotable", coupled with the equipment to make it possible. That could be as simple as a cell phone, a laptop computer, and an internet connection. (And possibly a quite place to work.) We have the technology today.

We may not have the psychological ability to implement BYOO. If managers need to see people sitting at their desks to believe that they are working, BYOO is not possible. Remote work is possible only when managers trust individuals to complete their work without immediate supervision.

One other prediction: the acronym BYOO will *not* be the one people use. I don't know what it will be, but it won't be BYOO.

New dimensions in system design

The technology environment is changing. The change is significant, affecting the basic dimensions with which we measure systems.

The center of the old technology world was Windows. Manufacturers built PCs to run Windows. Suppliers built software to run on Windows. Systems were local -- that is, they ran in a single location. Before the internet era, everything lived in your data center. Even with the internet, systems ran in a single data center. (Or possibly two, for redundancy.)

With everything in one data center,  

The age of "Windows as the center of the universe" has passed. Today, we have multiple environments. The simple universe of one technology has been replaced by a universe of multiple galaxies.

Today, systems that are spread across multiple hardware installations. Systems consist of one (or several) front end "user clients", possibly for the iPhone, Android phones, and web browsers. The back end consists of not one but many cooperative services, each handling a small portion of the work. These can include web servers, database servers, queue managers, and content distribution networks.

But the change is larger than that. The set of basic elements is changing. In the old world, systems were built from a database, access, and programs written in a specified language. Those "dimensions" of the application defined its "space" in the data center. Vendors were defined by how well they met the needs of the organization in those dimensions.

In the new world, systems are more complex. Instead of a single database, a system may use several. Instead of a single web server, an application may use multiple, depending on the transaction being processed. We use virtualized processors to host servers, and cloud computing to manage the virtualized servers. We no longer think of a system as "a Java application"; we think of it as "a Java, Javascript, SQL, NoSQL, message queues, and some HTML and CSS" system.

In such a complex world, we design our systems with a new collection of "building blocks", and we look for vendors to provide those building blocks. Those elements of system design are: hardware, software, content, and services. These are the dimensions for system architecture and vendor offerings.
Let's look at the big providers:

Microsoft clearly supplies software: Windows, Office, Visual Studio, and many other packages. They are getting into the hardware game. Microsoft has offered hardware for years, in the form of the Microsoft Mouse, the Microsoft Keyboard, and today with the XBOX, the Kinect, and the Surface. They also offer cloud services and content (music, books, and movies).

Google offers some hardware (the Nexus phones and tablets) but also works with manufacturers. They offer the Chromebook hardware that runs their Chrome browser. They offer cloud services. They have also gotten into the music and video markets, with Google play and YouTube.

Amazon.com offers hardware, but only the the form of the Kindle. They do not offer PCs or phones. They have a rich offering of services with their cloud systems.

Apple offers hardware, software, content, and little in the way of cloud services. Their MacBooks and iPads (and the operating systems) are respected by all. They provide content in the form of music, movies, books, and newspaper subscriptions. Yet their focus is on consumers, not the enterprise. This is clear in their iCloud offerings, which are designed for individuals.

In this light of hardware, software, services, and content, the other "big names" of the tech world are lacking:

Barnes and Noble offers hardware (Nook tablets and e-readers) and the software to run them, but nothing for development or the office. They offer content but not services.

IBM offers hardware and software but not content. They don't sell books or music. They offer cloud services, in addition to their old-school consulting services.

Facebook offers services and content, but not hardware and software. (This is why the rumor of a Facebook phone keeps returning.) Facebook uses cloud computing for their servers but doesn't offer it to customers. They offer other services, such as a platform for games and an authentication service for web site log-ins.

Yahoo offers services and some (limited) content but not hardware or software.

I'm not claiming that a vendor needs all four of these components to be profitable. IBM and Yahoo are doing rather well. (Barnes and Noble not so much, but that is a problem specific to their market.) But the presence (or absence) of these four components is important, and decides how a vendor can assist a client.

The new dimensions of hardware, software, services, and content affect hiring organizations too. Systems will need all of these components (to one degree or another) to satisfy a customer's needs. When looking for solutions from vendors, and when looking to hire, companies will have to weigh the strengths of the vendor (or the candidate) in all of these areas.
The smart, big vendors are offering all services. The smart, small vendors will offer a carefully selected subset and ensure that they can provide quality. The same goes for candidates. The heavyweights will have expertise in all areas, the middleweights light expertise in all and strength in a few, and the lightweights will be capable in one or two.

The task for vendors (and candidates) is to build their skills along these dimensions, and present them to clients.

PC as status item

Today, the common PC is just that -- common. A typical office will have many PCs, all like. (Some offices will have variation. From my observations, the consistency of the PC set will be proportional to the size of the organization. The largest organizations have the most homogenous set of PCs.)

With the introduction of BYOD, we may see a resurgence in "the PC as status symbol".

What's that, you say? You've never seen a PC used as a status symbol?

Well, it has happened. Just after the release of the IBM PC, and when companies were experimenting with word processors and spreadsheets, PCs were *quite* the status symbol. A PC was a better typewriter, an expensive investment, and a thing to be admired. Some PCs had monochrome monitors and some had color monitors.

When the IBM PC AT was released, some people had the newer, faster PC and some had the older, slower PCs.

Even as late as 1995, PCs varied within organizations and were used as status symbols. After 1995, that changed. The price of PCs dropped to a level that made frequent replacements feasible. Large organizations (the ones with tech support groups) found it easier and cheaper to "refresh" PCs every few years. It meant they had the latest operating system, fewer hardware failures, and a consistent set of PCs with easier support.

When the PCs become consistent, the status from different PCs disappeared.

BYOD may introduce the status again. When individuals select and purchase their own equipment, the consistency of equipment will vanish. Some will purchase iPads, some Android devices, and some Microsoft Surface tablets. Some people will "refresh" their devices frequently, and some will hold on to them for years. (We may see a "reverse status" with reverence for an old-school device.)

The return of status may cause some friction and competition among team members. A good manager will look for the signs and focus the team on the objectives.

Refactoring and code cleanup are everyone's job

Code is like fish. Over time (and a surprisingly short period of time), it "goes bad" and starts to smell. While fish must be discarded, code can be improved.

Code can be messy for a number of reasons. It can be assembled from older (poorly written) systems. It can be developed under aggressive timeframes. The developers can be careless or inexperienced.

You want to improve your code. Messy code is hard to understand, difficult to debug, and problematic to change. Projects with messy code find that they miss deadlines and have a large number of defects.

Refactoring is the process of changing the structure of code while maintaining its behavior. By changing the structure, you can improve the readability and maintainability of the code. By keeping the functionality, you keep all current features.

One might think that assigning the task of refactoring to a subset of the team is sufficient. The idea is that this subteam will improve the code, cleaning up the mess that has developed over time. But I believe that such an approach is ineffective.

Refactoring (and code quality in general) is a task for everyone on the project. The approach of a separate team does not work. Here's why:

The team members dedicated to the task are viewed as a separate team. Usually they are viewed as the elite members of the team; more darkly as diva-developers. Sometimes they are viewed as servants, or a lower caste of the team. Fracturing the team in this way benefits no one.

Other (non refactoring) members of the team can become sloppy. They know that someone will come after them to clean their code. That knowledge sets up an incentive for sloppy code -- or at least removes the incentive for clean code.

The biggest reason, though, is one of numbers. The refactoring team is smaller than the rest of the team. This smaller team is attempting to clean up the mess created by the entire team. Your team's current processes create messy code (for whatever reason) so that larger (non-refactoring) team is still creating a mess. The smaller team attempts to clean while the larger team keeps creating a mess. This doesn't work.

As I see it, the only way to clean code is to get everyone involved. No separate team, no elite squad, no penalty assignments. The team's process must change to create clean code (or to improve messy code). Nothing less will do.