Software Development Literacy – Wave of the Future or Doomsday Device?

A few months ago, I read a newspaper article – which unfortunately I can’t find – about the idea that software development literacy may someday seem as normal as reading literacy is today. I didn’t think it was far-fetched at all. In today’s world *everyone* touches a computer in some way, even if it’s only the chip that runs the fare collector on public transportation. (This isn’t a discussion about rich and poor – I tried to come up with the most benign example I could. Admittedly, it’s more a first world example.)

Today there was an article in the Boston Globe about a company called FreeCause here in Boston that is doing something unique. The story explained that…

…29-year-old company chief executive Michael Jaconi told all 60 of his employees that they had to learn the programming language JavaScript. The idea is not to turn everyone into an engineer, but to give employees — from accountants to designers to salespeople — a better understanding of what goes into developing the company’s software.

Jaconi’s initiative is a recognition that technology has inserted itself into almost every aspect of modern life, and it’s a subject people increasingly need to know. In many companies, technology often creates barriers that separate technical from nontechnical workers.   “There’s a pretty big divide between engineers and nonengineers, and what I wanted to do was bring those two camps closer together,” said Jaconi, a serial entrepreneur and former political campaign worker who is learning to code along with his employees. “I thought that this would facilitate more efficiency, bring teams closer together, and ultimately make our company perform better.”

Oddly, unless I’m really out of it, there’s a bug in the example the article showed in one of the accompanying pictures. Bonus points if you spot it.

Learning JavaScript

Image from the Boston Globe Web site

I tweeted a link. (Through the wonders of HootSuite – the awesome social media tool I prefer over all the others – I also posted it to Facebook and LinkedIn at the same time.)

The fastest response I got on Twitter was from my friend Dan Antion (@DAntion):

I expected I’d hear something similar from a good number of the developers who follow me on Twitter, and eventually I did hear from quite a few with what amounted to disparaging comments about the idea. At best they were, like Dan’s, a sort of “uh-oh”.

I think it’s more complex than that initial reaction and also more important. Let me explain my thoughts.

As a consultant, I am paid to be an expert in some things. What many of my clients don’t realize, though, is that because I don’t specialize in any particular industry and I’ve been in consulting a very long time, I also have to know at least something about a lot of things: car manufacturing, stock trading, theme parks, higher education, pharmaceutical discovery, and the list goes on. (Those are all examples of real projects I’ve worked on over the years.) I have enough humility to know that I’m not an expert in fields out of my chosen one, but I have to know *something* about others in order to advise in a useful way and to write useful solutions.

Think about your major in college. Do you “do” that thing now as your everyday activity? I majored in Mathematics, and it’s pretty rare that I “do” math. I studied all kinds of things in college: psychology, chemistry, film making, rocks for jocks [geology], etc. I don’t “do” any of those things on a daily or even yearly basis. But I’ll argue with anyone who says that a liberal arts education – wherein one studies a wide range of things – doesn’t add up to a well-rounded, multi-talented individual. (Full disclosure: my major was actually called “Computer Mathematics”. The last time I came up with an interesting, computer-based  way to factor primes was in college, though.)

Another thing I’ve seen over my years of consulting is that, generally speaking, the teams that I’ve seen be most effective share some traits. They are usually cross-functional, highly motivated, and inquisitive about each other’s knowledge. I’d take a team with those traits over specific, homogeneous knowledge any day. Note that I mentioned “inquisitive about each other’s knowledge”. That means that they want to learn a little something about what the others know. This helps them to work together more effectively.

As software development becomes more and more pervasive, what’s wrong with everyone having basic literacy in it?

We might be able to interact with technical customer support better. We may be able to understand what to do or not do to avoid infecting our computers with viruses. We may be able to save unending time by not doing things that cause our work to be lost, requiring us to recreate it. We might understand what we’re asking each other for just a little bit better, making us more able to collaborate on the important parts of the task at hand rather than level setting every time.

Simple programming knowledge (I almost said “basic programming knowledge”, but that would be too specific) is an excellent idea. To apply knowledge management principles to “using a computer”, if we can identify what the key things the high performers know that make them good at it and can teach the low performers just a scintilla of that knowledge, everyone’s competency rises. By knowing something about what’s going on under the hood, I posit we all become better digital denizens.

Also note that nothing in the article said that the accountant or the salesperson has to become a software developer. They just have to learn the basics – enough for “every FreeCause employee develop a product such as a Web page or toolbar component that could potentially be integrated into the company’s loyalty rewards software.” That’s potentially. Not definitely, and not absolutely.

I’m going to go with Jaconi’s idea as a wave of the future, and one I welcome. There’s plenty of other stuff to worry about in the doomsday category, and this isn’t one of them.

Enhanced by Zemanta

Sunday Boston Globe: "Please do not change your password"

There’s an interesting article in today’s Sunday Boston Globe entitled Please do not change your password The basic premise is that the security folks are wasting their time and ours in trying to get us to use strong passwords which we change frequently.  The harder they try to make us do it, the less likely it is that we *will* do it.  This all comes from a new study from Cormac Herley of Microsoft, who is a principal researcher for Microsoft Research.

To prompt [people] to be more rigorous about computer protection, he said, “You want actual studies, actual data.

”That poses a challenge for the security industry, Herley said. While doctors can cite statistics showing smoking causes cancer, and road-safety engineers can produce miles of numbers supporting seat belt use, computer security professionals lack such compelling evidence to give their advice clout. “Unbelievable though it might seem, we don’t have data on most of the attacks we talk about,” he said. “That’s precisely why we’re in this ‘do it all’ approach.”

