How to Go Faster as a Software Development Team

When performance tuning an actual software system, one challenge is that it is possible to measure many different metrics: api response times, startup time, screen load times, etc. It can be hard to know what to measure. As developers, many times we concentrate exclusively on tuning the computational performance of the system, which is important, but fail to address our users’ performance frustrations. The things that our users think are slow will almost invariably be different from the things that our profiling tools think are slow. Focusing on the perceived performance of the system according to our user is critical. If we take steps to reduce the time between the user’s request and the visual feedback to that request, our users will generally be much more satisfied with their experience, even if the api calls have not been sped up.

Here comes the point.

The same can be said about a software development project. Every project, including ours, has sponsors – people who have asked us to do this work. They are “using” our team to accomplish something; the stakeholders are our users. We can take steps to dramatically improve our perceived performance as a software development team, even if we might feel there is not much we can do to improve our computational performance.  In other words, we might not be able to actually go faster, but if we provide our stakeholders and users with visible feedback (software they can use) more frequently, we will have more satisfied stakeholders. They will perceive our performance much differently than if we only communicate updates when they ask us for them, or if we only deliver software at infrequent intervals.

The keys to accomplishing this are 1) open, frequent, transparent communication with our stakeholders and users and 2) continuously delivering a stream of software that is designed to actually meet the needs of well-chosen users.

There many additional benefits to both the team and stakeholders in doing this , but that's a matter for another post (or 20).


@JamieMSmyth

Why (most) tablet magazines are (currently) failures

Jon Lund is wrong.

I read Jon Lund's article on GigaOm entitled Why tablet magazines are a failure with some interest since I work in that space. Jon has concluded that an "app-based tablet approach to magazines leads straight to oblivion, at least for individual magazine titles."

I couldn't disagree more.

I am the CEO of TypeEngine, a Newsstand publishing platform that is designed for large agencies as well as indie publishers. I also run a full service mobile app consulting agency. I obviously have a vested interest in proving that tablet magazine apps are not doomed.

Jon obviously sees the problem but fails to see the solution. He makes four points about why he thinks magazine apps are doomed. He says:

1) “The average smartphone user opens only eight apps a day” and consequently “there’s not much room for magazine apps”.

2) Magazine apps are "invisible in the stream of information" since one must read the articles in that app, as opposed to something like Flipboard or Zite.

3) Magazine apps are "antiquated monoliths" of terrible grossness.

4) Lastly, Jon says that "magazine apps don't sell", citing some statistics from the Alliance for Audited Media.

Let's consider these points one at a time.

1) "Eight Apps a Day"

The argument here is that people only use eight apps a day, so odds are a magazine app won't be one of them. So the app developers of the world should just go home, right? There is no room in the public consciousness for other apps, right? Nonsense.

The same study from Flurry that Jon quotes goes on to show that 63% of the apps people are using are new apps that they weren't using a year ago. It also shows that the number of apps people use each day is growing.

So don't let the defeatist thinking fool you. People are using more native apps more frequently and for longer periods of time than ever before. If it's done right, there's no reason why your magazine app couldn't be one of them.

2) "Invisible in the Stream of Information"

Jon argues that when a magazine is bundled into an app it vanishes. Google can't index it, people can't discover it, and when readers share an article with their friends, the link only takes their friend to the app store.

Not only are parts of that argument completely wrong, it also totally misses of the point of creating high quality unique content.

There is so much to say on this topic. First of all, the essence of this argument admits that reading a Newsstand magazine app is immersive; it's not the same experience as drinking from the firehose information glut of Facebook, Flipboard, and Zite. That's a good thing. This content stands apart. It's considered, it's special.

Second, who's suggesting that magazine publishers should have no web representation of their native magazine content? I didn't suggest that? Did you? That would be a terrible idea. While it is true that many Newsstand magazine apps have little or no web presence, suggesting that the apps themselves are failures because of that is shortsighted. The only way to run a Newsstand magazine is to have web versions of each article precisely for indexing, discoverability, and social landing. That way, when a reader shares an article to Facebook or Twitter or App.net, their friend is taken to the web version of that article when they click the link. Now, what the friend of the reader actually sees when he views that page is a different story. At TypeEngine, when a publisher creates an article for the magazine app, a web version is also created. However the web version is, by default, truncated and has a link to "Go Download The App" to read the rest of the article. This accomplishes several things, and nullifies all of Jon's arguments here: 1) it gives Google something to index for discoverability on the web at large and 2) it gives the friend of a reader something to actually read instead of simply a link to the app store.

