, , , ,

Blast from the past: Facebook’s tech infrastructure from 2008

Waybackmachine3Fire up the WABAC Machine, Mr. Peabody: In June 2008, I wrote a piece for MIT Technology Review explaining “How Facebook Works.”

The story started with this:

Facebook is a wonderful example of the network effect, in which the value of a network to a user is exponentially proportional to the number of other users that network has.

Facebook’s power derives from what Jeff Rothschild, its vice president of technology, calls the “social graph”–the sum of the wildly various connections between the site’s users and their friends; between people and events; between events and photos; between photos and people; and between a huge number of discrete objects linked by metadata describing them and their connections.

Facebook maintains data centers in Santa Clara, CA; San Francisco; and Northern Virginia. The centers are built on the backs of three tiers of x86 servers loaded up with open-source software, some that Facebook has created itself.

Let’s look at the main facility, in Santa Clara, and then show how it interacts with its siblings.

Read the whole story here… and check out Facebook’s current Open Source project pages too.

, , ,

Apple WWDC 2016 becomes Apple WTF – No show stoppers there

apple-watchos-wwdc-2016_0014-720x405-cSan Francisco – Apple’s Worldwide Developer Conference 2016 had plenty of developers. Plenty of WWDC news about updated operating systems, redesigned apps, sexy APIs, expansion of Apple Pay and a long-awaited version of Siri for the Macintosh.

Call me underwhelmed. There was nothing, nothing, nothing, to make me stand up and cheer. Nothing inspired me to reach for my wallet. (Yes, I know it’s a developer conference, but still.) I’m an everyday Apple user who is typing this on a MacBook Air, who reads news and updates Facebook on an iPad mini, and who carries an iPhone as my primary mobile phone. Yawn.

If you haven’t read all the announcements from Apple this week, or didn’t catch the WWDC keynote live or streaming, Wired has the best single-story write-up.

Arguably the biggest “news” is that Apple has changed its desktop operating system naming convention again. It used to be Mac OS, then Mac OS X, then just OS X. Now it is macOS. The next version will be macOS 10.12 “Sierra.” Yawn.

I am pleased that Siri, Apple’s voice recognition software, is finally coming to the Mac. However, Siri itself is not impressive. It’s terrible for dictation – Dragon is better. On the iPhone, it misinterprets commands far more than Microsoft’s Cortana, and its sphere of influence is pretty limited: It can launch third-party apps, for example, but can’t control them because the APIs are locked down.

Will Siri on macOS be better? We can be hopeful, since Apple will provide some API access. Still, I give Microsoft the edge with Cortana, and both are lightyears behind Amazon’s Alexa software for the Echo family of smart home devices.

There are updates to iOS, but they are mainly window dressing. There’s tighter integration between iOS and the Mac, but none of those are going to move the needle. Use an iPhone to unlock a Mac? Copy-paste from iOS to the Mac? Be able to hide built-in Apple apps on the phone? Some of the apps have a new look? Nice incremental upgrades. No excitement.

Apple Watch. I haven’t paid much attention to watchOS, which is being upgraded, because I can’t get excited about the Apple Watch until next-generation hardware has multiple-day battery life and an always-on time display. Until then, I’ll stick with my Pebble Time, thank you.

There are other areas where I don’t have much of an opinion, like the updates to Apple Pay and Apple’s streaming music services. Similarly, I don’t have much experience with Apple TV and tvOS. Those may be important. Or maybe not. Since my focus is on business computing, and I don’t use those products personally, they fall outside my domain.

So why were these announcements from WWDC so — well — uninspiring? Perhaps Apple is hitting a dry patch. Perhaps they need to find a new product category to dominate; remember, Apple doesn’t invent things, it “thinks different” and enters and captures markets by creating stylish products that are often better than other companies’ clunky first-gen offerings. That’s been true in desktop computers, notebooks, smartphones, tablets, smart watches, cloud services and streaming music – Apple didn’t invent those categories, and was not first to market, not even close.

Apple needs to do something bold to reignite excitement and to truly usher in the Tim Cook era. Bringing Siri to the desktop, redesigning its Maps app, using the iPhone to unlock your desktop Mac, and a snazzy Minnie Mouse watch face, don’t move the needle.

I wonder what we’ll see at WWDC 2017. Hopefully a game-changer.

, , , ,

A Seven-Point Plan for Automotive Cybersecurity

code-curmudgeon2I am hoovering directly from the blog of my friend Arthur Hicken, the Code Curmudgeon:

Last week with Alan Zeichick and I did a webinar for Parasoft on automotive cybersecurity. Now Alan thinks that cybersecurity is an odd term, especially as it applies to automotive and I mostly agree with him. But appsec is also pretty poorly fitted to automotive so maybe we should be calling it AutoSec. Feel free to chime-in using the comments below or on twitter.

I guess the point is that as cars get more complicated and get more “smart” parts and get more connected (The connected car) as part of the “internet of things”, you will start to see more and more automotive security breaches occurring. From taking over the car to stealing data to triggering airbags we’ve already had several high-profile incidents which you can see in my IoT Hall-of-Shame.

To help out we’ve put together a high-level overview of a 7-point plan to get you started. In the near future we’ll be diving into detail on each of these topics, including how standards can help you not only get quality but safety and security, the role of black-box, pen-test, and DAST as well as how to get ahead of the curve and harden your vehicle software using (SAST) and hybrid testing (IAST).

The webinar was recorded for your convenience, so be sure and check it out. If you have automotive software topics that are near and dear to your heart, but sure to let me know in the comments or on Twitter or Facebook.

Okay, the webinar was back in February, but the info didn’t appear on my blog then. Here it is now. My apologies for the oversight. Watch and enjoy the webinar!

, , , ,

The most important plug-in for Customer Experience Management software: Humans

customer_experienceNo smart software would make the angry customer less angry. No customer relationship management platform could understand the problem. No sophisticated HubSpot or Salesforce or Marketo algorithm could be able to comprehend that a piece of artwork, brought to a nationwide framing store location in October, wouldn’t be finished before Christmas – as promised. While an online order tracking system would keep the customer informed, it wouldn’t keep the customer satisfied.

Customer Experience Management (CEM). That’s the hot new buzzword for directly engaging the customer. Contrast that with Customer Relationship Management (CRM), which is more about the back-end tracking of customers, leads and orders.

Think about how Amazon.com or FedEx or Netflix keep you constantly informed about what’s happening with your products and services. They have realized that the key to customer success is equally product/service excellence and communications excellence. When I was a kid, you mailed a check and an order form to Sears Roebuck, and a few weeks later a box showed up in the mail. That was great customer service in the 1960s and 1970s. No more. We demand communications. Proactive communications. Effective, empathetic communications.

One of the best ways to make an unhappy customer happy is to empower a human to do whatever it takes to get things right. If possible, that should be the first person the customer talks to, so the problem gets solved as quickly as possible, and without adding “dropped calls” or “too many transfers” to the litany of complaints. A CEM platform should be designed with this is mind.

I’ve written a story about the non-software factors required for effective CEM platforms for Pipeline Magazine. Read the story: “CEM — Now with Humans!

, , ,

Too slow, didn’t wait: The five modern causes of slow website loads

Let’s explore the causes of slow website loads. There are obviously some delays that are beyond our control — like the user being on a very slow mobile connection. However, for the most part, our website’s load time is entirely up to us.

For the most part, our website’s load time is entirely up to us as developers and administrators. We need to do everything possible to accelerate the experience, and in fact I would argue that load time may be the single most important aspect of your site. That’s especially true of your home page, but also of other pages, especially if there are deep links to them from search engines, other Internet sites, or your own marketing emails and tweets.

We used to say that the biggest cause of slow websites was large images, especially too-large images that are downloaded to the browser and dynamically resized. Those are real issues, even today, and you should optimize your site to push out small graphics, instead of very large images. Images are no longer the main culprit, however.

Read my recent article in the GoDaddy Garage, “Are slow website load times costing you money and pageviews?” to see the five main causes of slow website loads, and get some advice about what to do about them.

, , , , , ,

Sauron hacks the Internet of Rings as a state sponsor of cyberterrorism

sauronBarcelona, Mobile World Congress 2016—IoT success isn’t about device features, like long-life batteries, factory-floor sensors and snazzy designer wristbands. The real power, the real value, of the Internet of Things is in the data being transmitted from devices to remote servers, and from those remote servers back to the devices.

“Is it secret? Is it safe?” Gandalf asks Frodo in the “Lord of the Rings” movies about the seductive One Ring to Rule Them All. He knows that the One Ring is the ultimate IoT wearable: Sure, the wearer is uniquely invisible, but he’s also vulnerable because the ring’s communications can be tracked and hijacked by the malicious Nazgûl and their nation/state sponsor of terrorism.

Wearables, sensors, batteries, cool apps, great wristbands. Sure, those are necessary for IoT success, but the real trick is to provision reliable, secure and private communications that Black Riders and hordes of nasty Orcs can’t intercept. Read all about it in my NetworkWorld column, “We need secure network infrastructure – not shiny rings – to keep data safe.”

, , ,

Hackathons build community

diet-cokeA hackathon – like the debut LSO Hackathon held in November 2015 at the MEF’s GEN15 conference – is where magic happens. It’s where theory turns into practice, and the state of the art advances. Dozens of techies sitting in a room, hunched over laptops, scribbling on whiteboards, drinking excessive quantities of coffee and Diet Coke. A hubbub of conversation. Focus. Laughter. A sense of challenge.

