Today, let’s do something different. Instead of offering up my own opinions, I’ll let others hang themselves with their own words. Suffice it to say, test your software fully before shipping it out. These aren’t kids cloistered away in their bedrooms building apps for fun; these are commercial developers. Have comments on this? Well, sure you do — you’re a software developer, too. What do you think? Join the discussion; we’d like to hear from you.
Adobe royally messes up this week’s updates to Lightroom (desktop) and Lightroom CC (cloud).
In an effort to simplify the process of importing images from camera into the Lightroom database, well, it’s broken. Broken so badly the various photography forums are ablaze with anger. Today (Fri., Oct. 9, 2015), in the Adobe Lightroom Journal, branded as “tips and advice straight from the Lightroom team,” Adobe’s Tom Hogarty, writing on behalf of the Lightroom Management Team, falls on his sword:
Lightroom 6.2 Release Update and Apology
I’d like to personally apologize for the quality of the Lightroom 6.2 release we shipped on Monday. The team cares passionately about our product and our customers and we failed on multiple fronts with this release. In our efforts to simplify the import experience we introduced instability that resulted in a significant crashing bug. The scope of that bug was unclear and we made the incorrect decision to ship with the bug while we continued to search for a reproducible case(Reproducible cases are essential for allowing an engineer to solve a problem). The bug has been fixed and today’s update addresses the stability of Lightroom 6.
The simplification of the import experience was also handled poorly. Our customers, educators and research team have been clear on this topic: The import experience in Lightroom is daunting. It’s a step that every customer must successfully take in order to use the product and overwhelming customers with every option in a single screen was not a tenable path forward. We made decisions on sensible defaults and placed many of the controls behind a settings panel. At the same time we removed some of our very low usage features to further reduce complexity and improve quality. These changes were not communicated properly or openly before launch. Lightroom was created in 2006 via a 14 month public beta in a dialog with the photography community. In making these changes without a broader dialog I’ve failed the original core values of the product and the team.
The team will continue to work hard to earn your trust back in subsequent releases and I look forward to reigniting the type of dialog we started in 2006.
Epicurous, the foodie website, messes up its mobile apps beyond repair. The apps have to be completely withdrawn. Really.
Read portions of what Eric Gillin, executive director of Epicurious, writes on the Epicurious website on Tues., Oct. 6, 2015 (excerpted):
Important Announcement for All Epicurious App Users
If you’re using our app on Apple or Windows, it’s critical you upgrade it immediately. If you’re using it on another platform, sadly, we no longer support those apps. Read on for more information.
Effective immediately, our apps for Apple and Windows will no longer work unless you update them. On that same date, our apps for Android, Nook, and Kindle will stop working properly.
IF YOU USE THE EPICURIOUS APP ON APPLE OR WINDOWS TABLETS OR PHONES
You must update the Epicurious app. Upgrading your app is critical. It will no longer work properly if you remain on an older version. If you’re unable to install the update for some reason, you can still view our recipes — and your recipe box — right here on our website.
IF YOU’VE BEEN USING THE EPICURIOUS APP ON ANDROID, KINDLE, OR NOOK DEVICES
These apps will no longer work properly. Because we can no longer support these apps, we will be removing them from stores. We’ll be working to create new versions that include all of the functionality you’ve come to expect from us.
We’re deeply sorry if this causes frustration. We’re doing this because we want to make sure that we offer the best possible experience and sadly, it’s no longer possible for us to support older devices and every single platform.
Do I need to say anything else? What do you have to say?
You’d think we’re in a cycle where the number of cloud applications in enterprises is on a steady increase. I would have thought that, too. After all, the rush to decimate legacy IT has turned into something of a drag race. But, according to one study, we’d be wrong.
In its summer 2015 quarterly cloud report, the cloud-enablement firm Netskope reports that the average number of cloud apps used per enterprise declined for the first time. The company ascribes the decline to consolidation efforts from IT beginning to take hold.
To be a bit more specific, the report from the Los Altos, Calif. company notes the average number of apps used within enterprises declined from 730 in its first-quarter 2015 report to 715 in the second quarter. This marks the first time a decline has been seen, according to the company.
Why is this happening? The report says “enterprises are beginning to consolidate apps, especially those in the marketing, collaboration and productivity categories.”
That last statement suggests that enterprises are moving to a model of fewer, bigger, more-comprehensive apps that each do more. Call me naïve, but I would have thought it equally reasonable to go the other way — more apps that are each highly focused and specialized.
What is happening with the number of apps in your enterprise cloud? Which way should the enterprise app pendulum swing? Fewer apps that do more or more apps that specialize? It’s an intriguing topic for a lively discussion. Share your thoughts, we’d like to hear from you.
Let’s do some supposin’.
Suppose you work for a giant, global manufacturer. The company might make air conditioners. Or diesel-powered cars. Suppose you’re given detailed specifications for an embedded software project that disguises the operating status of a product being designed. Suppose the purpose of that application is to underreport the electricity consumed by that air conditioner.
Or — and this just might be the wackiest idea ever — suppose the purpose of the software is to surreptitiously shift a car’s diesel engine into a low-pollution “clean” mode while the engine is running and sensors detect that the steering wheel isn’t being moved and the wheels aren’t rotating. That would present artificially low levels of exhaust pollutants and particulates to environmental test equipment. I know, who could ever dream up such an outlandish, ridiculous scheme? It would be scandalous on an international level.
Here’s the tough question: What would you do if tasked with coding such a program?
You might keep your mouth shut, write the code, grin, and deposit your hefty paycheck. You might become a whistleblower and contact the authorities or the media. You might rationalize the situation and conclude you were just following orders. Perhaps your conscience might drive you to quit and find employment elsewhere. You might even write a time bomb into the code that prevents a car from shifting into low-pollution test mode. What would you do?
As a software developer, are you bothered by the premise of building apps designed to deceive? Have you ever been asked to this? Share your opinions, we’d like to hear from you.
Whatever language(s) you happen to use for coding applications and services, there’s no doubt that you are among the world’s best it. You’ve got the skill, the talent, the insight, and the brains to write efficient, compact code that runs flawlessly.
But, from what program specifications or documentation are you building these apps? Call me a mainframe-era dinosaur, but not a line of code written until at least two processes happened.
First, a business systems analyst interviewed stakeholders and translated their tales of woe into a clear, logical, unambiguous, easily followed set of requirements. That’s essential, because users rarely know what they want. (You agree with that, right?) When a department pleaded with IT (still called MIS in those days) for a new report, the savvy business analyst knew to look beyond the report request for fundamental process shortcomings. Generating a report, after all, is merely treating a symptom, not the underlying disease. It wasn’t unusual — at least if you were fortunate enough to have a really good analyst — for that one report request to eventually become a system that simultaneously solved a dozen seemingly unrelated problems.
Second, the business requirements document, following reviews, revisions, and sign-offs by all stakeholders — which magically transforms them into owners — was handed off to a systems analyst. It was this person’s job to translate the business requirements into a set of functional specifications, logical statements and if-then structures that programmers (not yet called developers) turned into actual program code.
Done right, this process, though glacially slow and deliberate, was often a thing of beauty, with buy-ins and approvals every step of the way. There could be no room for stakeholder/owners to complain that the delivered system was not what they wanted.
Today, things are very different. We don’t have months. New apps, systems, and user interfaces must be designed, built, tested, and deployed in a matter of weeks. Infrastructure is as much a part of system design as the software itself. Where everything once ran on the machines down the hall, today, your apps run, well, somewhere. You’re calling on data from multiple sources, integrating data and processes on the fly, and delivering the results to potentially millions of devices owned by completely nameless, anonymous users.
That brings me back to the original question. When a project for a new application or system is dropped in your lap, what do you use as the specifications basis for writing code and designing an architecture? Does your organization have analysts who create detailed business and logical requirements? Are you instead saddled with this responsibility, and if so, do you know the business well enough to do a comprehensive job? Does someone have a chat with you over coffee and attempt to explain what he or she wants?
Share your experiences, good or bad, about defining app and systems requirements. We’d like to hear from you.
Yesterday (Sept. 24), I attended a cloud summit seminar sponsored by the Object Management Group’s Cloud Standards Customer Council. This was not about scrutinizing lines of code, but rather, an examination of real-world situations as seen through the eyes of cloud consultants, architects, and select major vendors.
What I learned could have come from the mind of Forrest Gump, who famously said, “Stupid is as stupid does.”
David Linthicum, senior vice president at Cloud Technology Partners and a TechTarget contributor, was the first to say it: “If you take a crappy application that exists on a platform internally and put it in the cloud, it’s just a crappy application in the cloud.”
In her presentation, Pamela Wise-Martinez, senior enterprise architect at the Pension Benefit Guaranty Corporation, hammered home the same point. “You’ve got to see how cloud-ready your applications are. If it’s a crappy application and you put it in the cloud, it’s still crappy. You’ve got to make intelligent decisions about what goes to the cloud.”
In other words, crappy is as crappy does.
Sure, we all want to move everything, or nearly everything, into the cloud. These speakers, though, are making a couple of important points. First, some applications, not matter how well built, simply don’t belong in the cloud. That might be factory floor process control or retail back-room administrative functions. Second, applications that would benefit from being in the cloud might be built in a way that makes them cloud unfriendly. If you want the functionality of those apps in the cloud, the existing code base may need to be thrown out and replaced with something else.
What’s your plan for moving on-premises, legacy applications into the cloud? Have you figured out which apps are good candidates and which are not? Or did you learn the hard way, only after attempting a migration? Share your thoughts, we’d like to hear from you.
Sometimes the best ideas start with a rant. At least that’s what happened to Mallika Iyer, a Cloud Foundry specialist at Pivotal who helps clients either start or expand their cloud efforts. After a particularly frustrating day, Iyer was complaining to her partner about the mistakes that clients seemed to make over and over again. His advice: make it a speech.
So last week attendees at Boston’s 2015 DevOps Days got to hear Iyer explain “Cloud Anti-Patterns,” which are a collection of five areas cloud implementations can go wrong. It’s good practical advice for anyone in the cloud space.
1. Ignoring the sweet spot: The sweet spot is a platform as a service or PaaS offering that can make all of the many moving parts of cloud adoption so much easier, Iyer explained. “Companies start on their journey and they think you need one tool to manage microservices, one to manage containers and one (or more) for continuous integration (CI) and continuous development (CD) tool sets,” she said. “Usually what ends up happening is they’re already creating silos. Now they’ve got three separate areas to manage instead of just one PaaS.” Her bottom line: “A PaaS allows you to align strategy with Dev and Ops teams and unifies your cloud strategy. Otherwise you’re going to exist in a silo’d world.” So think this through ahead of time and you’ll save time.
2. The logic leak: Although it’s tempting to have a whole lot of different but closely related microservices around when developing a product, problems arise when they’re too closely related (sharing a core object library or common domain objects) and suddenly “you’re going to end up with an inconsistent object at the end of the day,” Iyer warned. That results in the charmingly named “code smell” and is an easy trap to fall in to. Instead, remember DRY, for “don’t repeat yourself,” she said. And really, really don’t repeat similar logic.
3. Monolithic microservices: It’s tempting to put different microservices in the same container, right? Why not save money, and they’re all kind of related, and it’s a great idea, right? Wrong, said Iyer, though she acknowledged this practice is way more common than most people are willing to admit and more often than not the driving force is cost. But this strategy will cause your code to “decompose prematurely,” she warned, because microservices sharing the same container develop dependencies and suddenly making code changes – or scaling – becomes very difficult to do. “They grow arms and legs in there, so you just can’t put more than one in the same container,” Iyer said.
4. Ignoring the 3 Musketeers: Iyer referred to APIs/API interfaces, service registries and fault tolerance as the 3 Musketeers. APIs need to talk to each other but are often at cross purposes language-wise. Her advice is to use language independent Swagger to bridge all the gaps. “You need to honor the contract between your microservices,” she said. Service discovery is important because it can be easy to loose track of what is where with all the communication between APIs and the addition of new microservices. Her advice: Use Eureka from Netflix or Spring Cloud services. And finally, that third Musketeer, fault tolerance cannot be ignored because problems at the API layer can spread and potentially cause a disruption of service. Iyer suggested using Netflix’ Hystrix as “an elegant way to solve this problem.”
5. Siloed Search: Search can get tricky – and go stale – when all an application’s microservices are operating multiple sets of data and potentially altering them. The solution, Iyer said, is a cloud native federated search model. An enterprise wide data bus using Rabbit MQ or Kafka is the answer. “Instead of going from a formerly stale data push model now you have more of a proactive real time data model pulling from the message bus and updating, thus giving users the most up to date information,” Iyer said.
Has your organization been guilty of any of these “anti-patterns”?
We’re all so busy reading (you) or writing (me) about developing apps for cloud and mobile platforms, it’s getting pretty tough to find much in the way of Windows coverage. If you’ve forgotten about Windows on the desktop, you may be making a mistake.
Certainly, we all know the PC is dead, right? Well, not so fast. Consider this market research nugget published just six months ago by IDC. According to its own March 2015 Worldwide Quarterly PC Tracker, “total 2015 volume is projected at 293.1 million PCs, slipping a little further to 291.4 million in 2019.” (That includes Macs.)
That’s more than a quarter-billion desktop and laptop PCs (a lot more) globally every year from now through 2019. And the number is not going to suddenly plummet to zero in 2020. There’s no question shipments are in an overall declining trend, but a quarter-billion PCs every year is not to be ignored. In June 2015, the last full month before Win 10 started shipping, the various versions of Windows together accounted for 76.9 percent of all those machines, according to Statista. (Mac OS was 10.03 percent; Linux 1.77 percent.)
Granted, the PC numbers pale in comparison with IDC’s Aug. 2015 Worldwide Quarterly Mobile Phone Tracker that says worldwide smartphone shipments in 2015 will top an astounding 1.43 billion units. In comparison, tablet shipments in 2015 will be a mere 233 million units worldwide, according to a Jan. 2015 report from Gartner. That’s a bit of a recovery after sales plummeted in 2014, a year that Gartner described as “troubling” for tablets. Note that the predicted tablet shipments lag behind PCs.
What spurred me to think about this is the torrent of press releases I see weekly announcing new development tools. To the best of my recollection, only one company, Embarcadero Technologies (which has its roots in the old Borland of Turbo Pascal and Delphi fame) is actively focusing on Windows and bringing out new generations of its tools.
Do you still develop for Windows? Or have you moved to cloud and mobile exclusively? Share your opinions; we’d like to hear from you.
We’re all aware that as cloud applications grow in importance, businesses are clamoring to hire more software engineers. They might work in mobile application development, database design and administration, security, communications, analytics, or somewhere else.
While most businesses acknowledge that simply finding software engineers can be a challenge, IBM, of all companies, admits something much more revealing: IBM doesn’t even know what a software engineer is.
During a presentation on big data analytics at a recent conference in Boston, Mike O’Rourke, vice president of product development for IBM’s cloud data services team, made a statement that I found rather startling:
“There are 400 different ways that people in IBM have described themselves as software engineers.”
That’s just inside one company (admittedly a very large one). Look online and you’ll find wildly varying definitions.
How do you define software engineer? Join the discussion and post your definition. Let’s see how well they line up or vary. Perhaps this is a new area crying out for standards.
And just like that, all the mobile cloud apps you worked so hard to build and deploy for iOS 8 throughout the past year are now woefully, utterly obsolete.
Sure they are. If your mobile apps don’t support iOS 9’s snazzy new 3D Touch technology, you are, well, out of touch. The technology was announced today (Wed., 9/9/2015) along with new iPhones, a new iPad, and a $99 stylus (the Apple Pencil), one thing Steve Jobs vowed never to bring to market.
3D Touch allows the newly announced iPhone 6s and 6s Plus models to sense how much pressure a fingertip applies to the display. That’s the basis for “Peek and Pop,” iOS 9’s marquee new feature that lets a user preview content within an app and act on it without actually opening it. (Not unlike the Preview Pane we’ve been using for years in Microsoft Outlook.)
To cite an Apple example, “With a light press you can Peek at each email in your inbox. Then when you want to open one, press a little deeper to Pop into it.” The feature can also be used on a link to preview a Web page without actually navigating to the site. Or press on a street address to peek at a map. Let go and the map goes away; press harder (“more deeply,” to use Apple’s vocabulary) and the map can be opened and zoomed for greater detail.
Here’s hoping that users don’t overdo the finger pressure gesture, though I’m sure we’ll soon be reading reports of Peek and Pop suddenly being transformed into Snap, Crackle, and Pop. If last year was “Bend-gate,” this year may descend into “Pop-gate.”
With “Quick Actions,” pressing on an app icon brings up a context sensitive menu of actions. (Think right clicking with a mouse.) On the native camera app, these options are Take Selfie, Record Video, Record Slo-Mo, and Take Photo.
For your job as an app developer or architect, here’s why your life is likely to get real busy real fast. Again, to quote Apple, “3D Touch works throughout iOS 9 to make the things you do every day more natural and intuitive. There are so many ways that simply pressing deeper can make whatever you’re doing a better experience.” (Update: Apple announced on Sept. 11 that it is now accepting for review applications developed for iOS 9, OS X El Capitan, and watchOS 2.)
As part of Apple’s launch event, it trotted out several companies that have already incorporated 3D Touch into their apps. If your apps are public facing, they’ll need 3D Touch functionality to stay competitive. After all, your competitors aren’t sitting still. Apps designed for in-house corporate and employee use are not under the same pressure (sorry).
With the public release of iOS 9 just a week away (Sept. 16), what is your organization doing to stay ahead of the feature curve? Maybe simply waiting is the most-prudent strategy. Or perhaps the race is on to broaden app capabilities. Tell us about your plans for iOS 9. There’s a lively discussion just around the corner. We’d like you to peek and then pop into it.
When someone using your mobile cloud app begins a transaction and communications is unexpectedly lost, what happens on both the device and server sides when that break is detected? And what actions follow when communications is restored, likely in a completely new session? These are important questions whether your app is operating in the financial, retail, or services industries.
This boils down to well-crafted specifications from a competent business systems analyst coded by an experienced developer in a clear, understandable way that holds up to extensive QA scenario testing and subsequent audit scrutiny. No one said it would be easy — that’s why up to 80% of the code in a typical application may be solely for exception handling.
It’s akin to a multiple-choice question with no right or wrong answer: cancel, complete, or suspend.
When a cloud session is interrupted, do you cancel an in-progress transaction? If yes, and that’s happening on the server side, you’ve got to do store-and-forward, eventually getting that cancellation to the mobile app to maintain end-to-end synchronization. Maybe your server side also needs to generate an e-mail or text message so the user knows what happened and what action ensued. Of course, no communications means the message might also be subject to delay. And, your app is logging all of this, right?
Perhaps, instead, the transaction gets processed and posted. If that’s the case, it might be happening without immediate confirmation to the user. Maybe that’s ok for a 99-cent music download, but, if the transaction is an application for a mortgage, for scheduling medical tests, purchasing airline tickets, or, to think more industrially, something that impacts a factory-floor production line, there’s much more at stake.
The third alternative is to suspend the transaction and wait for the user to re-appear under a new session ID, whereupon the transaction can presumably resume. This state that lies somewhere between cancel and complete may be the most complicated of all. Was the product deducted from the available inventory database? Was the payment portion transmitted to the third-party credit card processor? Was a pick ticket generated? There’s the issue of databases that may not know the correct record-locking states. And what if the user doesn’t re-appear within a specified time frame? It can get very messy very quickly.
Journaling and logging are essential components of any transaction-based system, but their true value may be more in post-mortem by a team of auditors than in dissecting the complexities and permutations of an interrupted event in real time. That was fine decades ago for nightly batch processing, but in today’s cloud age of expected instant results, users can’t — or won’t — wait.
Finally, there’s perception. Does the user blame the communications carrier or your app for the snafu? It takes only a moment for an angry customer to blast your app and company on social media, even though neither may be at fault.
What’s your philosophy when it comes to transactionus interruptus? What happens on your mobile app and on the server side? And how do you get the two sides back in sync? Tell us, we’d like to hear from you.