As for Flipboard and Zite not being able to look in and "grab" the content of the articles, that's kinda the point. Zite and Flipboard function to enhance their own brand by doing this, and publishers don’t necessarily benefit from that. By publishing bespoke content that is not available elsewhere creates a sense of exclusivity in the reader - that this content is not available elsewhere. All this serves to build the publisher’s brand and reputation.

3) "Antiquated Monoliths"

Bingo, Jon. You got this one right.

Most Newsstand apps are antiquated and most are monolithic. But just because many Newsstand apps are terrible doesn't mean that making Newsstand apps is a terrible idea. It just means they should stop sucking. How can we stop the suck?

Let's look into the comments of the GigaOm article for some suggestions, shall we?

"The content has to adapt to the platform and user rather than pushing a one size fits all experience on the consumer. I love print magazines that are well-done, but it is rare I find the same experience in digital form." -Madlyb

So right. PDFs, InDesign folios, Photoshop files and the like all suffer from the same problems when publishers try to use them for Newsstand apps: extreme bloat, non-adaptive content and content that is tightly lashed to the layout and design. It's now common knowledge that these are poor choices for the architectural foundations of a Newsstand magazine app. So why do so many publishers start there? Three reasons: time, money and familiarity. I'll treat the first two here and the third in a later post.

Time

Because of time and personnel constraints, publishers are under enormous pressure to recycle the production artifacts used to create print publications, so it's natural that these have been the foundation of so many Newsstand magazines. But just because something is easier doesn't mean you should do it. Publishers should take the time to dignify their content by preparing it properly for digital distribution.

Karen McGrane's wonderful book "Content Strategy for Mobile" should be mentioned here.

Money

In addition to subscriptions, magazines make money by charging for advertising. The amount of money that a magazine can charge advertisers depends in large part on their circulation —the more people that see an ad, the more they can charge an advertiser for it. That's called the "rate base." Therefore, it is enormously important for magazines to show (and prove) high circulation numbers. There are 3rd party audit bureaus like the Alliance for Audited Media that charge publishers through the nose for doing circulation audits, and advertisers want to see these audits. Think of it as Carfax for magazine circulation. Doing circulation auditing for print is a long-solved problem, but as you can imagine, they have scrambled in recent years to bolt on circulation auditing for mobile.

Large magazine publishers live and die by this circulation report. But the auditing bureaus have a choke hold on the industry with their standards for what is required to report circulation of digital editions. These circulation figures, such as the one Jon references in his article, generally only include digital replica versions in the main circulation figures and rate base comparisons. I'm going to restate that: The core circulation figures and rate base comparison reports by the audit bureaus only include the circulation of Newsstand magazine apps so long as the Newsstand app is a REPLICA of the print version. They will acknowledge "Non-Replica" app circulation, but those are consistently relegated to second class citizens in the report. The audit bureaus have incentivized the publishers to produce apps that look the same as print versions.

The audit bureaus have incentivized producing apps that suck.

This drive to create print replica digital editions naturally causes many magazine publishers to start with print-first assets like PDFs, InDesign folios and Photoshop files to create their digital publication. This results in rather-be-stabbed-in-the-face download times and digital magazines that ignore phone-sized form factors and landscape device orientation.

Tim Shea hits the nail on the head regarding the net effect of this suck fest in the comments section of Jon's article:

"They offer a horrible user experience. Just downloading GQ takes an hour off the very worst airport wifi connection. And takes no advantage of the platform or real-estate. You can almost smell the cologne advertisements by how obvious they are trying to keep aligned to the print edition."

4) "Magazine Apps Don't Sell"

As Tim Shea states above, many magazine apps offer a horrible experience for the user. And people don't normally buy products that offer horrible experiences.

However, not all magazine apps suck, and not all of them are suffering from a lack of sales. Just ask Glenn Fleishman of The Magazine, Jim Dalrymple of The Loop Magazine, or Thomas Deneuville of I CARE IF YOU LISTEN Magazine (who just won the ASCAP Foundation Deems Taylor Award for Media). All have created user-friendly, content-centric apps that have healthy subscription bases, relative to production costs.