More than 50 network and/or software experts joined the first-ever LSO Hackathon, representing a very diverse group of 20 companies. They were asked to focus on two Reference Points of the MEF’s Lifecycle Service Orchestration (LSO) Reference Architecture. As explained by , Director of Certification and Strategic Programs at the MEF and one of the architects of the LSO Hackathon series, these included:

  • LSO Adagio, which defines the element management reference point needed to manage network resources, including element view management functions
  • LSO Presto, which defines the network management reference point needed to manage the network infrastructure, including network view management functions

Read more about the LSO Hackathon in my story in Telecom Ramblings, “Building Community, Swatting Bugs, Writing Code.”

, , ,

Bimodal IT — safety and accuracy vs. speed and agility

gartner-bimodal-itLas Vegas, December 2015 — Get ready for Bimodal IT. That’s the message from the Gartner Application, Architecture, Development & Integration Summit (AADI). It wasn’t a subtle message. Bimodal was a veritable drumbeat, pounded home over and over again in keynotes, classes, and one-on-one meetings with Gartner analysts. We’re going to be hearing a lot about bimodal development, from Gartner and the industry, because it’s a message that really describes what many of us are encountering today.

To quote Gartner’s official definition:

Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.

Gartner sees that we create and manage two different types of projects. Some, Mode 1, being very serious, very methodical, bet-the-business projects that must be done right using formal processes, and others, Mode 2, being more opportunistic, quicker, more agile. That’s not to say that Mode 1 projects can’t be agile, and that Mode 2 projects can’t be big and significant. However, we all know that there’s a big difference between launching an initiative to implement a Black Friday sale on our website or designing a new store-locator mobile app, vs. rolling out a GAAP-compliant accounting system or migrating critical systems to the cloud.

You might argue that there’s nothing revolutionary here with bimodal, and if you did, you would be right. Nobody ever claimed that all IT projects, including software development, are the same, and should be managed the same way. What Gartner has done is provide a clear vocabulary for understanding, categorizing, and communicating project differences more efficiently.

Read more about this in my story “Mode 1, Mode 2: Gartner Preaches Bimodal Development at AADI,” published on the Parasoft blog.

, ,

How to handle difficult feedback without losing your cool

difficult-conversationsYour app’s user interface is terrible. Your business plan is flawed. Your budget is a pipe dream. Your code isn’t efficient. Clients are unhappy with your interpersonal skills. Your meetings are too long. You don’t seem to get along with your developers. You are hard to work with. You are being kicked off the task force because you aren’t adding any value. The tone of your e-mail was too informal. Your department is being given to someone else. No, we won’t need you for this project. No, we don’t need you at all.

We all get feedback. Usually it’s a combination of good and bad. There’s praise and helpful criticism. Sometimes the feedback is about our company, sometimes about our project, sometimes about our team, and sometimes, well, about us. Sometimes we take the feedback in good stride. Other times, we get hurt and angry—and don’t listen. Speaking for myself, I tend to get defensive when given feedback that’s less than glowingly effusive.

Own your feedback. A short paper published by Harvard Business Review, called“Difficult Conversations 2.0: Thanks for the Feedback,” can help.

“In the realm of feedback, the receiver—not the giver—is the key player in the exchange. Here’s how to become a world-class receiver,” write Douglas Stone and Sheila Heen, founders of Triad Consulting Group. The pair teach negotiation at Harvard Law School, and have written a couple of great books, Thanks for the Feedback: The Science and Art of Receiving Feedback Well (Even When it is Off Base, Unfair, Poorly-Delivered, and Frankly, You’re Not in the Mood) and Difficult Conversations: How to Discuss What Matters Most.

I heartily recommend both of Stone & Heen’s books. For now, let me share some of the wisdom in the five-page paper, which is focused somewhat on feedback from managers, but which is broadly applicable to all types of feedback. Stone & Heen write:

By becoming a skillful receiver of feedback, you can achieve three important benefits:

• Take charge of your life-long learning: When we get better at receiving feedback, we take charge of our own learning and can accelerate our growth.

• Improve our relationships: The way we handle feedback has an impact on our relationships.

• Reduce stress and anxiety: For the more sensitive among us, there’s one more important benefit: getting better at receiving feedback reduces stress and anxiety.

The authors say that it’s only natural to evaluate feedback, determine what is accurate and inaccurate, and then focus on what we see as inaccurate:

You can find something wrong with just about any feedback you get. Maybe it doesn’t address the constraints you’re under, it’s outdated, biased, coming from only a few people, or only part of the story. The problem is, when we focus on what’s wrong with the feedback, we lose sight of what might be right about it; and there is also almost always something right about it.

They continue:

Receiving feedback well doesn’t mean that you always have to take the feedback or agree with the assessment. But it does mean engaging in order to first truly understand the feedback, and then deciding what to do about it.

We receive feedback every day. The feedback might be about us from our managers. It might be about products from customer comments left on an open forum, or sent via Twitter. Feedback can be elating—everyone loves a five-star review. It can also be painful and debilitating. As developers, techies, managers and humans, let’s get better at receiving it.


, , , , ,

Big Security, Big Cloud and the Big Goodbye

ddjSoftware-defined networks and Network Functions Virtualization will redefine enterprise computing and change the dynamics of the cloud. Data thefts and professional hacks will grow, and development teams will shift their focus from adding new features to hardening against attacks. Those are two of my predictions for 2015.

Big Security: As 2014 came to a close, huge credit-card breaches from retailers like Target faded into the background. Why? The Sony Pictures hack, and the release of an incredible amount of corporate data, made us ask a bigger question: “What is all that information doing on the network anyway?” Attackers took off with Sony Pictures’ spreadsheets about executive salaries, confidential e-mails about actors and actresses, and much, much more.

What information could determined, professional hackers make off with from your own company? If it’s on the network, if it’s on a server, then it could be stolen. And if hackers can gain access to your cloud systems (perhaps through social engineering, perhaps by exploiting bugs), then it’s game over. From pre-released movies and music albums by artists like Madonna, to sensitive healthcare data and credit-card numbers, if it’s on a network, it’s fair game.

No matter where you turn, vulnerabilities are everywhere. Apple patched a hole in its Network Time Protocol implementation. Who’d have thought attackers would use NTP? GitHub has new security flaws. ICANN has scary security flaws. Microsoft released flawed updates. Inexpensive Android phones and tablets are found to have backdoor malware baked right into the devices. I believe that 2015 will demonstrate that attackers can go anywhere and steal anything.

That’s why I think that savvy development organizations will focus on reviewing their new code and existing applications, prioritizing security over adding new functionality. It’s not fun, but it’s 100% necessary.

Big Cloud: Software-defined networking and Network Functions Virtualization are reinventing the network. The fuzzy line between intranet and Internet is getting fuzzier. Cloud Ethernet is linking the data center directly to the cloud. The network edge and core are indistinguishable. SDN and NFV are pushing functions like caching, encryption, load balancing and firewalls into the cloud, improving efficiency and enhancing the user experience.

In the next year, mainstream enterprise developers will begin writing (and rewriting) back-end applications to specifically target and leverage SDN/NFV-based networks. The question of whether the application is going to run on-premises or in the cloud will cease to be relevant. In addition, as cloud providers become more standards-based and interoperable, enterprises will gain more confidence in that model of computing. Get used to cloud APIs; they are the future.

Looking to boost your job skills? Learn about SDN and NFV. Want to bolster your development team’s efforts? Study your corporate networking infrastructure, and tailor your efforts to matching the long-term IT plans. And put security first—both of your development environments and your deployed applications.

Big Goodbye: The tech media world is constantly changing, and not always for the better. The biggest one is the sunsetting of Dr. Dobb’s Journal, a website for serious programmers, and an enthusiastic bridge between the worlds of computer science and enterprise computing. After 38 years in print and online, the website will continue, but no new articles or content will be commissioned or published.

DDJ was the greatest programming magazine ever. There’s a lot that can be said about its sad demise, and I will refer you to two people who are quite eloquent on the subject: Andrew Binstock, the editor of DDJ, and Larry O’Brien, SD Times columnist and former editor of Software Development Magazine, which was folded into DDJ a long time ago.

Speaking as a long-time reader—and as one of the founding judges of DDJ’s Jolt Awards—I can assure you that Dr. Dobb’s will be missed.

, , ,

Innovate in the cloud, cheaply and securely

sony_pictures_logoFor development teams, cloud computing is enthralling. Where’s the best place for distributed developers, telecommuters and contractors to reach the code repository? In the cloud. Where do you want the high-performance build servers? At a cloud host, where you can commandeer CPU resources as needed. Storing artifacts? Use cheap cloud storage. Hosting test harness? The cloud has tremendous resources. Load testing? The scales. Management of beta sites? Cloud. Distribution of finished builds? Cloud. Access to libraries and other tools? Other than the primary IDE itself, cloud. (I’m not a fan of working in a browser, sorry.)

Sure, a one-person dev team can store an entire software development environment on a huge workstation or a convenient laptop. Sure, a corporation or government that has exceptional concerns or extraordinary requirements may choose to host its own servers and tools. In most cases, however, there are undeniable benefits for cloud-oriented development, and if developers aren’t there today, they will be soon. My expectation is that new projects and team launch on the cloud. Existing projects and teams will remain on their current dev platforms (and on-prem) until there’s a good reason to make the switch.

The economics are unassailable, the convenience is unparalleled, and both performance and scalability can’t be matched by in-house code repositories. Security in the cloud may also outmatch most organizations’ internal software development servers too.