Another thing this points out to me is similar to what I meant when I tweeted earlier this week "Never fall for your own marketing". What I meant was that it can be pretty easy, when you are in the midst of something, to believe that it is not only important, but that everyone else will think it is important, too. This happens to people in the middle of a political campaign juggernaut, and apparently can happen to computer security professionals, too.

I understand every little bit of the threat that is out there around someone knowing my passwords. (I really think that I do.) But it annoys me no end to be told that I need to change my password every 30 days to something which is absolutely non-mnemonic for me.  In most cases, people get around this by simply writing the password down on a piece of paper, often putting it right on their monitor!

It’s also important for all of us to keep in mind that what we hold the most important may not mean a damn thing to anyone else. As computing professionals, we can spend way too much time trying to get every pixel in place and writing the most elegant code, but the users often just don’t care. They want it to work, and they want it to be easy.  That may be it.

So let’s all learn something from the password study: Don’t make it too hard, and back it all up with data. Real data.

Applying "Product Service Systems" to Corporate Environments

There’s a great article in the Boston Sunday Globe today entitled The Leased Life. It talks about what is termed the “product service system”.  The basic idea is that many of the things we buy we don’t buy because we want the thing itself, but what the thing can do for us.  We buy tomatoes or airline tickets because we actually want the thing, but we buy cars or refrigerators or power drills because we want what the thing does: getting us from Point A to Point B, cooling our milk, or making a hole in something.

I live in what, to most people, is a very affluent community.  We all have a lot of “stuff”.  When we need something, we typically go out and buy it (like Americans increasingly do, regardless of their means).  I live in a drafty old (for the US) house that requires some pretty specialized little repairs from time to time, so I own a bunch of what I’ve always thought of as “one time use” tools.  I needed to fix a hanging shower curtain rod, so I bought a little device (for $15!) that let me make a length of metal have threads on one end. Am I likely to need it again? Not a chance.  It’s often occurred to me that if I could just look into my neighbors’ toolboxes, then I wouldn’t need to buy so many of these silly little tools.  Better for my wallet and for the planet in general because fewer of these things would need to exist.

The idea with a “product service system” is that we look at those one (or just a few) time use things and figure out a way to provide them for people in a more economical way (for them) and a more efficient way (for the provider). There are great examples of this in the article.  Think of it basically like the leasing model that is in place pervasively for cars, and you’ll get the idea. There are even some Web sites springing up to facilitate this sort of transactions between neighbors.

What really got me thinking, though, is how cool it would be to apply this kind of thinking in a corporate setting, for real.  What if I need someone to help my team with some marketing concept for a few days? The barriers to this tend to be the inflexibility of corporate budgeting and internal cost transfers.  When I worked at Renaissance Solutions (long defunct) back in the late-1990s, one of the founders, Harry Lasker (a man perhaps too brilliant for any of us to fathom), often talked about a concept called “solution puts and calls”.  The terminology didn’t work for anyone, really, including Harry, but the idea was similar to a product service system.  If I have some extra expertise and time within my team, why not say to the organization: “I can offer you X.”  This can work as a sort of mart mechanism: some people offer solutions (the puts) and others publish the needs or questions (the calls).  (Yes, this is where, even if you’re following the word usage, extending the put and call concept from options trading falls down.) The quid pro quo on this could take many forms, and the exchange of internal funny money is only one possibility.  Too often organizations get too trapped in the control mechanisms which are in place to be able to be productive.

And, lest you thought you would be able to read an entire post form me without a mention of SharePoint, here’s where SharePoint can come in.  SharePoint is uniquely suited to provide the platform for this type of transaction.  Not only can it facilitate the put and call matching, it can also allow for mining the put and call content for interesting patterns and capabilities that organizations don’t even realize they have.  If we can see that there is a lot of “traffic” on a certain set of transactions, it may indicate latent capabilities within the organization we didn’t realize we had, excess capacity we can better repurpose, etc.  These capabilities can, and should have a potential impact on the organization’s strategy.  If there’s a huge capability that we didn’t know we had, then perhaps it’s time to look at how we can develop and monetize it.

I would love to work on a project like this because it really kicks things up several notches.  Unfortunately, it takes pretty visionary higher-ups to see that this approach can be fruitful and, in fact, improve not just the organization’s productivity, but also it’s general well-being, though a happier and more loyal culture.

Are Newspapers Really Dead? The Boston Globe Thinks Not

And I don’t think so, either.  I love sitting down with the Boston Globe and finding out what’s going on in the world and locally.  (I am totally at odds with the editorial slant of the Globe, but that’s part of what I enjoy!)  Even better if I can read the Globe lying in the hammock on a beautiful summer day!

Today there was an insert in my Boston Globe promoting a new online option for the Globe: the GlobeReader Preview Edition.  Available to current subscribers for free (at the moment) and built with Adobe Air, it lets you download and take offline a full digital version of the newspaper.

The download and install was painless (not all are) and gosh darn it, the app gives you the paper pretty much as it looks in print.  Of course because it’s on the computer it’s fully navigable, you can adjust font sizes, you can peruse only the pictures, etc.  Of course, you can also print anything you want.  You can also store up to seven days of the paper locally.

Maybe this type of thing will be what saves newspapers.  What do you think?