Most magazine apps are stinking up Newsstand in a huge way right now, that’s for sure. So I offer this advice to publishers:

• Get with the times. Stop using monolithic, non-adaptive, outdated artifacts as starting points for your digital magazines.
• Stop thinking that folios with animated monkeys (or watches or clouds or cars) are the basis for a good digital magazine; those are video games at best.
• Stop kowtowing to the audit bureaus' definitions of what constitutes circulation. Be willing to stand up and do something new and fresh.
• Consider your users and give them a nice experience. Remember that digital is not paper, so stop treating it like paper.
• And lastly, keep your chin up—mobile devices are not going anywhere. They are the future of your magazines and your wonderful content. Just please, for the love of God, stop making Newsstand apps that suck. Your content is worth so much better.

I'd also like to address the fact that Jon's article is entitled "Why TABLET magazines are failures" (caps mine). I always cringe when I hear Newsstand magazine apps referred to as "tablet" magazines since that obviously ignores phones. Producing a tablet-only Newsstand magazine app is a huge mistake. Since we launched TypeEngine in July, we've shipped almost 30 Newsstand magazine apps and over 53% of the readers are using an iPhone or iPod touch.

So perhaps if people didn't think of Newsstand magazine apps as "tablet apps" they'd have 53% more subscribers.

I'm on Twitter as @JamieMSmyth if you want to flame me.

Here's to my ex-boss Sam

I went on a job interview for doing SQL Server database development years ago and project management. The guy asks me one or two quick questions about SQL Server and then says "okay I have a test for you." 

I'm like, "great."

The test was 300 questions of nothing but shapes and patterns.  It was incredibly difficult toward the end. I finished it and he said "I was timing you."

I got the job and he turned out to be the best boss I have ever had. He was incredibly intelligent. When I asked him about the test he said "I wasn't as interested in learning what you know as I was in learning how quickly you learn."

I worked there for a couple of years and the president fired him because the president was/is a racist. (My boss was from Jordan)

At the time I was in charge of the largest contract the company had. The president wanted me to lie to the client and tell them that my boss was still there to cover his racist butt. I quit the same day and went to work with my previous boss. 

Years later, we still keep in touch. #BestBossEver

Corporate Hackathons: The Fine Line Between Engaging and Exploiting

Last week I saw that Campbell soup was “inviting developers to hack the kitchen” by hosting a coding competition around their recipe API. I posted on Twitter and App.net that “I’m tired of corporations ‘inviting’ us to do their work for them.”

That hit a nerve, both with Campbell soup’s marketing people and with developers. The Campbell’s folks took exception to my comment but the developers hanging out in ADN asked me to write about it. I decided to listen to the ADN gang.

Campbell soup Global Head of Digital and Social Adam Kmiec fired off a tweet snarking that “I’ll assume we shouldn’t send you or your organization any RFPs in the future.” Fair enough, since my tweet was pretty snarky. I never thought I’d get into it with a soup company on Twitter (strange times), but I’d like to address the larger topic here: Is it really worth it for developers to participate in corporate hackathons? I’ll just use Campbell’s “Hack The Kitchen” shindig as an example of corporate hackathons at large.

Update (1/20/2012): Adam appears to have deleted his tweets stating that he 'shared his opinion about me & my company to every colleague he has client-side and agency-side'.  
Thanks saurik.

What’s the Use?
Corporations are obviously under enormous pressure to get with the 21st century and appear relavent in the digital age. Their brand marketers are tasked with coming up with new and novel ways of making sure people are thinking and talking about their brands. Obviously in this age of mobile, that includes making the brand available on as many platforms and screens as possible.

It makes perfect sense for Campbell’s to make an API of recipes for dishes made from Campbell’s family of products. If they get enough people to use the data in the API, it obviously builds brand caché and could drive sales (Ranchero Enchilada Casserole, anyone?)

But what’s in it for the developers?

$25,000 - $50,000, that’s what. “Woot! Sign me up!” right?

Slow down Speedy, let’s look at what you need to do before you can collect.