We have read horror stories about the theft of millions of credit cards and other personal data, medical data, business documents, government diplomatic files, e-mails and so-on. It’s all terrible and unlikely to stop, as the recent hacking of Sony Pictures demonstrates.

What we haven’t heard about, through all these hacks, is the broad theft of source code, and certainly not thefts from hosted development environments. Such hacks would be bad, not only because proprietary source code contains trade secrets, but also because the source can be reverse-engineered to reveal attack vulnerabilities. (Open-source projects also can be reverse-engineered, of course, but that is expected and in fact encouraged.)

Even worse that reverse-engineering of stolen source code would be unauthorized and undetected modifications to a codebase. Can you imagine if hackers could infiltrate an e-commerce system’s hosted code and inject a back door or keylogger? You get the idea.

I am not implying that cloud-based software development systems are more secure than on-premises systems. I am also not implying the inverse. My instinct is to suggest that hosted cloud dev systems are as safe, or safer, than internal data center systems. However, there’s truly no way to know.

A recent report from the analyst firm Technology Business Research took this stance, arguing that security for cloud-based services will end up being better than security at local servers and data centers. While not speaking specifically to software development, a recent TBR report concluded, “Security remains the driving force behind cloud vendor adoption, while the emerging trends of hybrid IT and analytics, and the associated security complications they bring to the table, foreshadow steady and growing demand for cloud professional services over the next few years.”

Let me close by drawing your attention to a competition geared at startups innovating in the cloud. The Clouded Leopard’s Den is for young companies looking for A-series or B/C-series funding, and offers tools and resources to help them grow, attract publicity, and possibly even find new funding. If you work at a cloud startup, check it out!

, , , ,

Is the best place for data in your data center or in the cloud? Ask your lawyer


Cloud-based storage is amazing. Simply amazing. That’s especially true when you are talking about data from end users that are accessing your applications via the public Internet.

If you store data in your local data center, you have the best control over it. You can place it close to your application servers. You can amortize it as a long-term asset. You can see it, touch it and secure it—or at least, have full control over security.

There are downsides, of course, to maintaining your own on-site data storage. You have to back it up. You have to plan for disasters. You have to anticipate future capacity requirements through budgeting and advance purchases. You have to pay for the data center itself, including real estate, electricity, heating, cooling, racks and other infrastructure. Operationally you have to pipe that data to and from your remote end users through your own connections to the Internet or to cloud application servers.

By contrast, cloud storage is very appealing. You pay only for what you use. You can hold service providers to service-level guarantees. You can pay the cloud provider to replicate the storage in various locations, so customers and end-users are closer to their data. You can pay for security, for backups, for disaster recovery provisions. And if you find that performance isn’t sufficient, you can migrate to another provider or order up a faster pipe. That’s a lot easier, cheaper and faster than ripping-and-replacing outdated storage racks in your own data center.

Gotta say, if I were setting up a new application for use by off-site users (whether customers or employees), I’d lean toward cloud storage. In most cases, the costs are comparable, and the operational convenience can’t be beat.

Plus, if you are at a startup, a monthly storage bill is easier to work with than a large initial outlay for on-site storage infrastructure.

Case closed? No, not exactly. On-site still has some tricks up its sleeve. If your application servers are on-site, local storage is faster to access. If your users are within your own building or campus, you can keep everything within your local area network.

There also may be legal advantages to maintaining and using onsite storage. For compliance purposes, you know exactly where the data is at all times. You can set up your own instruction detection systems and access logs, rather than relying upon the access controls offered by the cloud provider. (If your firm isn’t good at security, of course, you may want to trust the cloud provider over your own IT department.)

On that subject: Lawsuits. In her story, “Eek! Lawyers are Coming After Your Fitbit!,” Sharon Fisher writes about insurance attorneys issuing subpoenas against a client’s FitBit data to show that she wasn’t truly as injured as she claimed. The issue here isn’t only about wearables or healthcare. It’s also about access. “Will legal firms be able to subpoena your cloud provider if that’s where your fitness data is stored? How much are they going to fight to protect you?” Fisher asks.

Say a hostile attorney wants to subpoena some of your data. If the storage is in your own data center, the subpoena comes to your company, where your own legal staff can advise whether to respond by complying or fighting the subpoena.

Yet: If the data is stored in the cloud, attorneys or government officials could come after you, or try to get access by giving a subpoena to the cloud service provider. Of course, encryption might prevent the cloud provider from complying. Still, this is a new concern, especially given the broad subpoena powers granted to prosecutors, litigating attorneys and government agencies.

It’s something to talk to your corporate counsel about. Bring your legal eagles into the conversation.

, , , ,

Once upon a midnight dreary, while I struggled with jQuery

The tests, my lord, have failed.

I should have used a promise;
There would have been an object ready made.
Tomorrow, and tomorrow, and tomorrow,
Loops o’er this petty code in endless mire,
To the last iteration of recorded time;
And all our tests have long since found
Their way to dusty death. Shout, shout, brief handle!
Thine’s but a ghoulish shadow, an empty layer
That waits in vain to play upon this stage;
And then is lost, ignored. Yours is a tale
Told by an idiot, full of orphaned logic
Signifying nothing.

Those are a few words from a delightful new book, “If Hemingway Wrote JavaScript,” by Angus Croll. For example, the nugget above is “Macbeth’s Last Callback, after a soliloquy from Macbeth from William Shakespeare.”

Literary gems and nifty algorithms abide in this code-dripping 200-page tome from No Starch Press. Croll, a member of the UI framework team at Twitter, has been writing about famous authors writing JavaScript since 2012, and now has collected and expanded the entries into a book that will be amusing to read or gift this holiday season. (He also has a serious technical blog about JavaScript, but where’s the fun in that?)

Read and wonder as you see how Dan Brown, author of “The Da Vinci Code,” would code a Fibonacci sequence generator. How Jack Kerouac would calculate factorials. How J.D. Salinger and Tupac Shakur would determine if numbers are happy or inconsolable. How Dylan Thomas would muse on refactoring. How Douglas Adams of “Hitchhiker’s Guide to the Galaxy” fame would generate prime numbers. How Walt Whitman would perform acceptance tests. How J.K. Rowling would program a routine called mumbleMore. How Edgar Allen Poe would describe a commonplace programming task:

Once upon a midnight dreary, while I struggled with JQuery,
Sighing softly, weak and weary, troubled by my daunting chore,
While I grappled with weak mapping, suddenly a function wrapping
Formed a closure, gently trapping objects that had gone before.

Twenty-five famous authors, lots of JavaScript, lots of prose and poetry. What’s not to like? Put “If Hemingway Wrote JavaScript” on your shopping list.

Let’s move from JavaScript to C, or specifically the 7th Underhanded C Contest. If you are a brilliantly bad C programmer, you might win a US$200 gift certificate to popular online store ThinkGeek. The organizer, Prof. Scott Craver of Binghamton University in New York, explains:

The goal of the contest is to write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil. Every year, we will propose a challenge to coders to solve a simple data processing problem, but with covert malicious behavior. Examples include miscounting votes, shaving money from financial transactions, or leaking information to an eavesdropper. The main goal, however, is to write source code that easily passes visual inspection by other programmers.

The specific challenge for 2014 is to write a surveillance subroutine that looks proper but leaks data. The deadline is Jan. 1, 2015, more or less. See the Underhanded C website; be sure to read the FAQ!

, , , ,

Tomorrow’s forecast: Distributed Denial of Service

forecastMalicious agents can crash a website by implementing a DDoS—a Distributed Denial of Service Attack—against a server. So can sloppy programmers.

Take, for example, the National Weather Service’s website, operated by the United States National Oceanic and Atmospheric Administration, or NOAA. On August 29, the service went down, hard, as single rogue Android app overwhelmed the NOAA’s servers.

As far as anyone knows, there was nothing deliberately malicious about the Android app, and of course there is nothing specific to Android in this situation. However, the app in question was making service requests of the NOAA server’s public APIs every few milliseconds. With hundreds, thousands or tens of thousands of instances of that app running simultaneously, the NOAA system collapsed.

There is plenty of blame to go around. Let’s start with the app developer.

Certainly the app developer was sloppy, sloppy, sloppy. I can imagine that the app worked great in testing, when only one or two instances of the app were running at any one time on a simulator or on actual devices. Scale it up—boom! This is a case where manual code reviews may have found the problem. Maybe not.

Alternatively, the app developer could have checked to see if the public APIs it required (such as NOAA’s weather API) could handle the anticipated load. However, if the coders didn’t write the software correctly, load testing may not have sufficed. For example, say that the design of the app was to pull data every 10 seconds. If the programmers accidentally set up the data retrieval to pull the data every 10 milliseconds, the load would be 1,000x greater than anticipated. Every 10 seconds, no problem. Every 10 milliseconds, big problem. Boom!

This is a nasty bug, to be sure. Compilers, libraries, test systems, all would verify that the software ran correctly, because it did run correctly. In the scenario I’ve painted, it simply wasn’t coded to meet the design. The bug might have been spotted if someone noticed a very high number of external API calls, or again, perhaps during a manual code review. Otherwise, it’s not hard to see how it would slip through the crack.

Let’s talk about NOAA now. In 2004, the weather service beefed up its Internet loads in anticipation of Hurricane Charley, contracting with Akamai to host some of its busiest Web pages, using distributed edge caching to reduce the load. This worked well, and Akamai continued to work with NOAA. It’s unclear if Akamai also fronted public API calls; my guess is that those were passed straight through to the National Weather Service servers.

