Platforms need developers to succeed, so you need stories that resonate with developer’s worldview. Stories that you live to make true.
Your stories must be true. Developers can spot lies and it’s easier than ever to spread bad news, such as on Facebook. Not to pick on Facebook, but they serve as an example of conflict between a platform vendor and developers.
Facebook is a platform for third-party applications. And not just for games; you’ll find a range of business and marketing applications as well. After all, with Facebook’s massive user base there’s money to be made.
Watch out if a prospect asks you to prove your story’s true. Instead, seek out an audience inclined to believe your story.
I developed applications for CICS on IBM mainframes in the 1980s. At that time IBM had a project to reimplement CICS using formal methods. Reading about the Verification Grand Challenge reminded me of that project.
An ambitious 15-year international research project, its goal is to create a large repository of useful code, verified to the highest standards of rigour and accuracy. An early case study applied automated verification tools to prove CICS is formally correct. For this they used the CICS Z notation specifications from the 1980s.
Apple’s walled garden is becoming a hermetically sealed world with a (secret) licence agreement to sterilise every input.
The clash of worldviews between Apple and developers took a turn for the worse this week. For the first time, Apple will be banning meta programming tools for the iPhone and iPad. Section 3.3.1 of the latest iPhone Developer Program License Agreement states:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
The Clang compiler recovers from unknown tokens using a spell-checker. Something small can be remarkable and worth spreading.
Being remarkable doesn’t always mean you have to develop something large. Sometimes remarkable is small, as this Clang example seen today on Hacker News demonstrates very nicely.
Clang is an open-source compiler front-end for C, C++ and Objective C. The project builds on the LLVM compiler back-end with the goal of replacing the GCC tool chain. Their worldview accepts that programmers can and do make mistakes. Amazing feats of Clang Error Recovery shows how they’ve woven this worldview into the compiler.
What caught my eye was how Clang recovers from unknown tokens. Instead of unhelpful error messages (like GCC), the Clang team chose to do something remarkable: they added a spell-checker to guess what you mean:
Because millions of users associate WordPress with free, the VaultPress team wove their paid-only story into their beta sign-up form.
A post about VaultPress on Mike Davidson’s blog reminds us that weaving a story into software can be easy. VaultPress is from the great team behind WordPress and is a real-time backup service for self-hosted WordPress blogs.
Most WordPress products are freemium. VaultPress is paid-only: a high-end product for high-end users. Or: VaultPress is for people whose worldview leads them to expect to pay for backups. That covers me, and I don’t consider myself a high-end user!
WordPress is very visible company with millions of users. Many of these will notice VaultPress and take a look. Because most users associate WordPress with free, the VaultPress team wove their story into their beta sign-up:
As Blaise Pascal (sort of) said: it takes longer to write a long post than a short one; ‘Writing is rewriting’ is so true.
Today I’m looking back on Story Complete’s first month. This is the 17th consecutive day I’ve posted. While at first I found the daily schedule difficult, I’m hoping practice makes perfect.
Written preparation is often the path to success, whereby the writing part is essential. My daily schedule forces me to click that scary WordPress publish button. On the other hand, sharing my thoughts in writing helps me clarify what I’m trying to say.
Identify returning users as VIPs: those most likely to spread your story. Treating everyone the same is easy, but they deserve better.
Existing users are more likely to recommend you than new one, so don’t treat everyone the same. Existing and new users have different expectations, even though they share a common worldview.
A chainsaw cannot change itself depending on whether a newbie or an experienced lumberjack picks it up. Your software is not a physical product. It’s easy to support multiple expectations from a single code base, just as you do with i18n and L10n.
The German tax system is complex (it’s said 80% of the world’s tax laws are in German). As a result, a large vertical niche of tax return software exists.
Forcing our code generation worldview on prospects just lead to heated arguments and late nights cranking out emergency fixes.
For many years I built, sold and supported application generators that generated platform-specific code from abstract problem statements. We generated Java, C++, C, SQL, HTML, COBOL, PL/I and many other languages.
Our worldview: generated code is efficient and works. Our ideal prospects shared our worldview. While they were often experts, they had no expectations about how the generated code should look. Just that it worked and that they were more productive.
Not all prospects shared this worldview. If someone said “I would not have written the (generated) code like that” we knew there would be trouble.
You can’t spread your own story, just create a fertile environment, weave your story, give it its freedom and wish it a world of luck.
Stories are your best chance of getting your message to the people you need to hear it. Even so, the right story told to the right people is no guarantee your story will spread. You need 5 ducks in a row to have a chance of spreading:
Physical products are tactile, but software is intangible, so how do you think your audience expects it should look, feel or even smell?
Your target audience has a story about how they expect your product will make them feel. Marketers and developers must work together and meet this expectation with consistent and genuine stories woven into your software.
Physical products are tactile; you can feel them in your hands, how they move, smell and taste. Software is intangible. Even so, how do you think your audience expects your software to feel? To look? To smell? How should it look on opening the box (installing)?
Software is easier to change than physical products. Good design splits function and presentation; weaving your story into your software will be easy. Or not.
Target people sharing a worldview, already paying attention to your domain. They notice newcomers; are you sure they’ll notice you?
We view the world differently based on our biases, assumptions, values and experience. Our worldview filters what we pay attention to; what we believe.
Our worldview underlies the story we tell ourselves about what’s happening. It drives the guessing machine we use to predict future events.
Your target audience is a cluster of people who share a worldview and who are paying attention to your domain. But, while they notice newcomers, will they notice you?