1. You need to think of an imaginative way to use their recipe data and send them your idea before Feb 1. This is open to everyone in the US. You need to describe what makes it great and what you’ll need to actually deliver. Easy.
2. Campbell’s will choose up to 30 ideas and then (and only then) give you access to the API. That happens on Feb 11. You will then have three weeks to code on your idea.
3. After the three weeks, they will select up to 10 finalists to come to New York (at your own expense) and pitch your app to the judges. If you don’t want to pay to travel to NYC, you can do it via videoconference. Presentation day is March 22.
4. At some undisclosed point in time, they will pick one winner and one or more runners-up. The winner will get a $25,000 prize plus a $25,000 contract to actually make the market-ready app. It’s not clear whether they will even pick runners-up, but if they do, they will get 10 grand for their work. No contract for you.

It’s a contest. There are prizes. Got it.

Calling All Developers
We already know what Campbell’s gets out of this whole deal: The buzz associated with “engaging the developer community” and a nice launch of some product that lets people look up new ways to use V8 carrot juice. They also get to have a look at some pretty good developers.

But for  approximately 93% of the fortunate developers that “won” the chance to write code against the Campbell’s soup API (!), they get… nothing.

Now you might be wondering, “Forbes says that software developers continue to have the most sought-after skills in America. So why would I go and do a bunch of free work for the soup guys?” Good question.

Perhaps you’ll make 50 grand. You’ll no doubt get to meet some smart people. You never know, Campbell’s might offer you a job. You get to travel to New York and talk to some bigwigs. And you might change the way people decide what to make for dinner. Who knows?

The majority of participating developers, however, will get nothing. So if you actually are a software developer, and if you really want to make some guaranteed money and meet some smart people, just get a job doing software development. EVERYONE is hiring. If you want to go it alone, just pay $25 to Google (or $99 to Apple) and start writing and selling apps.

Not All Hackathons Are Created Equal
I’m not “against” the hackathon model.  For instance, Google just announced their hackathon for Google Glass. Do I think it's a waste of time for developers to enter this hackathon too?  No.

The point I'm making is that developers who are thinking of entering this type of contest should consider what they'll be left with if they are not the winner.  In the case of the Campbell soup Hacroutonathon (thank you +Kosso K), you'll be left with no money and an app that you spent a ton of time writing that's somewhat dependent on the Campbell soup API.  Did you gain experience with a technology that's likely to be marketable? No.  You learned the ins and out of the Campbell's recipe API.  

How does that measure up to something like the Google Glass hackathon?  For starters, you had to have paid $1500 months ago to join the early Google Glass developer's program.  That sort of separates the men from the boys when it comes to developer intent.  Those who paid will get an actual Google Glass device at the event.

In addition, Google has not mentioned what type of award, if any, will be given to the winners of the hackathon.  But award or not, ALL of the participants in Google Glass Found hackathon walk away with highly marketable experience and knowledge.  Google is not dangling a carrot in order to get some apps written on the cheap.  The same cannot be said for Campbell's.


Unethical?
Don’t get me wrong, I’m not writing a manifesto here. I’m not making a stand against coding competitions, hackathons, or code fests. I think they’re great when they’re held for the greater good or for the benefit of the participants themselves. (Here’s a nice list of hackathons sponsored by open government data.) But I think it’s a little lame when a big corporation tries to leverage this model in order to advance their own brand without giving all the participants something worthwhile. I don’t think they’re being evil or unethical. Just lame.

Let’s look at what is really going on. The corporation wants something. And to get it, they are going to have 30 people build 30 apps. They are only going to pay for one or two of them. I mentioned this to Campbell’s guys during an email exchange and they told me that the losers are “welcome to take that ‘rejected’ idea and pitch it to a VC or launch it as your own app if you please.”

I know what you’re thinking, “What am I supposed to do with an app that uses the Campbell’s soup recipe API now that I no longer have API access?” Another good question. The answer from the Cambell’s guys: “I don’t think the idea is necessarily reliant on our specific API, if it has legs it can work elsewhere as well.”

To me, it’s similar to someone who says, “I made some homemade bread and want a sandwich made from it. Have 30 people come to my house and make different kinds of sandwiches. Tell them to bring their own sandwich fixings. I’ll buy the one sandwich I like best. Tell the other 29 people that I’ll want my bread back, they can take their sandwich contents and try to sell them to someone else.”

So is Campbell’s doing anything predatory, evil, or unethical?  No. They are being totally open about how this whole thing will go down. But my question to software developers out there who are thinking of devoting any real effort to a corporate hackathon like this is, “Why?”


twitter: @jamiemsmyth
app.net: @jamiesmyth
email: jsmyth@thesmythgroup.com