NOAA’s biggest problem is that it has little control over external applications that use its public APIs. Even so, Akamai was still in the circuit and, fortunately, was able to help with the response to the Aug. 29 accidental DDoS situation. At that time, the National Weather Service put out a bulletin on its NIDS messaging service that said:


Kudos to NOAA for responding quickly and transparently to this issue. Still, this appalling situation—that a single DDoS attack could cripple such a vital service—is unacceptable. Imagine if this had been a malicious attack, rather than an accidental coding error, and if the attacker was able to modify the attack in real time to go around Akamai’s attempts to block the traffic.

What could NOAA have done differently? For best results, DDoS attacks must be blocked within the network before they reach (and overwhelm) the server. Therefore, DDoS detection and blocking systems should already have been in place.

For example, with the ability to detect potential attacks due to abnormally high volumes of requests from a specific app, raise alarms, and also drop such requests (which is fast and takes few resources), instead of servicing them (which is slow and takes more resources). Perfect? No. DDoS scenarios are nasty and messy. No matter how you slice it, though, a single misbehaving app should never be able to crash your server.

, , ,

Capriza’s clever mobility via HTML screen scraping

caprizaHTML browser virtualization, not APIs, may be the best way to mobilize existing enterprise applications like SAP ERP, Oracle E-Business Suite or Microsoft Dynamics.

At least, that’s the perspective of Capriza, a company offering a SaaS-based mobility platform that uses a cloud-based secure virtualized browser to screen-scrape data and context from the enterprise application’s Web interface. That data is then sent to a mobile device (like a phone or tablet), where it’s rendered and presented through Capriza’s app.

The process is bidirectional: New transactional data can be entered into the phone’s Capriza app, which transmits it to the cloud-based platform. The Capriza cloud, in turn, opens up a secure virtual browser session with the enterprise software and performs the transaction.

The Capriza platform, which I saw demonstrated last week, is designed for employees to access enterprise applications from their Android or Apple phones, or from tablets.

The platform isn’t cheap – it’s licensed on a per-seat, per-enterprise-application basis, and you can expect a five-digit or six-digit annual cost, at the least. However, Capriza is solving a pesky problem.

Think about the mainstream way to deploy a mobile application that accesses big enterprise back-end platforms. Of course, if the enterprise software vendor offers a mobile app, and if that app meets you needs, that’s the way to go. What if the enterprise software’s vendor doesn’t have a mobile app – or if the software is homegrown? The traditional approach would be to open up some APIs allowing custom mobile apps to access the back-end systems.

That approach is fraught with peril. It takes a long time. It’s expensive. It could destabilize the platform. It’s hard to ensure security, and often it’s a challenge to synchronize API access policies with client/server or browser-based access policies and ACLs. Even if you can license the APIs from an enterprise software vendor, how comfortable are you exposing them over the public Internet — or even through a VPN?

That’s why I like the Capriza approach of using a virtual browser to access the existing Web-based interface. In theory (and probably in practice), the enterprise software doesn’t have to be touched at all. Since the Capriza SaaS platform has each mobile user log into the enterprise software using the user’s existing Web interface credentials, there should be no security policies and ACLs to replicate or synchronize.

In fact, you can think of Capriza as an intentional man-in-the-middle for mobile users, translating mobile transactions to and from Web transactions on the fly, in real time.

As the company explains it, “Capriza helps companies leverage their multi-million dollar investments in existing enterprise software and leapfrog into the modern mobile era. Rather than recreate the wheel trying to make each enterprise application run on a mobile device, Capriza breaks complex, über business processes into mini ones. Its approach bypasses the myriad of tools, SDKs, coding, integration and APIs required in traditional mobile app development approaches, avoiding the perpetual cost and time requirements, risk and questionable ROI.”

It certainly looks like Capriza wins this week’s game of Buzzword Bingo. Despite the marketing jargon, however, the technology is sound, and Capriza has real customers—and has recently landed a US$27 million investment. That means we’re going to see a lot of more this solution.

Can Capriza do it all? Well, no. It works best on plain vanilla Web sites; no Flash, no Java, no embedded apps. While it’s somewhat resilient, changes to an internal Web site can break the screen-scraping technology. And while the design process for new mobile integrations doesn’t require a real programmer, the designer must be very proficient with the enterprise application, and model all the pathways through the software. This can be tricky to design and test.

Plus, of course, you have to be comfortable letting a third-party SaaS platform act as the man-in-the-middle to your business’s most sensitive applications.

Bottom line: If you are mobilizing enterprise software — either commercial or home-grown — that allow browser access, Capriza offers a solution worth considering.

, , , , ,

Big Data Divinations – Your business partner’s book about Big Data

Big Data Divination Pam BakerYou’ve gotta read “Data Divination: Big Data Strategies,” Pam Baker’s new book about Big Data.

Actually, let me change my recommendation. If you are a techie and you are looking for suggestions on how to configure your Hadoop installation or optimize the storage throughput in your NAS array, this isn’t the book for you. Rather, this is the book for your business-side manager or partner, who is looking to understand not only what Big Data is, but really really learn how to apply data analysis to business problems.

One of the challenges with Big Data is simply understanding it. The phrase is extremely broad and quite nebulous. Yet behind the overhyping of Big Data, there are genuine use cases that demonstrate that looking at your business’ data in a new way can transform your business. It is real, and it is true.

Bake is the editor of the “Fierce Big Data” website. She deconstructs the concept by dispensing with the jargon and the, well, overly smug Big Data worship that one finds in a lot of literature and pushed out by the vendors. With a breezy style that reflects her background as a technology journalist, Baker uses clear examples and lots of interviews to make her points.

What will you learn? To start with, “Data Divination” teaches you how to ask good questions. After all, if you don’t ask, you won’t learn anything from all that data and all those reports. Whether it’s predictive analytics or trend spotting or real-time analysis, she helps you understand which data is valuable and which isn’t. That’s why this book is best for the executive and business-side managers, who are the ultimate beneficiaries of your enterprise’s Big Data investments.

This book goes beyond other books on the subject, which could generally be summarized either as too fluffy and cheerleading, or as myopically focused on implementation details of specific Big Data architectures. For example, there is a lengthy chapter on the privacy implications of data gathering and data analysis, the sort of chapter that a journalist would write, but an engineer wouldn’t even think about.

Once you’ve finished with the basics, Baker jumps into several fascinating use cases: in healthcare, in the security industry, in government and law enforcement, in small business, in agriculture, in transportation, in energy, in retail, in manufacturing, and so on. Those are the most interesting parts of the book, and each use had takeaways that could apply to any industry. Baker is to be commended for digging into the noteworthy challenges that Big Data attempts to help businesses overcome.

It’s a good book. Read it. And tell your business partner, CIO or even CEO to read it too.

, , ,

You’ve got 30 seconds. Make the most of it

Graeme WarringThirty seconds. That’s about how long a mobile user will spend with your game before deciding if he or she will continue using it. Thirty seconds. Maybe a minute. If you haven’t engaged the customer by then, forget it.

That’s according to Graeme Warring, COO of 2XL Games LLC, a game startup based in Phoenix. Speaking at an investor conference here today sponsored by AZ TechBeat, Warring explained that while mobile games are exploding, it’s getting harder and harder to make money at it.

One culprit that’s especially true with mobile games is that the new business model is free-to-play. That is, gamers can download the mobile app at no cost. They have, therefore, little or no emotional investment. They might try the game. They might not try it. They might play for 30 seconds or a minute. There’s no sense of guilt to drive them to engage with the software for hours or days, and then be inspired to use in-app payments to improve the gaming experience.

By contrast, consider a console game, such as for Sony’s PlayStation 4 or Microsoft’s Xbox One. A typical game might cost US$60. The gamer has done his/her research before making that purchase. Thanks to the emotional and financial investment, he/she is going to make a serious effort to play that game.

“It’s problem transference,” explained Warring. Who owns the problem of ensuring that the player gives the game a serious try? For an expensive console game, it’s the player’s problem. For a free-to-play mobile game, it’s your problem as the game developer.

Getting the player to engage requires an outstanding initial experience. Don’t require a steep learning curve; the era of preliminary in-game tutorials is long gone. Get the player involved instantly, and make it a fun and rewarding experience. Later, and only later, should you try to monetize through in-app purchases. Whether it’s a new weapon for a shoot-em-up, or grippier tires for a racing game, or more lives and candy and prizes, those become appealing only after the player is hooked and engaged.

Warring and other speakers at the AZ TechBeat conference made the point that the best-selling, top-revenue-producing games come from a small number of firms. They insist, however, that there are tremendous opportunities to make a smaller game, perhaps one that costs less than $5 million to create and market, and to make a profit from the investment.

Marketing is key. Expect to spend as much on marketing as on development, “and be prepared to burn through that budget,” the speakers insisted. That may mean social media; it may mean licensing arrangements. To that end, they suggest that instead of creating your own new brand and attracting a new audience, you may do better licensing an existing brand and a proven audience. Making a motorcycle racing game? License and tie it in with an existing motorcycle event, if you can. Such a tie in might be expensive, but it might bootstrap downloads and maybe even help attract investors.

That, in turn, will buy you 30 seconds. Make the most of it.

, ,

Three first impressions of Apple Watch, Pay-to-Yelp and something old

apple_watchFirst Impressions of the Apple Watch: Surprised that it’s not called the iWatch. The user interface looks surprisingly cool. Distressed that the Apple Watch needs to be charged every day, but if the docking station is sufficiently easy to use, it shouldn’t be a deal breaker.

The watches look like real watches, beautiful as well as functional. The pricing of US$349 and up doesn’t scare me. The long delay for the release—not until early 2015—gives competitors like Motorola and Samsung a great opportunity to respond and seize the initiative. I hope that by the release date, Apple Watch will work with Android phones (and maybe Windows Phone), not only iPhones.

First Impressions of Pay-to-Yelp: The Ninth Circuit Court of Appeals in San Francisco ruled that Yelp did not extort businesses by changing how business reviews appeared on its site based on their advertising status. For example, because Yelp never had any agreement to be impartial in its dealings with Dr. Tracy Chan (a dentist who never bought ads from the company), the judge said:

We begin with Chan, who alleges that Yelp extorted her by removing positive reviews from her Yelp page. Chan asserts that she was deprived of the benefit of the positive reviews Yelp users posted to Yelp’s website, and that, had she received the benefits of the positive reviews, they would have counteracted the negative reviews other users posted. But Chan had no pre-existing right to have positive reviews appear on Yelp’s website. She alleges no contractual right pursuant to which Yelp must publish positive reviews, nor does any law require Yelp to publish them. By withholding the benefit of these positive reviews, Yelp is withholding a benefit that Yelp makes possible and maintains. It has no obligation to do so, however.

This sets a scary precedent that could affect all for-profit businesses that both provide a forum for user feedback and which benefit in some way from that feedback. For example, an electronics reseller will undoubtedly sell more products if the reviews of those products are positive. There is nothing to stop such a reseller from removing negative reviews of products that it wants to sell (such as those that have profit margins or where the manufacturer offers incentives), or removing positive reviews from other products. While I never had much faith in online reviews, whether of books, hotels or big-screen TVs, I will have even less faith in them now.

First Impressions of COBOL: Well, okay, it’s not a first impression, but let us revisit last week’s column, where I talked about job opportunities for young COBOL developers. Kevin Nitert, a 26-year-old developer from the Netherlands, responded, “While it’s very true [COBOL] is easy to learn, the problem is that most companies work directly on the mainframe or ISPF. So learning COBOL is only one part; you have to know about the mainframe environment as well and learn things about JCL and REXX.”

I totally agree and should have talked about the environment. It is easy to learn COBOL on your own or with online training. Picking up the mainframe and environment is much harder. It’s been my experience that employers bringing in employees to work on legacy systems expect to do such training themselves, especially if those employees are young and were hired for their aptitude, not for their specific legacy skills with the platform.

To be honest, it wouldn’t take long to bring newbies up to speed on REXX (Restructured Extended Executor, a sophisticated scripting and job-control language) and ISPF (Interactive System Productivity Facility, a development tool chain for IBM’s z-series mainframes).


Learning COBOL might be a great job move

mag-tapeOnce upon a time, back when dinosaurs roamed the planet, I learned COBOL. While I never wrote any deployed applications in the language, I did use it to teach an undergraduate course in computer science for business majors, back in the early 1980s. Those poor students, who submitted their programs on punch cards for an IBM System/370, complained that the class was the most time-consuming of their undergraduate studies, often requiring lots of late nights at the campus computer center.

Hint: If you are using a card punch, it’s important to have excellent typing skills.

Today, of course, COBOL is more likely to be a punchline. Sure, there was a resurgence of interest in the language about 15 years ago, when everyone was concerned about the Y2K problem. After that, legacy systems running COBOL disappeared from the public eye. Everyone would much rather use Java or C# or Python or Ruby or Objective-C; that’s where the jobs are, right?

Don’t be so quick to discount COBOL, especially if you are looking for a job, or think that you might be some day. There are lots of COBOL applications running all over the world, and more and more COBOL experts are retiring every day.

I’d like to share some information from one of the biggest COBOL vendors: Micro Focus. Bear in mind that Micro Focus’ interest is self-serving, but with that said, I find the information fascinating.

According to the company:

A poll of academic leaders from 119 universities across the world saw more than half (58%) say they believed COBOL programming should be on their curriculum, with 54% estimating the demand for COBOL programming skills would increase or stay the same over the next 10 years. That’s a far cry from today’s reality. Of the 27% confirming COBOL programming was part of their curriculum, only 18% had it as a core part of the course, while the remaining 9% made it an elective component.

The company has a lot of bullet points about COBOL, which I’ll share verbatim:

  • COBOL supports 90% of Fortune 500 business systems every day
  • 70% of all critical business logic and data is written in COBOL
  • COBOL connects 500 million mobile phone users every day
  • COBOL applications manage the care of 60 million patients every day
  • COBOL powers 85% of all daily business transactions processed
  • COBOL applications move 72,000 shipping containers every day and process 85% of port transactions
  • 95% of all ATM transactions use COBOL
  • COBOL enables 96,000 vacations to be booked every year
  • COBOL powers 80% of all point-of-sale transactions
  • There are 200 more COBOL transactions per day than Google + You Tube searches worldwide
  • $2 trillion worth of mainframe applications in corporations are written in COBOL
  • 1.5 million new lines of COBOL code are written every day
  • 5 billion lines of new COBOL code are developed every year
  • The total investment in COBOL technologies, staff and hardware is estimated at $5 trillion
  • An estimated 2 million people are currently working in COBOL

Micro Focus cites lots of sources: The Aberdeen Group, Giga Information Group, Database and Network Journal, The COBOL Report, SearchEngineWatch.com, Tactical Strategy Group, and The Future of COBOL report as sources for those points.

Again, this might mean job opportunities. FedTech Magazine reports:

In March [2014], the Office of Personnel Management released its “Strategic Information Technology Plan,” a vision for revamping the agency’s IT operations, including plans to automate paper-based processes, invest in data analytics and consolidate numerous databases. But maintaining the mainframe hardware and software systems that currently support retirement processes is expensive; according to the agency’s plan, OPM anticipates costs will increases 10 percent to 15 percent annually “as personnel with the necessary coding expertise retire and cannot easily be replaced.”

The United States military agrees. According to Terry Halvorsen, CIO of the Department of the Navy, it is often more cost-effective to maintain COBOL systems than to replace them:

In many cases, however, maintaining an older system that fully supports our mission makes more sense than upgrading it or buying a new system that runs the risk of degrading our mission and requires a large investment. The [Department of the Navy] and industry still use a programming language developed in 1959 to operate major business functions in finance and personnel. In fact, nearly three quarters of the world’s business transactions are done in that venerable language, COBOL. Now with an estimated 200 billion lines of code, it still works. Part of the reason for this is it’s an easy-to-use language, it is fast and it processes data quickly. It is in use worldwide and has proven so stable and reliable that many Fortune 500 companies—Capital One, for example—still hire and train COBOL programmers.

COBOL is easy to learn… and the jobs are there.

, , , ,

They want to steal your data

bankamericard“My name is Patricia from the Bank of America fraud prevention department. This important message is for Mr. Alan Zeichick. We are calling to verify some potentially suspicious activity on your account. It is very important that we speak with you.”

Tuesday’s voicemail from my bank was short and simple. Nobody had pilfered a credit-card receipt or hacked into my account, the representative told me during our conversation. Rather, BofA had been notified by Visa (the credit card clearinghouse) that a retailer had been hacked, and many credit card numbers were stolen. Including mine. As of right now, my card was frozen; the bank will issue me a new card with a new number.

Who was the merchant? According to the BofA representative, Visa didn’t divulge that information due to an ongoing investigation. Nor did the representative know how many credit card numbers were stolen; all she knew what was that BofA was given a list of their bank’s customers who were affected.

These stories are coming far too often. Millions of cards were stolen in 2014 from diverse merchants like P.F. Chang’s China Bistro (a restaurant chain), Michaels Stores (art supplies), Sally Beauty (cosmetics), and Shaws (grocery stores). And those are only a few of the major vendors. Who knows how many smaller card thefts are either never reported, or aren’t deemed sufficiently juicy by the news media?

Some of you might be thinking, “We don’t take credit card numbers on our websites, so there’s no potential risk exposure.” Wrong. I am frequently astonished by the number of companies that maintain lots of customer data, and have that data pilfered. The Payment Card Industry (PCI) standards say that you should never store customer payment information. We’ve all seen that those standards are not followed, sometimes intentionally through neglect, and sometimes through flawed architecture, bad coding or lousy testing.

Let’s be clear: Encrypting browser communications does not protect your customers’ personal or financial information. If you are storing that information anywhere—in your data center, in the cloud—it is at real risk. The threats are active. Are your countermeasures active?

What is even more astonishing is that many of these thefts are of personal information stored on employees’ laptops. You may recall a high-profile case in 2013, where nearly 840,000 Horizon Blue Cross Blue Shield customers had their information compromised when two laptops were stolen from the New Jersey-based health insurance company.

To quote from the Star Ledger’s story,

The stolen laptops were password-protected but had unencrypted data, Horizon said in a statement today. A subsequent investigation determined the computers may have contained files with personal information, including names, addresses, dates of birth, and, in some instances, Social Security numbers and limited clinical information, the insurer said.

How is that possible? No possible scenario should allow customer information to be downloaded onto a desktop or laptop or tablet or phone. Ever. Encrypted or not, the data should never leave the server.

Please tell me you aren’t storing credit card info in files that can be stolen. Please tell me  your company has actively sought to ensure that customer information can never ever ever be downloaded from servers.

Data theft is a nuisance, for cardholders like me, and for businesses like yours. Do you protect your customers’ information?

, , ,

What to do when, not if, your cloud goes down

azure-statusCloud-based development tools are great. Until they don’t work.

I don’t know if you were affected by Microsoft’s Azure service outage on Thursday, August 14, 2014. As of my deadline, services had been offline for nearly six hours. On its status page, Microsoft was reporting:

Visual Studio Online – Multi-Region – Full Service Interruption

Starting 22:45 13 Aug, 2014 UTC, Visual Studio Online customers may have experienced issues with latency and extended Execution times. The initial incident mitigated at approximately 14:00 UTC. During investigation at 13:52 14 Aug, 2014 UTC, engineering teams began receiving alerts for a separate issue where customers were unable to log in to their Visual Studio Online services. From 13:52 to 19:45 on 14 Aug, 2014 UTC, customers were unable to access their Visual Studio Online resources. Engineering teams have validated their mitigation efforts for both issues and have confirmed that full service has been restored to our Visual Studio Online users. These incidents are now mitigated.

My goal here isn’t to throw Microsoft under the bus. Azure has been quite stable, and other cloud providers, including Amazon, Apple and Google, have seen similar problems. Actually, Amazon in particular has seen a lot of uptime and stability problems with AWS over the past couple of years, though its dashboard on Thursday afternoon shows full service availability.

Let’s think about the broader issue. What’s your contingency plan if your cloud-based services go down, whether it’s one of those players, or a service like GitHub, Salesforce.com, SourceForge, or you-name-it? Do you have backups, in case code or artifacts are lost or corrupted? (Do you have any way to know if data is lost or corrupted?)

This is a worry.

In the case of the August 14 outage, the system wasn’t down for long — but long enough to kill a day’s productivity for many workers. Microsoft’s Visual Studio Online blog has a little bit of insight into the problem, but not much. Posted at 16:56 UTC, Microsoft said:

The actual root cause is still under investigation, but initial investigation is indicating a contention in our core database seems to be causing blocking and performance issues in the services. Our DevOps teams have identified a couple of mitigation steps and currently going thru validations. We will provide an update as soon as we have a mitigation in place. We apologize for the inconvenience and appreciate your patience while working on resolving this issue

This time you can blame Microsoft for any loss of productivity. Next time the service goes down, if you haven’t made contingency plans, the blame is yours.

, , , ,

For your customers, support low- and intermittent-bandwidth mobility

four-cornersWe drove slightly more than 2,500 miles (4,000 kilometers), my wife and I, during a weeklong holiday. We explored different states in the western United States: Arizona (where we live), Colorado, New Mexico and Wyoming. The Rocky Mountains are incredible. Most of our vacation was at altitudes above 6,000 feet (1,800 meters). Many of the mountain peaks were above 14,000 feet (4,200 meters), and one road went above 11,000 feet (3,300 meters). Exciting!

The adventure involved bringing only smartphones, one running Android, one running iOS. We used mobile apps for navigation, for communication, for photography, for reading, for social media, for finding hotels and restaurants, just about everything.

We learned that apps only seem to run well when there is copious bandwidth, either WiFi at a hotel or a fast cellular data link. If a smartphone registered 4G or LTE, all was good. If the phone indicated that the connection was EDGE, GPRS or 3G, all bets were off. It’s not that data loaded slowly. That would be expected. It’s that the apps would crash, or time out, or posting data would fail, or nothing would happen at all. Many modern apps expect or demand lots and lots of bandwidth.

I’m not talking here about apps running completely offline. That’s an entirely different conversation. I’m talking about apps not gracefully handling situations where the bandwidth is narrower than a drinking straw.

Many developers test out their mobile apps using simulators. That, or on devices that have very high bandwidth connections, such an office WiFi network or the type of high-speed network that you’ll find in Silicon Valley, New York City, or other major tech hubs around the world. Having lots of mobile bandwidth is undoubtedly a blessing for developers, but for many consumers, that’s simply not the case.

Lots of customers live in areas with poor bandwidth, or find themselves traveling in places where connectivity is slow or intermittent. Given the use cases for mobile devices—that is, they are frequently used when not at home or in an office—optimizing apps for bad bandwidth should be mandatory. Hey, this isn’t about streaming 1080p movies. This is about being able to use a search engine, or call up a map, or be able to find a hotel room.

Will people use your apps in poor-bandwidth or intermittent-bandwidth situations? If so, here are some steps you can do to improve the user experience:

  1. Make sure that part of your testing involves low-bandwidth and intermittent-bandwidth scenarios. Find beta testers who live with poor bandwidth or who travel to such locations.
  2. Have your app test for throughput, and not only at application launch. Merely detecting whether the connection is WiFi or cellular is insufficient. If throughput is low, consider degrading the experience, such as by using lower-end graphics, in order to keep data moving.
  3. Cache, cache, cache.
  4. Don’t insist on reloading data each and every time the user either launches the app or switches to it. Alan’s pet peeves include news and other websites that freeze the UI while loading the latest headlines or content each time the app is brought to the foreground.
  5. If you detect that the device is in a low-bandwidth environment, pause background data syncing, or at least ask the user if he/she would like to do so.
  6. If you are sending audio or video, compress the heck out of it. That may involve choosing different algorithms for different bandwidth situations, with low-bandwidth scenarios using narrower and lossier codecs.
, , ,

Look to the intranet for shared corporate data — it’s a Big Data problem

Microsoft-SharePoint-Foundation-2010-logoWhere do your employees go to find shared data? If it’s external data, probably an external search engine, like Google (which apparently holds 67.6% of the U.S. market) or Bing (18.7%) or one of the niche players.

What about internal corporate data? If your organization uses a platform like Microsoft’s SharePoint, that platform includes a pretty robust search engine. You can use SharePoint to find documents stored inside the SharePoint database, or external documents linked to it, and conversations and informal data hosted by SharePoint. If you are familiar with a product called FAST, which Microsoft acquired in 2008, SharePoint’s search contains some elements of FAST and some elements of Bing. It’s quite good.

What if you are not a SharePoint shop, or if you are in a shop that hasn’t rolled SharePoint out to every portion of the organization?  You probably don’t have any good way for employees to find structured and unstructured documents, as well as data. You’ve got information in Dropbox. In Box.com. In Lotus Notes, maybe. In private Facebook groups. In Yammer (another Microsoft acquisition, by the way). In Ribose, a neat startup. Any number of places that might be on enterprise servers or cloud services, and I’m not even talking about the myriad code repositories that you may have, from ClearCase to Perforce to Subversion to GitHub.

All of those sources are good. There are reasons to use each of them for document sharing and collaboration and source-code development. That’s the problem. Like the classic potato chips advertisements say, you can’t only eat one.

Even in a small company, the number of legitimate sharing platforms can proliferate like weeds. As organizations grow, the potential places to stash information can grow exponentially, especially if there is a culture that allows for end users or line-of-business departments to roll out ad hoc solutions. Add mobile, and the problem explodes.

This is a governance problem: How do you ensure that data is accounted for, check that external sharing solutions are secure, or even detect if information has been stolen or tampered with?

This is a productivity problem: How much time is wasted by employees looking for information?

This is a business problem: How much money is wasted, or how much work must be duplicated or redone because data can’t be found?

This is a Big Data problem: How can you analyze it if you can’t find it?

The answer has to be a smarter intranet portal. In a recent essay by the Nielsen Norman Group, usability experts Patty Caya and Kara Pernice write that “Intranet portals are the hub of the enterprise universe.”

The trick is to discover it, index it, and make it available to authorized users—without stifling productivity. That includes data from applications that your developers are creating and maintaining.

, , , ,

Microsoft’s bold ambition scares me

satya-nadellaMicrosoft has evolved considerably. It’s moved from its early days selling developer tools, or its era focusing on Windows and Office, or its run as a server software maker, or its first iteration as a cloud/online services company. Despite all the myriad changes, it’s always been true that Microsoft does not excel at innovation.

In fact, when the company focuses on innovation, it often misses with its products and pricing. Features are implemented badly, bugs proliferate, messages are muddled and strategy appears non-existent.

This confuses customers, annoys developers and frustrates partners.

When, by contrast, Microsoft focuses on execution, it does much, much better. Software and services are about getting the details right, and that means understanding the customers, not slamming out a bewildering product that has state-of-the-art technology but doesn’t make sense to anyone.

This is true whether you are talking about operating systems like Windows, or back-end products like Bing or SharePoint, or mobile phones. The new, innovative, visionary, ground-breaking products (or product upgrades) nearly always disappoint.

Reading new CEO Satya Nadella’s letter to his employees, I am concerned that Microsoft doesn’t understand that customers want excellent products. That means execution more than it means innovation.

Nadella’s letter, called “Bold Ambition & Our Core,” was published on July 10. Right up front, Nadella says, “The day I took on my new role I said that our industry does not respect tradition – it only respects innovation.”

That scares me. I think he misses the point.

Nadella writes,

At our core, Microsoft is the productivity and platform company for the mobile-first and cloud-first world. We will reinvent productivity to empower every person and every organization on the planet to do more and achieve more.

What does it mean to reinvent productivity? I’m sure it means more than carrying around a Microsoft Surface Pro 3 device that tries to be both a notebook computer and a tablet, but doesn’t truly succeed in either configuration.

Nadella continues,

Productivity for us goes well beyond documents, spreadsheets and slides. We will reinvent productivity for people who are swimming in a growing sea of devices, apps, data and social networks. We will build the solutions that address the productivity needs of groups and entire organizations as well as individuals by putting them at the center of their computing experiences.

It’s a beautiful concept – but so far, Microsoft’s bread and butter has been specifically documents, spreadsheets and slides. Is he talking about SharePoint and Yammer?

In the 3,000-word missive, Nadella spends a lot of time talking about specific areas. He talks about “digital work and life experiences,” which are productivity enhancers designed for the mobile-first and cloud-first world. He talks about context-rich connections between experience, such as with the Cortana app on Windows Phone. He talks about the cloud, where

the combination of Azure and Windows Server makes us the only company with a public, private and hybrid cloud platform that can power modern business. We will transform the return on IT investment by enabling enterprises to combine their existing datacenters and our public cloud into one cohesive infrastructure backplane.

Nadella also talks about Xbox:

The single biggest digital life category, measured in both time and money spent, in a mobile-first world is gaming. We are fortunate to have Xbox in our family to go after this opportunity with unique and bold innovation. Microsoft will continue to vigorously innovate and delight gamers with Xbox.

What’s missing from Nadella’s call-to-arms letter? You won’t read much specifically about Windows Phone, about notebooks and desktop computers, about desktop Windows, or even traditional Office.

You also didn’t see much about execution, about delivering excellent products. All I read is innovate, innovate, innovate. Ideas are nice, Mr. Nadella, but I’d like to see a company that actually delights its customers, instead of frustrating them with its latest upgrades.

, , ,

Developer programs are a good investment in your employees

OTN-Tour-2014-370x395If your developers aren’t enrolled in developer relations programs, they will grow old and stale. They will become moldy. They will pine for the Good Old Days and opine endlessly about the irrelevance of new tools, new platforms, new paradigms and new ideas. No matter their brilliance today, they will become obsolescent.

You can’t let that happen!

Developer relations programs are all over the map, literally. Some are focused on operating systems – see those from Apple and Microsoft. Some are about back-end platforms, like programs from IBM or Oracle. Some are tied to very specific products.

It’s hard to know where your developers will get the best value. Let’s take a very simplistic case. If you have a bright programmer who is working to integrate back-end Oracle databases with Windows servers, should she be a member of the Oracle Technology Networkor MSDN? Likely both; it doesn’t hurt to sign up. But where should she spend her time?

It’s tricky to make that call, and it largely depends on both the developers’ self-starter motivation and your own corporate culture. Some developer programs are free, but others aren’t, with prices ranging from a hundred dollars per year to thousands of dollars. Do you offer to cover the costs of belonging to the developer program for each architect, designer, coder or tester who wants to sign up – or do they have to go through hoops that send out the message that the programs aren’t important (or that the employee isn’t worth the investment)?

Let’s say that you are running a Windows shop, and being a Windows Server guru is seen as essential for career growth. Clearly, your bright programmer should grow and enhance her skills as a Windows expert. While deep Oracle expertise is essential, it might be a secondary investment for her time.

Of course, if your team is seen as an Oracle shop, and the Microsoft aspect is seen as secondary, she should invest her time in Oracle technologies.

The scenario above is too simple. There’s no reason that the bright programmer can’t participate in two developer programs. However, what’s a reasonable ceiling. Two? Three? Five? Ten? If developers spread themselves out too thin, it’s hard to gain deep expertise. To my mind, a developer should engage with 3-5 development programs; probably no more. Depending on the situation, though, perhaps only one or two would be appropriate. If you have a developer who doesn’t see any benefit in belonging to a developer relations program, look at where he or she is spending time. There may be local user groups that provide the same level of engagement. But if you have someone who doesn’t want to engage at all in the larger world beyond his or her team — who doesn’t see the value of building deep expertise in products or platforms — you should be concerned.

Early in 2014, the market research firm Evans Data Corp. conducted a study on developer relations programs. They asked developers, “What most motivates you to seek solutions from developer programs?” The answers should not surprise anyone:

  • 35.5%: Need to upgrade from existing, outdated technology
  • 24.3%: Present skillset is insufficient
  • 21.7%: Present toolsets are insufficient
  • 8.5%: Anticipating future problems
  • 6.3%: Need to match or beat competition
  • 3.8%: Other

I’d keep an eye on those who answered “present skillset is insufficient.” Those employees are investing in themselves — and they are going places!

, , , , , ,

The future of computing: Android Everywhere

googletvGOOGLE I/O 2004, SAN FRANCISCO — What is Android? It’s hard to know these days, and I’m not sure if that’s good or not. We all know what happened when Microsoft began seeing Windows as a common operating system for everything from embedded systems to desktops to phones to servers. By trying to be reasonably good at everything, Windows lost its way and ceased being the best platform for anything.

Once upon a time, Android was a free operating system for smartphones, conceived of as a rival for Symbian and (believe it or not) Windows Mobile. Google purchased Android Inc. in 2005; the Open Handset Alliance launched in 2007; and the first smartphone running Android appeared in 2008. Today, Android-based phones dominate the market, with the most visible handset makers being Samsung and LG. Some estimates show that at the end of 2013, more than 81% of all smartphones were running Android.

From its origins in smartphones, it was natural that Android would expand to tablets. Although no Android tablet has emerged as a clear market leader, there are many manufacturers, from Samsung to Amazon to Google to Asus. While Android has decisively eclipsed Apple’s iPhone in the smartphone market, the iPad still defines tablets.

What else? Android is now an operating system for head-mounted displays, smartwatches, wearables, televisions and automotive entertainment systems.

We’re all familiar with Google Glass, which is based on Android. The company is working hard to recruit developers to build Glassware. This spring, Android announced Android Wear, which is described as “your key to a multiscreen world,” especially if one of those screens will be a smart watch. A few companies, including LG, Samsung and Motorola, have announced watches.

Remember Google TV? It was not a success in the market. The replacement, announced this week here at the annual Google I/O developer conference, is called Android TV. According to Google, “Thousands of apps in the Google Play Store are already optimized for TVs.”

Google is clearly interested in cars, and not only because it wants to build self-driving vehicles. A few aftermarket audio system makers have used off-the-shelf Android as the driver in replacement automotive head units. This week, Google announced Android Autoas a competitor to Apple’s iOS-focused CarPlay. As with smartphones, Google set up a vendor alliance — in this case, the Open Automotive Alliance — to developer industry specifications and to drive alliances with car manufacturers.

From the looks of things, Android is now intended to become a general-purpose operating system. Good for embedded, small-footprint, app-based, highly connected devices.

Google’s emphasis, though, isn’t on the hardware, but on that increasingly multiscreen world. With screens spanning the wrist, phone, tablet, head-mounted displays and televisions, Android looks to be everywhere. And that means that Google Play will be everywhere. Thus Google advertisements everywhere too. I mean, duh.

I guess that’s the future of computing: Android Everywhere.


Don’t sign the non-compete agreement

gold-handcuffAre you covered by a non-compete agreement at your current employer? Are your workers covered by a non-compete? While non-competes may make your executives (and their attorneys) feel good, they may not be good for your company.

Non-compete agreements restrict where you can work after you leave your current employer. They might lock you out of taking another job in your industry for years—agreements of even up to five years are not uncommon. Of course, non-competes can dissuade competitors from recruiting you while you are still working. That’s not all: They could also scare away potential employers even if you lose your job due to a layoff or involuntary termination.

By restricting the free flow of employees from company to company, non-compete agreements limit employment options. They also can cut down on a vibrant culture of innovation and startups.

Why have non-compete agreements? One argument is that employers invest in hiring and training their employees, and don’t want to have those employees, once trained, snatched up by competitors. Another is that by virtue of their jobs, employees have access to intellectual property, and that the non-compete stops competitors from gaining ready access to that IP.

As you can imagine, information technology workers, including software developers, are often seen as key strategic assets and may find non-compete agreements a necessary evil. Programmers aren’t the only folks locked in by non-competes, though. A recent story by Steven Greenhouse in the New York Times, “Noncompete Clauses Increasingly Pop Up in Array of Jobs,” talked about a Boston-area teenager who couldn’t work at a summer camp in 2014 because the camp she worked at in 2013 had a 12-month non-compete agreement. Ugh.

Some states, including California, give more protections to employees than to employers, and non-compete agreements are often unenforceable. Some analysts believe that this worker-friendly environment contributes to the vitality of the area’s tech economy—see Sharon Wienbar’s blog post, “The Power of a Fluid Market: Employee Mobility Makes Silicon Valley Flow.”

Wienbar writes

A non-compete isn’t the only reason why the abundance of VC $$ remain in Silicon Valley but it is an important item to consider. In the technology landscape, talent can make or break a business and the more fluid the resources, the better the chance of building a viable business.

Other states are friendlier to business and uphold non-compete agreements. I would not like to work in that environment, personally. I’m not a fan of non-compete agreements and have never signed one or asked an employee to sign one. However, I recognize that in some locations, and in some companies, that’s the only way to get the job you want at the company you want.

Compelling arguments against such agreements are plentiful. Read Jeff Haden’s, “The Case Against Non-Compete Agreements,” published in Inc.; “Time to get rid of ‘noncompete’ agreements” by the Boston Globe’s Scott Kirshner; and Jon Zemke’s “To Compete or Non-Compete: Contracts That Make Michigan Less Competitive,” in Concentrate.

, ,

Forget Big Data and worry about Bad Data

bad-dataTwo consulting projects this year have involved lots and lots of data. One was the migration of a very complex customer database and transaction logging system to a cloud-based CRM platform from a homegrown system. The other involved performing serious analytics on a non-profit’s membership system that had data spanning decades.

Both projects required incredible manual intervention in the data processing. Data came from different original sources and had wildly varying schemas. Some data was relational, and some was flat-file. Some of the data was clearly contradictory. Timestamps were missing on records. Valuable data was stored in comment fields. Documentation didn’t exist. Keys were lost. Fields were abandoned. Live data was mixed with archival data.

Both systems were a mess—but that wasn’t the problem. The issues I’m describing are the everyday result of messy software, evolving databases and the real world. Solving those challenges takes some effort, but we all know the importance of factoring data cleansing into any type of migration or analytics project, both in terms of time and of finances.

The real challenge is that most of the data was totally wrong. No resemblance to reality. That person never lived at that address. The relationships in the SQL database were not correct. Conventions were nonexistent. When data is being collected by many systems—and stored in many systems—over years and decades, this is what happens.

Yes, both projects were successful. However, we had to throw away a lot of data that would have added value to the organizations and their customers or members. Worse, we learned that both organizations had been using bad data for years, resulting in missed opportunities, less-than-ideal customer service, and flawed business planning.

Garbage in, garbage out. After all, if you are thinking about offering a new product or service, and are basing your decisions on bad data, you aren’t making a good decision. You are guessing.

What went wrong? It wasn’t in the migration and analytics projects. We went in, cleaned up the data best we could, and got out. It was a finite task and went as well as could be expected.

The root causes weren’t bad programming either, or poor database administration. In many IT shops, schemas change. Documents are lost. Corruption happens. Ideas are tried and abandoned. That’s simply what happens when data is kept past its sell-by data.

The failure is that nobody regularly (or ever) checked the data to make sure that it’s still good. Nobody performs period data hygiene. Nobody tested addresses, or eyeballed records to see if they made sense, or validated the databases against other sources (or even against themselves).

Data is a valuable corporate asset. In fact, when it comes to customer data and transaction records, data may be the single biggest asset of your company. Most companies work hard to ensure that their assets are solid. A manufacturer checks its raw materials and finished goods to ensure that they are as expected. Materials in warehouses are inventoried. Random samples are pulled from time to time, tested, and examined carefully.

When it comes to data, long-term quality is rarely a consideration. Data is stored and used. Is it checked? Rarely, if ever. We all know the benefits of Big Data for our business. What about the costs of Bad Data? Unknown, but real. I’ve seen this time and again. As Bad Data is used and reused, it will only get worse.

, , ,

It’s time to learn Swift

swift-chris-lattnerSAN FRANCISCO — I expected a new version of OS X, the operating system for Mac desktops and notebooks. I expected a new version of iOS, the operating system for iPhones and iPads. I did not expect a new programming language. Yet that’s what we got at Apple’s Worldwide Developers Conference, held here this week. And I’m delighted.

Along with the previews of OS X 10.10 “Yosemite” and iOS 8, Apple showed Swift, a language that runs inside its familiar Xcode integrated development environment.

Swift is designed primarily for safety. As Apple puts it:

Swift eliminates entire classes of unsafe code. Variables are always initialized before use, arrays and integers are checked for overflow, and memory is managed automatically. Syntax is tuned to make it easy to define your intent—for example, simple three-character keywords define a variable (var) or constant (let). The safe patterns in Swift are tuned for the powerful Cocoa and Cocoa Touch APIs. Understanding and properly handling cases where objects are nil is fundamental to the frameworks, and Swift code makes this extremely easy. Adding a single character can replace what used to be an entire line of code in Objective-C. This all works together to make building iOS and Mac apps easier and safer than ever before.

Obviously we have not had a chance to work with Swift directly. However, it appears to be a very easy language to learn, especially for developers who are used to Objective-C. It’s designed for Apple’s Cocoa and Cocoa Touch libraries, is built with the familiar and stable LLVM compiler, and creates the same runtime as Objective-C.

Apple says Swift programs are fast. The company claims that a complex object sort will run in Objective-C about 2.8x faster than in Python. But if you use Swift, it runs 3.9x faster.

Learn more about the Swift announcement, as well as a ton of new APIs, in Rob Marvin’s article, “Apple announces Swift programming language, new SDK and developer features at WWDC.”

A neat feature of Swift is what Apple calls “playgrounds,” where you can see how the code runs as you write it—without building a new version. That’s cool. Swift isn’t ready yet, but you can check out Apple’s preliminary documentation, including a tour and language guide.

Swift is a cross-platform language, if you define “cross platform” to mean “both of Apple’s platforms.” Yes, you can use Swift to write apps for OS X and for iOS, and because it creates the same runtimes as Objective-C, you should be able to run Swift applications on older versions of those operating systems, not only OS X 10.10 and iOS 8. What you can’t do, and probably never will do, is run Swift apps on competing platforms. No Android, no Windows Phone. Given that the language does target the Cocoa and Cocoa Touch libraries, that’s clearly no surprise.

Most mobile app developers already target iOS first, even though there are more Android devices than iPhones and iPads. Swift won’t change that, and in fact it will likely make iOS development even more attractive.

On the desktop/notebook side, developers writing native software probably target Windows first because of the huge installed base of machines. It’s unlikely that Swift will change behaviors there. But then again, writing desktop/notebook software truly is becoming a niche activity.

, , ,

Git control of your software development assets

gitThere are lots of reasons to use Git as your source-code management system. Whether used as a primary system, or in conjunction with an existing legacy repository, I’m going to argue that if you’re not using Git now, you should be at least testing it out.

Basics of Git: It is open source, and runs on Linux, Unix and Windows servers. It is stable. It is solid. It is fast. It is supported by just about every major tool vendor. Developers love Git. Managers love Git.

Not long ago, much of the world standardized on Concurrent Versions System (CVS) as its version control system. Then Subversion (SVN) came along, and the world standardized on that. Yes, yes, I know there are dozens of other version control systems, ranging from Microsoft’s Visual SourceSafe and Team Foundation Server to IBM Rational’s ClearCase. Those have always been niche products. Some are very successful niche products, but the industry standards have been CVS and SVN for years.

Along came Git, designed by Linus Torvalds in 2005, now headed up by Junio Hamano. For a brief history of Git, read “The Legacy of Linus Torvalds: Linux, Git, and One Giant Flamethrower,” by Robert McMillan, published in Wired in November 2012. For the official history, see the Git website.

What’s so wonderful about Git? I’ll answer in two ways: industry support and impressive functionality.

For industry support, let me refer you to two new articles by SD Times’ Lisa Morgan. Those stories inspired this column. The first is“How to get Git into the enterprise,” and the other is “Git smart about tools: A Buyers Guide.” You’ll see that nearly every major industry player supports Git—even competing SCM systems have worked to ensure interoperability. That’s a heck of an endorsement, and shows the stability and maturity of the platform.

Don’t take my word for it for the impressive functionality. Instead, let me quote from other bloggers.

Tobias Günther: “Work Offline: What if you want to work while you’re on the move? With a centralized VCS like Subversion or CVS, you’re stranded if you’re not connected to the central repository. With Git, almost everything is possible simply on your local machine: make a commit, browse your project’s complete history, merge or create branches… Git lets you decide where and when you want to work.”

Stephen Ball: “Resolving conflicts is way easier (than SVN): In Git, if I have a private branch from a branch that has been updated with new (conflicting) commits, I can rebase its commits one at a time against the public destination branch. I can resolve conflicts as they arise between my code and the current codebase. This makes dealing with conflicts easy because I get the context of the conflict (my commit message) and only see one conflict at a time.

“In SVN if I merge a branch against another and there are a lot of conflicts, there’s nothing I can do but resolve them all at the same time. What a mess.”

Scott Chacon: “There are tons of fantastic and powerful features in Git that help with debugging, complex diffing and merging, and more. There is also a great developer community to tap into and become a part of and a number of really good free resources online to help you learn and use Git…

“I want to share with you the concept that you can think about version control not as a necessary inconvenience that you need to put up with in order to collaborate, but rather as a powerful framework for managing your work separately in contexts, for being able to switch and merge between those contexts quickly and easily, for being able to make decisions late and craft your work without having to pre-plan everything all the time. Git makes all of these things easy and prioritizes them and should change the way you think about how to approach a problem in any of your projects and version control itself.”

Nicola Paolucci:
“If you don’t like speed, being productive and more reliable coding practices, then you shouldn’t use Git.”

Peter Cho: “Most developers would be delighted if they can change their workflow to use Git. Switching over early would be more ideal unless, of course, your SCM relies on a large network of dependent applications. If it’s not viable to change SCM systems, I would highly recommend using it on future projects.

“Git is infamous for having a large suite of tools that even seasoned users need months to master. However, getting into the fundamentals of Git is simple if you’re trying to switch over from SVN or CVS. So give a try sometime.”

Thomas Koch: “Somebody probably already recommended you to switch to Git, because it’s the best VCS. I’d like to go a step further now and talk about the risk you’re taking if you won’t switch soon. By still using SVN (if you’re using CVS you’re doomed anyway), you communicate the following: We’re ignorant about the fact that the rest of the (free) world switched to Git. We don’t invest time to train our developers in new technologies. We don’t care to provide the best development infrastructure. We’re not used to collaborate with external contributors. We’re not aware how much Subversion sucks and that Subversion does not support any decent development process. Yes, our development process most certainly sucks too.”

Günther also wrote, “Go With the Flow: Only dead fish swim with the stream. And sometimes, clever developers do, too. Git is used by more and more well-known companies and Open Source projects: Ruby On Rails, jQuery, Perl, Debian, the Linux Kernel, and many more. A large community often is an advantage by itself because an ecosystem evolves around the system. Lots of tutorials, tools (do I have to mention Tower?) and services make Git even more attractive.”

I’m sure there are arguments against Git. Nearly all the ones I’ve heard have come to me via competing source-code management vendors, not from developers who have actually tried Git for more at least one pilot. If you aren’t using Git, check it out. It’s the present and future of version control systems.