25 August 2013
Modern version control systems automatically record useful information every time we make a commit:
The difference (diff) of every file is automatically recorded, so we can see the additions and deletions in each commit.
Every commit tracks the location (files) of each change, so we know where the bodies are buried.
Every commit is timestamped, so it’s easy to find things that were changed yesterday, last week or ten years ago.
Every commit is associated with a person, so we know who to ask about that confusing conditional.
The reason for making this change is the only thing a version control system can’t infer, so it’s the only piece of information that should ever go into a commit message.
Version control systems automatically record the ‘who’, ‘when’, ‘where’ and ‘what’ of every commit. Please, use the commit message to tell us why this change was made.
(Thanks to Antony and Andy for helping me understand these ideas and write useful commit messages.)
07 June 2013
This discussion of empiricism, complexity and being gentle with enthusiasm, by yours truly, is clearly in gross violation of the spirit of a ‘pro tip’ but may be of interest to programmers or those working on Ruby on Rails projects.
Warning: contains code and high-horsedness.
16 May 2013
Are native apps faster than web applications? Do they feel better than web applications? Maybe.
As a user, there’s a bigger problem with web applications. They can be changed at any time, without notice.
The ability to change your product quickly and often is also a huge boon to creators of web applications. The godfather of startups, Paul Graham, in his seminal startup bible ‘Hackers and Painters’, calls this out as a huge advantage to startups: Release early, release often. Iterate!
The new ‘Lean’ literature is also full of this kind of thinking: Make a hypothesis about a change to your system, quickly build a barely-sufficient (sorry, ‘minimum viable’) version of a feature, deploy it to your users, then measure their response to test your hypothesis had the desired effect.
Now, rinse and repeat until you’ve attracted enough users to be aquihired by Google. Now you can become a V.C.
Circle of life.
Once in a while, this process of rabidly churning out changes to a product results in a beneficial long-term invention for users. It’s a hap-hazard approach akin to throwing shit against a wall and hoping that a masterpiece eventually reveals itself: If it eventually happens you look like a genius, but in the mean-time we’re all covered in shit.
I’m sick of having to re-learn the interface for your half-assed web app. I’m sick of your tweaking and polishing and rearranging and pivoting. It may be the most cost effective way for you to “innovate”, but you pass some of that cost to me, your theoretical, quote-unquote non-customer. Now I have to spend my time and and attention learning how to attach an email again, or figuring out why the workflow that I depend on is suddenly, maddeningly ever-so slightly different than it was five minutes ago.
There’s a reasonable argument that web apps feel less snappy than native apps, and sure that’s important to me. But it’s far less important than the feeling of relying on your web app for something and, in exchange, exposing myself to your shit-slinging innovation process.
I’m sick of being your lab rat, running desperately through the new maze you’ve dreamed up, frantically searching for that piece of cheese that I know you’ve hidden around here somewhere.
Why are web apps worse than native apps? Because they encourage you, big-shot startup entrepreneur, to experiment on me instead of thinking through the job that I’ve hired your software to do. And you’re not entirely to blame. I should be more discerning with my time and attention. I should be paying for a well considered, thoughtfully designed service that solves a genuine problem. I should be more circumspect about the use of my time and attention.
And so, it is with regret, that I must decline to sign-up for your shiny new web app. I will pass on your revolutionary new gadget. I really don’t need another way to watch my extremely limited time on this earth slip through your sweaty fingers in the name of “innovation”.
Good luck with your acquisition.
01 February 2013
MG Siegler gets excited about the prospect of digital, Internet-connected smart wristwatch personal assistants: > I want a Dick Tracy watch that can do all kinds of things beyond just making calls. Call/SMS notifications are a great first step.
Lining up watches as the next disruptive technology—much like the iPhone spawning the smartphone revolution—is tempting, but there are a few notable differences.
The big difference between pre-2007 cell phones and today’s wrist watches is that there are already wristwatches I want to use today.
My wristwatch is a result of the cumulative experience of an industry with hundreds of years of technology-advancement and craftsmanship under its belt, culminating in a seemingly living, breathing mechanical work of art that I get to wear on my wrist everyday.
My watch has precisely three functions: it shows the current time, the current day of the month and it has a mechanical alarm (seriously, mechanical). Its user-facing functionally is incredibly simple.
I love this watch.
In 2007, before the iPhone was announced, I owned a little Samsung slide phone. I don’t recall the model number. It was ugly, awkward to use and I hated almost every interaction with it. Before the Samsung I had owned some iconic Nokia phones, including the 5110, 7110 and 6110. All the Nokia phones I owned were good at their job: Functional cell phones. I loved none of them, but they were adequate. The iPhone changed that. It was the first cellular device that I felt genuine affection for. It was a beautiful, tactile little Internet-connected computer.
I loved that phone.
The iPhone was, at least, 100 times better than any other personal communication device I had ever owned. Moreover the iPhone was beautifully designed. It was an object of art. I felt the same kind of affection for the iPhone as I do for my watch.
Before the iPhone, cell phones were either terrible or adequate. Wristwatches don’t have that problem.
The wristwatch as a category for disruption seems like a much tougher proposition than cell phones. The watchmaking industry has a long, distinguished history of creating beautiful, functional items. Making a watch that’s 100 times better than the best in the market today will be an incredibly tough challenge.
But maybe I’m looking at this from the wrong angle. Am I acting like the people who continue to buy Blackberry phones because they absolutely must have a physical keyboard? Will the benefits of a tiny, wearable always-connected computer assistant trump the nostalgic beauty of a mechanical Swiss watch? For most people, I bet they will.
The market for watches with complicated, automatic movements will become even smaller and more niche, like vinyl record players, relegated to the realms of the enthusiast. In some ways I suppose this has been happening to high-quality watches since the advent of Quartz movements. Technology moves the purists along, if grudgingly.
I think I see where MG is coming from. He’s thinking about the customer experience first and working backwards to the technology. I do see the benefit of more portable, powerful, wearable, connected computing power. But not on my wrist.
16 December 2012
From time to time somebody will convince you to produce a résumé. This is a problem because résumés are awful.
Your résumé is too long, and too generalised. Make it shorter and more specific: A maximum of one single-sided printed page (A4 or U.S. Letter size), tailored to the hiring company.
A résumé should be designed to sell the concept of you working with the hiring company. Design is about compromise: Include only what’s essential.
To compromise you need a constraint. The one page résumé is your constraint.
When you have only one page you must think about more than just words. Think about the font faces, size and colour of those words. Think about the layout of those words on the page. Think about the negative space around those words. Think about design.
One page of words shows respect for the reader’s time and attention. They’re busy. They need help with something. Tell them how you can help each other. And nothing else.
Hiring is a lot of work. Tailoring your résumé is more effort for you but it makes the hiring process feel more balanced.
Tell them why you should work together: How will you help improve their business? How will they help you improve yourself?
To answer these questions honestly you have to research the hiring company. How do they work? Who do they do business with? How do they make money? What do they value?
Answer these questions, then explain why you’re a good fit. Your honesty, insight and interest will be noticed and appreciated.
Be bold and honest.
If, as you design your one page résumé, you don’t feel good about working with the hiring company then don’t apply. You will have learnt something about yourself and saved everybody some time and anxiety.
Try it: Think of your dream job. Now create a one page résumé that gets your foot in the door.
18 October 2012
Tweetbot for Mac was released in the Mac App Store today. It’s priced at $19.99.
From the announcement on the Tapbots blog: > If you think about it, it’s not that expensive. Twenty dollars for a quality piece of software that you use every day? That has been the price point for quality utility apps on the Mac for years.
No arguments there. Tweetbot for Mac is a solid app that compliments my use of Tweetbot on iOS. I bought it because having a unified Twitter experience across my devices is worth the price.
But, honestly, the explanation of the pricing makes me nervous about the longevity of the app:
Once we use up the tokens granted to us by Twitter, we will no longer be able to sell the app to new users. […] We spent a year developing this app and it’s the only way for us to be able to make our money back and continue supporting it with updates in the future.
After the success of Tweetbot for iOS, building a Mac version must have been a no-brainer for Tapbots. But Twitter changed the rules half-way through development, putting a ceiling on the potential growth of Tweetbot for Mac. Now Tapbots need to recoup their development costs and find a way to support the app for the foreseeable future.
I don’t see how it necessarily follows that charging a higher one-off price gives Tapbots the ability to support Tweetbot for Mac long-term. Making a living selling apps on the Mac App Store is already difficult enough. As a customer, I’m nervous that Tapbots will lose interest once the Twitter tokens run out and the money dries up.
Tapbots have sunk a year of their time into building a product that depends on Twitter. Whether they manage to recoup that cost is one thing. The more interesting question is whether we, as Twitter users and Tapbots customers, should continue to sink more of our money and time into such a volatile platform.
17 October 2012
Photoset is an iOS app from the makers of Tumblr that lets you combine a number of photographs into a grid-based layout and share them on the web via a secret URL.
As an app, Photoset is reasonably well designed without being breathtakingly beautiful. The UI is simple and understated.
Photos can either be selected from the Camera Roll or taken from within the app. As photos are selected, Photoset arranges them on a grid. Tapping and holding a photo allows it to be dragged and repositioned elsewhere on the canvas. Photoset does a reasonably good job of shuffling the other photos around on the canvas as you move a photo, to allow for different layouts. The effect is similar to the way iPhoto for iOS allows dragging photos to create album layouts.
Caption, location and date meta-data can be added to a Photoset, which appears on the web-based version.
When you’re happy with the look of your Photoset, it can be uploaded to photoset.com. Optionally the Photoset can be uploaded to a Tumblr site.
Once uploaded to photoset.com a custom, random looking photoset.com URL allows your photoset to be viewed in a web page designed and laid out to resemble the app. Clicking on a photo in a browser shows a larger version of the image in a carousel-like layout.
Photoset URLs can also be shared via Twitter and email, from within the app.
A history of all your previous Photosets can be viewed in the app. From here, Photosets can be shared and their URLs retrieved. Photosets can also be deleted from this screen, and new Photosets created.
Over the past week I created a number of Photosets to test out the app. I found it particularly useful to post a collection of images that I had taken on my phone but not shared anywhere else. For example, when my Elevation Docks finally arrived last week, I added photos of them to a Photoset and shared them all at once, rather than jamming up my Twitter timeline with a dozen individual photos of very similar things.
My concern for Photoset is that it does not have the stickiness of Instagram. I don’t feel compelled to share often because I need to have taken at least three photos—although Photoset does not impose this restriction—to make it feel worthwhile.
Because there’s no following/follower social network built into the service and no image filters to add mood and personality, there just aren’t enough reasons to launch the app frequently.
Instagram is addictive because it encourages you to create or consume depending on your mood and available free time. Photoset, in contrast, feels less about creating something artful, and more about simply sharing a batch of photos: Occasionally useful, but not much fun.
11 October 2012
The App Store received a significant user interface redesign in iOS 6. The Lightwood Games blog shares “everything that’s wrong” with the update, including the new search result listings: > Now, instead of the native app table view, we’re presented with just one app per screen. A full thumb swipe from right to left is required to move to the next item. You can’t just zing your finger to the left and cause a bunch of apps to whizz past either. There’s no physics here. One gesture moves precisely one page.
While I don’t agree with everything in the Lightwood piece, the change to search results from a vertical tabular list, to a horizontal carousel-list is worth comment, as I believe it is a trade-off between “browsing without really knowing what I’m looking for”, and “searching for something specific”. Apple appears to have shifted the emphasis to the former, at the expense of the latter.
The goal of a list in most interfaces is to present a number of options from which the user has to pick a single item (multi-select list boxes excepted).
There are two interesting properties of list interfaces that effect their utility, depending on the goal the user is trying to achieve:
Horizontal or vertical? When it comes to selecting a single thing, usability testing shows that vertical scrolling is preferable. Jakob Nielsen: > We know from user testing that users hate horizontal scrolling and always comment negatively when they encounter it. Customer satisfaction is surely reason enough to avoid horizontal scrolling.
Whatever the reason, vertical scrolling was the more familiar and intuitive paradigm among users of the web, circa 2005. However, since this piece of web-usability research was done, Apple have used horizontal scrolling with some success in native interfaces. Remember Cover Flow?
First popularised by iTunes in 2006, Cover Flow demonstrated that a carousel-like horizontal list was a desirable method for browsing graphical representations of items. Cover Flow does a great job of showing off one item in a list, one at a time: Album covers look beautiful in iTunes.
In 2007 Cover Flow made its way into the OS X Finder for browsing documents and photos inside a folder. The iPhone and iPod Touch have since adopted the Cover Flow interface for browsing music.
The horizontally scrolling carousel-list interface, is really good for idly browsing through a list when you’re not sure exactly what you’re looking for. But when the goal is to choose one specific thing, flipping through a collection that is not sorted for relevance, one item at a time, feels ineffective and wasteful.
And that’s the problem with the new search results on the App Store: If I’m trying to select just one app from a list, and that app isn’t the first one, then I have to go through an inefficient horizontal swipe until the one I want is selected.
Worse, because the horizontal list doesn’t feature the helpful Cover Flow physics to help scroll quickly, after a few swipes I’m ready to give up.
Sorting a list helps us locate items relative to each other. We understand that the entries in our Contacts app are sorted alphabetically, so we know that ‘Jane Smith’ will be further down the list than ‘Johnny Appleseed’.
Sorting search results is a radically different challenge to sorting contacts because now we’re talking about sorting by relevance. Just look at how much engineering effort Google spends making the first result in their web search the most relevant to your query.
When you get really good at sorting by relevance, subsequent items in your list of results become irrelevant. When was the last time you clicked onto the second page of a list of search results? This is the reason Google’s “I’m feeling lucky” button exists: Google got so good at sorting their search results by relevance that they can send you directly to the most relevant result for your search terms.
If the App Store’s search results were sorted by relevance such that the first or second items in the list were always the thing we wanted then the new interface makes perfect sense. If I always found the app I searched for in the top five search results, I could probably forgive the sluggish scrolling.
But in reality the App Store search results generally leave a lot to be desired.
Here’s an example: Last night I wanted to install the ‘Oxford Dictionary and Thesaurus’ app, so I entered the search term ‘Oxford Dictionary’. There are a number of Oxford branded reference apps for sale in the App Store, but the first one—which happened to be the official ‘Oxford Dictionary & Thesaurus’ app that I was looking for—appeared at number 88 of 7,622 apps.
To reach the 88th app in the new App Store took minutes of scrolling, because I had to look at each app to see if it was the one I wanted.
Apple is not a search company. I’m sure they will continue to improve the quality of their search results, but having super-accurate app search results has not prevented people from purchasing billions of apps. In order to sell a lot of apps, the App Store needs to be optimised for browsing, which makes the horizontal list interface a much better choice.
There’s also now a uniformity to the App Store tabs. Along with search results, the ‘Featured’, ‘Charts’ and ‘Genius’ tabs use horizontally scrolling lists to promote more browsing.
It’s easy for the average person to open the App Store, enter a vague search term and then browse through the horizontal list. And if you find more than one app that takes your fancy, that’s great because the iOS 6 App Store allows you to buy and install multiple apps from any list without leaving the store.
While search may be a little frustrating if you know exactly what you’re looking for, Apple is now training you to buy a few things you didn’t know you needed, on your way to finding the thing you actually wanted.
Mark Zuckerberg talks to Bloomberg Businessweek about Facebook breaking one billion active users: > […] I was talking to [Facebook board member] Marc Andreessen about this and he said the only two companies that he thought of that had a billion customers are Coca-Cola and McDonald’s.
Brilliant trolling? Blissful ignorance? Honest opinion?
Given the direction of the share price, I’d say Facebook is a long way from one billion customers.
24 September 2012
It always bugged me that it was impossible to see the time during a FaceTime call.
In iOS 6, a single tap anywhere on screen during a FaceTime call brings up the status bar, complete with the clock and battery status.
This is exactly the behaviour I always expected during a FaceTime call, so I was delighted when it actually happened today.
Update: I was asked to provide a screenshot of this feature in action.
21 September 2012
Yesterday I wrote that O2 were the only UK carrier offering pre-paid nano SIM cards and specific plans for the iPhone 5 launch, however, Three is offering all their pay as you go plans, on nano SIMs, in stores today.
The Three website doesn’t mention the availability of the nano SIMs. I spoke to a Three online chat operator on Thursday, who told me there were no plans to offer pre-paid nano SIMs and that I should “keep an eye on the website”. But I can confirm that nano SIMs are available, having been to the Basingstoke Three store this morning.
The benefit of choosing Three over O2 is the data: Three’s best plan is the “All-in-One 15 Add-on”, which has unlimited data, 300 minutes and 3,000 texts, for £15. Compare that to O2’s best data offering of 250MB, 250 minutes and 2,500 texts for £20, and it seems like a no-brainer.
20 September 2012
UK virtual mobile network operator GiffGaff announced its plan to support the iPhone 5 on its contract-free SIM only plans: > If all goes well, we hope to have the SIM cards ready for distribution in the coming months.
The vocal GiffGaff community expressed their dissatisfaction, resulting in an several vague, apologetic updates, culminating in this: > The process for delivering the nano SIM on giffgaff was kicked off several weeks ago and is being treated as a high priority, but there are some steps which simply cannot be made faster. For these reasons, at this stage, the company cannot commit to detailed delivery timescales, but we are expecting to launch nano SIMs before the end of this year.
GiffGaff are a wholly owned subsidiary of Telefonica/O2 and rely on the telecommunications giant to provide all of its infrastructure.
GiffGaff behaves in some ways like a “small, lean company”, but they are firmly tethered to the mothership. While it looks like a disruptive upstart in a staid industry, GiffGaff is actually a mechanism for Telefonica/O2 to test out risky ideas on a flexible, responsive segment of the market.
The only reason for GiffGaff not to offer nano SIMs on iPhone 5 launch day is because they have not had the nod from their corporate overlords.
Why would Telefonica/O2 delay offering contract free iPhone 5 plans on GiffGaff? It may be because O2 are the only UK carrier offering prepaid (contract free) nano SIMs on launch day.
That’s a huge differentiator for O2. Given that they don’t have an LTE offering, and won’t have one for the foreseeable future, I suspect they want to hold onto as much of the iPhone 5 market as possible. If that slice of the market has to come from prepaid customers, then O2 will take it.
GiffGaff will get nano SIMs eventually, but only after O2 grab the early prepaid adopters.
14 September 2012
When a product you use every day suddenly changes radically the effect can be jarring.
When Apple changed the look of the iPhone 3G, it was jarring. So too, was was the redesign of iPhone 4. Those generational redesigns were significant aesthetic changes, that made people stop and take notice.
But the aesthetic of the iPhone 5 is very similar to the iPhone 4. So similar, that some may feel underwhelmed by the update. And that’s before you even consider the glaring omission of NFC, that useful, ubiquitous, life changing technology (I jest, others don’t).
When Apple announced the iPhone 4, I only bought one after seeing it for myself. The design looked very different, and it was the Retina screen that convinced me to part with my 3G.
This time it’s different. I don’t need to wait for the reviews because it looks beautiful. I’m not jarred by the new aesthetic. It’s not a shock to the system. The differences look subtle and natural. A much loved, well used device, better in almost every way.
The biggest change this time around is a slightly taller screen. But why, after five years, have Apple changed such a successful formula? Phil Schiller explained during the keynote: > Same width, but taller. > > But why? What is the design centre for a phone? It’s this: Your hand. > > When you carry your phone it should fit easily in your hand. It should be easy to send messages, type email and surf the web. And that’s just how we designed iPhone 5.
As iSpin explained earlier this week, iPhone’s width is perfectly suited to the average width of the human hand. The screen height was the only variable that Apple had leeway to change. Apple’s premise is that a taller - but not too much taller - screen gives a much better experience.
But if you want to understand why the iPhone 5 looks so similar to the iPhone 4, look no further than the screen: It is the device. It’s so important that Apple - one of the most calculating, meticulous, design-focused companies in the world - hasn’t changed its size for five years.
This screen resize represents the single, most dramatic aesthetic alteration to the iPhone since the original shipped in 2007. Apple’s designers don’t do things by accident. This is a huge deal.
It’s such a big deal that Apple had Jony Ive discuss the reason for the muted aesthetic changes: > When you think about your iPhone, it’s probably the product that you use most in your life. It’s the product that you have with you all the time. With this unique relationship people have with their iPhone, we take changing it really seriously. We don’t just want to make a new phone. We want to make a much better phone.
The changes in aesthetic between all previous iPhone generations were made for specific reasons. This year, the brief was clear: Thinner, lighter, “more room to work and play” (Schiller).
The iPhone is not a design playground. It’s too important to the people who use it everyday, and therefore too important to Apple’s business. Great design should make things look new, but only in the service of making great products much better.
12 September 2012
Farhad Manjoo pieces together some iPhone pre-history, using evidence submitted during the recent Apple Vs. Samsung trial. The effort and institutionalised secrecy involved in its production seems staggering.
Apple has an extensive array of systems to quickly create physical prototypes of digital designs, and the team would handle all of these prototypes and remark on how they felt. “We’re a pretty maniacal group of people,” [veteran hardware designer Christopher] Stringer explained, pointing out that they would sometimes review 50 different refinements of a single hardware button.
Yes, the patent system is broken. Yes, big corporations are litigious. The Apple Vs. Samsung verdict doesn’t change anything. It makes the patent system no more or less legitimate. It makes the act of suing your competitors no more or less morally objectionable.
But then you hear how a successful, disruptive product was willed into existence through years of hard work and secrecy. Then you see hundreds of prototypes that were painstakingly designed, tested and discarded. Then you get a sense for the tiny, “obvious”, details that were included because someone really used the device, every day during its creation.
Then, knowing all this, how can you begrudge the creators the opportunity to prove that their work was shamelessly copied?
This trial was not about the patents. The patents were just another piece of evidence that Apple used to support the story, that they poured years of hard work into the iPhone, which Samsung simply copied and reaped the rewards.
11 September 2012
As I speculated yesterday, 9to5Mac were not blocking the Instapaper bookmarklet. The site had been added to Instapaper’s publisher opt-out policy.
Marco Arment explains why it was him, and not 9to5mac, who instigated the opt-out: > The best way to prevent Instapaper from accessing 9to5Mac’s pages was to add them to the opt-out list. So I did that, thinking I’d let the dust settle and reevaluate that decision later once I had a better idea of how they felt about Instapaper.
As Marco admits, he overreacted, made a hasty decision, caused confusion and inconvenience for some of his users and probably didn’t do his reputation much good. But an explanation and an honest apology seems like a good recovery, to me.
10 September 2012
Harry Marks: > Now, why anyone from 9to5Mac would think anything from their site would be worth saving to read later, let alone at all, I don’t know. They apparently don’t read anything they write.
I’m not sure if 9to5mac.com is blocking the Instapaper bookmarklet. They could have simply opted out from Instapaper text parsing: > Most publishers value the increased engagement, retention, and social interaction that Instapaper encourages among their readership. But any publisher can choose to opt out of Instapaper text-parsing compatibility.
Whether you should choose to read 9to5mac, or its ilk, is another issue.
07 September 2012
Neven Mrgan: > Have fun, and remember: there’s no reason to ever have a bad meal in Portland!
I’m writing this in Portland airport, on my way back to London after a two week work trip.
During my trip I solicited and sampled some of Neven’s food recommendations. Now you can see them all on one convenient page.
My favourite dinner spots were Wafu and Pok Pok; both on SE Division. For brunch, The Woodsman Tavern was excellent.
I also spent a lot of time in the Stumptown Coffee cafés dotted around the city. Get a Chemex of the Gatomboya, if you like to start the day with a beautiful, fussy coffee
A Dash docset for Ruby on Rails 2.3, by Juan Ignacio Pumarino.
Unfortunately the repository’s feed didn’t work for me, which means I won’t get automatic updates.
To install manually, download the tar.gz or zip version of the source code, extract them and point Dash’s New Docset preferences dialog at the extracted source.
I assigned the Dash search prefix to :rails2, so I can search the Rails 2 and 3 documentation independently.
It would be helpful if Dash showed the name of the Docset against a search results, to help differentiate between versions.
25 August 2012
Harry Marks brings some much needed perspective to the recent spate of hypocritical ‘App.net is a country club for rich white people’ sensationalising: > Just a reminder: App.net is about making a better, more open Twitter competitor that doesn’t rely on ads to generate revenue. It was NOT designed as a way to keep poor people and minorities from using social networking tools. And if you do see App.net as a shift toward a “race war” or a “class war” on the Internet, please turn off your computer, call your ISP, and disconnect your service. Your privileges have been revoked.
21 August 2012
Aaron Swartz: > Fixed-mindset people feel smart when they don’t make mistakes, growth-mindset people feel smart when they struggle with something for a long time and then finally figure it out. Fixies try to blame the world when things go bad, growthers look to see what they can change about themselves. Fixies are afraid to try hard — because if they fail, it means they’re a failure. Growthers are afraid of not trying.
A joy to read.
(Via Kontra)
Nicholas Shaxson for The New Statesman: > The [City of London] corporation is an ancient, semi-alien entity lodged inside the British nation state; a “prehistoric monster which had mysteriously survived into the modern world”, as a 19th-century would-be City reformer put it. The words remain apt today.
Fascinating article highlighting the ancient, mysterious power of the City.
Shaxson’s book, Treasure Islands, is worth reading.
18 August 2012
As 10,000 early adopters pledge $50 each for early access to App.net, The Kernel’s Mic Wright, bemoans the ‘reverse gentrification’ of social networks: > But as Facebook and Twitter enter the mainstream, elites have begun to grumble that newcomers don’t know how to “do it right”, as if the cultural rules imposed by them in the early days are immutable. > > […] > > For all its philosophical posturing about Twitter being a big meanie and the nature of openness, what App.net is really about is that geeks are getting uncomfortable with normal people encroaching on their space. That $50 fee is the equivalent of a massive stone wall around a gated community.
This wilfully misses the point of Twitter, which appeals to diverse groups because they can coexist without ever acknowledging each other.
If Twitter becomes popular among people who’s updates don’t interest me, then I choose not to follow them.
Twitter encourages individuals to create their own personal communities, which are gated by the explicit follow mechanism.
Wright continues: > Underlying App.net’s manifesto, there is a simple sentiment: diversity sucks. What’s really tweaking the nipples of the snarky tech classes is that people who shop in stores that aren’t “cool”, don’t know a damn thing about Ruby and can’t afford a new MacBook Air every year are suddenly having fun on “their” social networks. Intolerable!
Personally, I backed App.net because I value diversity. But diversity comes in many forms, and I’m specifically interested in the diversification of Internet business models.
Why should the only viable online business be selling user’s eyeballs to advertisers? I’m more comfortable investing my time, attention, and yes money, in a customer-vendor relationship.
Wright’s sensationalising, tabloidesque perspective of the motivation behind App.net’s backers, also fails to acknowledge a larger idea: Alpha is just a reference implementation on top of the App.net infrastructure to help orient new users, which is why it looks like Twitter. Eventually Alpha should be free for everyone to use, and some of it may be supported by ads. But the real potential of App.net is as infrastructure for social web applications.
As Orian Marx points out: > Social web apps are built around concepts like users, posts, connecting and sharing. App.net will provide a scalable infrastructure and a base model for these concepts upon which startups can innovate without reinventing the same wheels again and again. Developers will spend less time just trying to make their applications functional, so they can have more time to make them unique and useful.
17 August 2012
On a recent project we used metaphors to help convey information about the system we were building, among our relatively small team.
The software was a run of the mill E-Commerce affair, featuring examples of customers purchasing products. There were rules effecting the sale of products, depending on certain properties of the customer, among other things.
After initial discussion with the designers, business people and information architects, we settled on the metaphor of customers taking a journey, guided through an online store, down a number of paths to purchase items. The items available for purchase along the journey depended on the customer, and their relationship with the business. Eventually, all journeys concluded at checkout, where external fulfilment systems provision the customer with their goods and services.
Initially, we started with a small team, working on a code base containing the usual suspects for building an online shop: An MVC application and a database.
After a few sprints the team was split into two, due to a desire to reuse the persistence part of the application across other business software. The metaphor (not fully explored) for the persistence layer emerged as a product catalogue; the canonical source of information for products sold by the business.
While we explored the guided journey metaphor, we neglected the product catalogue and allowed our understanding of layered software architecture to drive many design decisions: By thinking in terms of a service oriented architecture, we ended up building a horizontal slice (the database and REST API), and a single dumb client (the web application), that basically rendered JSON responses from the catalogue. The business logic for guiding a customer on their purchasing journey lived only in the horizontal product catalogue layer.
The metaphor was strained and unclear at this point and tension was building as we struggled to ignore the elephant in the room: the second client of the product catalogue service.
A third team started work on the second client of the product catalogue: An agent facing version of the online shop, designed to allow a sales representative to assist a customer with their shopping over the phone, in real-time. We quickly learnt that sales agents can deviate from the guided journey that the customer would be required to follow. In fact, the sales agents could bend our carefully constructed rules so much, that the API and business logic of the product catalogue was almost totally unsuitable for the agent-facing shop team to work with.
The product catalogue team attempted to meet the demands of these wildly different clients by declaring bankruptcy on their existing API and pushing more of the business logic out to the consumers. They reduced their responsibilities and went back to being a much simpler persistence layer, with a more generic search and purchase API.
All of the business logic for the guided journey now needed a new home. Some of it moved back into the client facing shop. Some of it moved to the agent facing shop. The common pieces of logic started moving towards a third system, to be shared by the two clients. For practical purposes, the two teams shared the code and started moving it into its own code base.
Throughout the project we felt the frustration of a metaphor that just didn’t seem to work. We spent a lot of time talking through the metaphor of the guided journey, without ever really reaping the benefit we felt it deserved. The reason for this, only became clear to me after recent conversations with Antony and Andy.
Instead of trying to stretch the edges of the guided journey metaphor past the point of usefulness, we should have embraced that pain and realised that a system can be usefully described by multiple metaphors. Had we recognised the product catalogue and the guided journey were overlapping but separate metaphors, we may have foreseen the problems caused by the next client of the product catalogue.
The agent facing shop, I have since recognised, could have used any number of interesting metaphors that ran parallel to the others. For example, what if the agents were super heroes, who were not bound by the same restrictions that mere mortal customers were? What if the world the super heroes and the regular people shared had emerged as a set of basic physical laws (a force like gravity; or a force like having to exchange money for products and services)?
If we had recognised the points where our metaphor was strained, and explored new metaphors as separate but overlapping things, perhaps we would have split our teams and systems differently; separating concerns and building a more flexible, emergent architecture.
Before this project, I appreciated that a metaphor can be a powerful carrier of information between small groups of people. I now believe that if we recognise a metaphor breaking down as a signal to split the system; a sort of ‘system mitosis’, splitting our existing architecture into naturally occurring interdependent systems. Together these systems, and their metaphors, convey a holistic story, and history, of their world in their own words.
15 August 2012
Andy Palmer used this description of Patterns, Idioms and Metaphors recently to help explain them to a client, which I paraphrase here for posterity: > Patterns carry a medium amount of information to a lot of people and cross language boundaries. > > Idioms carry a small amount of information to a medium amount of people; for example, “this is how we do loops in Ruby”. > > Metaphors carry a huge amount of information to a very small amount of people. A metaphor is something that works at the company level or smaller. It carries a lot of information and gives people within an organisation a common language. > > We find that if we boil a problem down to its essence by producing an appropriate metaphor, then that knowledge tends to spread among a small group faster, while retaining more useful meaning, than via other mediums.
Benjamin Brooks fantasising over Apple replacing Google search with a combination of DuckDuckGo and Wolfram Alpha across the board: > not only would this be a blow [to] Google, but to Microsoft as well. This would give people a true reason to use iOS and the Mac, it would keep money out of competitors hands, and would be a game changer.
One big problem with DDG is its localised search results, which are basically non-existent compared to Google.
If Apple added a third company to its list of acquisitions, one that had excellent localised search results, then this theory starts to sound plausible. Perhaps buying localised results from Bing, in the interim, would work.
14 August 2012
Dan: Can anyone in the chat room confirm that; how are our levels? Are we loud enough?
Marco: Are we level?
Dan: Are we level? Are we on the level?
Marco: Are we level enough for you?
Dan: Marco, are you on the level?
I needed a couple of quotes from this 5by5 podcast for a recent note, so I transcribed the whole episode.
One of the greatest quotes from this 1984 unused Apple commercial is from Macintosh marketing manager Mike Murray: > And I think what you’re going to see, is that the balance of power is going to shift; the balance of power from companies running people to, hopefully, people running companies. Murray never even mentions the product, but this quote speaks volumes for what must have been motivating people at Apple early on.
10 August 2012
I’ve been sporadically working on a project called papyr, for RiverGlide, since April. It was intended to scratch an itch that we had around making good reading material available at convenient times. You can read about the background, if you’re interested.
One of papyr’s two major dependencies is my favourite ‘read later’ service, Instapaper. We knew we wanted to make content available offline in a beautiful reading environment, and we were already Instapaper users. It seemed a natural fit.
Conceptually, papyr is very simple: it watches your Twitter timeline, looking for readable articles, rather than movies or images, for example, and saves them to a folder in your Instapaper account.
Two weeks ago we started allowing the first beta testers onto papyr. We quickly ran into problems, as our intended use of the API is technically against the Instapaper terms of use. Instapaper creator Marco Arment, explained his position in an email to me and made an exception for papyr, under the condition that we kept the volume per user to a reasonable amount per day, which we have done.
This whole experience has made me question our implementation of papyr. It partly solves the problem we had, but right now it’s at the expense of a service I value.
There was a timely discussion on this week’s episode of Marco’s podcast, Build and Analyze. During the show Marco answers a question relating to rate limiting, posed by a listener and Instapaper customer, who has also fallen foul of the new rate limits:
I did, about two weeks ago, as [Michael Festler] noted, add a rate limit to ‘adding things to read later’. And there were a few reasons for this. One of the biggest ones was that there’s a number of services cropping up out there, even though I forbid them in the API documentation, services that will basically pipe RSS feeds into your Instapaper account automatically. And what this results in, much more often than not, is people having thousands and thousands of unread items building up fairly quickly. And that pretty much ruins an Instapaper account for any real use.
That’s right: One of the offending services is papyr.
Marco goes on to explain: > And I don’t mean for everybody to read everything they save, I don’t even read everything I save; not even close, but, when you can very quickly build up ten thousand unread items, not only is the service not really meant for that and it’s very expensive for me to keep hosting, but it’s just bad for you, the user. > > Preventing that kind of build up, is important for the service to do, just to keep users from shooting themselves in the foot too bad. The service is not designed for that, it won’t work well with that. The app certainly won’t work well with that and it’s just a waste. It’s a waste for everybody.
I’ve experienced problems with the app on iPhone and iPad caused by these volumes. When the turnover of articles is high the app downloads hundreds of articles to the device whenever you launch it, which is twice per day when commuting.
Usually there isn’t time to load everything before losing signal (on a train, for example), which results in not having anything new to read. And now, because the older things have been pushed out to make room for the new, there isn’t anything to read at all.
The Instapaper iPad app, I have found, is also fairly unstable when dealing with a large turnover in articles. If I scan through a folder of one hundred unread items; reading, deleting, archiving and sharing as I go, the app will generally become unstable and crash after ten minutes. I can imagine this being a side effect of dealing with so many articles.
Marco also shared the article limit for each user: > So, I want to set this limit, somewhere that normal reasonable use is never likely to hit. And I think 120 per day, is not that bad of a number to set, maybe I’ll have to raise that; I’m certainly going to evaluate that. But I don’t understand, honestly, how somebody can save 120 things per day and actually read any meaningful portion of those.
And he’s right. Even on my best days I can only manage to read about twenty articles during a normal commute. And when I’m not commuting, as I haven’t been for the last few weeks, the unread list simply builds up to an unmanageable level.
Today I paused papyr for my account, which all papyr users have the ability to do. I haven’t been keeping up with what’s been saved for me recently, so it makes sense to take a break, and it will reduce the load on Instapaper a little.
But aren’t all Internet services, that expose APIs, designed to be mashed up and used to create amazing new things? Perhaps. But we should consider the cost to the provider and our impact on the service.
Some Internet services have grown large and successful because developers and third parties built on top of their APIs and created value that the service owners had never dreamed of.
They became platforms.
The best two examples, Facebook and Twitter are not, however, great examples of successful, sustainable businesses. One is hugely overvalued and its share price is currently collapsing under the weight of expectations, and the other still hasn’t figured out how to monetise its service, but its attempts have driven the early adopters to look around for something better.
Marco has created a business that sustains him and his family, simply by making a useful service, charging money for it and not spending more than he makes. He has, as far as I know, rejected offers to take funding.
For papyr, I believe this means that Instapaper can’t be part of our solution.
We built papyr with the genuine intention of solving a problem and making things easier. It’s not fair on Marco or the Instapaper customers, some of whom we hoped would become our customers, to burden the service in a way that Marco has specifically identified as detrimental for everyone.
Marco seems to be saying that Instapaper is not a platform: > So when you’re saving 49,000 or 50,000 articles, what could you possibly be using my service for that it’s going to work well for? > > That’s the big thing: What are you doing with all these things? And if the answer is, nothing you can possibly do with this can work well and can serve you well even, and I’m just taking on a big burden for hosting it all, what am I supposed to do?
If Instapaper is not a platform, then we’ll respect his decision and stop treating it as one.
04 August 2012
Antony Marcano explains the benefits of embracing the serendipity economy within an organisation: > Ensure that employees have social networking tools at their disposal. Share the ideas. Create a simple sign up page that’s sent out to employees or even the general public. Get feedback. Provide “seed-funding” to the projects that inspire the most passionate responses. Get the first few features built. See how hard or easy it is. If it works out, you’ll have empirical data to base future estimates on and you’ll have the beginnings of the product (maybe something releasable).
For established organisations, with a solid brand image, adopting an experimental culture may seem risky. How would you feel if your bank or insurance company started exhibiting the behaviour of a lean startup? Shareholders and the stock market may react poorly to this kind of apparently wild business experimentation.
But companies don’t have to drag their carefully cultivated brand through the uncertainty of the lean start-up mire in order to exploit the serendipity economy.
Using Antony’s MARTA heuristic, let’s try to think beyond risk mitigation: embrace serendipity and test our new ideas on the market, while protecting our established brand, and maintaining customer loyalty and shareholder confidence.
Let’s assume for the purpose of this thought experiment that our company has a reasonable handle on internal privacy and controls media leaks. We start by introducing access to an internal social media platform (like Yammer, or Glassboard). We actively encourage employees to participate in public social networks (Twitter, LinkedIn, Facebook et al.), while making it clear what information we do and don’t want sharing on these platforms. We provide time and space for employees to meet informally and encourage cross-pollination of teams, divisions and ideas. We introduce twenty-percent time and encourage people to self-organise around solving the problems that they care most passionately about.
When interesting new projects and product ideas start to emerge we help them flourish, while gathering feedback internally. When we’re ready to take the plunge and test an idea with the public, we can start thinking about managing the risk.
We could opt to mitigate the risk of our customers and shareholders losing confidence in our brand by testing our ideas quietly. A subset of our most loyal, sympathetic customers are a good place to start; friends and family are a relatively safe audience.
If we decide that an idea is contrary to our brand, values or the market for our idea does not appear substantial enough, we could simply avoid exposing it to public scrutiny.
We could reduce the risk of damage to our brand by framing the idea as research or as being “just a hobby”, as Apple has done with the Apple TV since its introduction.
We could transfer the risk to someone else by hiring a specialist company to build and test our idea under a totally different brand.
And if we decide that the idea is close enough to our core business that the risk of damage to our brand is acceptable, we could simply push ahead and test it out in the open.
Being a big, trusted brand shouldn’t preclude us from acknowledging, embracing and exploiting serendipity. Failure to innovate, invent and adapt can be a killer; just ask Kodak and RIM.
17 July 2012
Thomas Fuchs has created a handy flow chart (PDF) to guide you through the minefield of creating or modifying image assets for display on high resolution (retina) displays.
Fuchs is also writing a book on the subject.
12 July 2012
Benjamin Brooks on the new business model for The Brooks Review: > All non-members of the site will have access to every post that members have access too, with one caveat: non-members won’t see those posts until seven days after I posted them. Gutsy move. I’m looking forward to updates about the impact of this change on Brooks’ ability to produce work that he’s proud of.
I was hoping TBR would adopt a ‘pay what you think it’s worth’ model, as I suspect it gives a deeper insight into the true value of your work. With Brooks setting the price himself ($4/month), and not disclosing how he arrived at that price, he may have missed the opportunity to discover what value his readers really place on his writing.
However, this is a line in the sand. Other writers can use Brooks’ business model, and pricing as a precedent for going user-supported, and as a benchmark for setting their own prices.
11 July 2012
David Heinemeier Hansson, with an uncharacteristically non-inflamatory post: > To help someone move up the hierarchies, they have to have an intrinsic desire to do so. Arguments like “but it works” or “it gets the job done” are tell-tale signs of someone happy at the lowest level of the technical hierarchy and your cue to just quietly back out of the debate. The diagram of the different aspirational levels is necessarily simplistic, but seems like a useful heuristic for having productive conversations about technology choices. Or at least for keeping them short.
04 July 2012
A wonderful video of Jim Weirich refactoring a Javascript factorial solver into the mythical Y-Combinator function. The introductory explanations before the refactoring are worth the price of admission alone.
21 June 2012
There’s been a brouhaha recently about (mostly independent) Internet writers (not) making money from their web sites.
On one side are the read later services like Instapaper and Readability that allow readers to take the content out of its original site, remove all the ads and other extraneous rubbish, and nicely format the text and layout of the page for an enhanced reading experience.
On the other side are the poor independent writers, who live and die by the page-view. What happens if no one clicks their ads because they have been removed by a read later service? Where does their revenue come from?
There are any number of novel business models that independent writers use to bolster their meagre incomes; like selling premium content to subscribers, selling T-shirts and other swag and placing ads into their RSS feed.
But I would like to specifically address the issue of the read-later services. If someone is taking your content, modifying it from its original form and removing the ads, then perhaps a more subtle advertising mechanism is in order.
Movies and TV have been doing this for a long time: It’s called product placement and, if well executed, it can be very effective. I’m far less likely to be offended by well chosen product placement in a movie, than an image (or, horror, Flash) advert on a website.
If your ad is presented in a format consistent with the bulk of your core offering, text, then it’s likely to be better received by your audience, and much less likely to be removed by read later services for distracting from your actual content.
If your site is primarily about images, like Flickr or Instagram, then users will be more sympathetic to, and engaged with, ads that are images. Ditto for movies, ditto for audio.
Writers: if your business model requires ad revenue that’s fine, but make your ads text-based and relevant to your audience.
Ad syndicate networks: make your ads available to writers in well written plain text format, with a single link.
As a reader, I favour the whole-post text ad (a la Daring Fireball’s two sponsored posts per week). But I could tolerate a clearly marked in-line text ad for something relevant to me and the content I’m reading about.
And no, I don’t believe Readability’s shady revenue-redirection business model, which they ditched recently, is an acceptable compromise for readers or writers.
18 June 2012
Adrian Kinglsey-Hughes’ “Final thoughts on Windows 8”: > Bolting on a new user interface is one thing, but when that user interface is incomplete, it makes you question the value of having it in the first place. One of Hughes’ predictions for Windows 8 seems unlikely: > Windows 9 will look significantly different to Windows 8, and likely switch back to the ‘traditional’ Windows interface; As usual, Microsoft’s dependence on the Enterprise and the ponderous pace of change in corporate IT departments means it has to drag the baggage of the existing Windows brand and interface along for the ride.
If Microsoft push ahead and release Windows 8 as-is then I think it has to stick with it, leaning on the OEM vendors to push it to consumers and pulling strings at the upper echelons of big corporates.
Microsoft has been able to offer inordinately long-term support to big business customers for so long because of its unassailable market position in the PC era. The mobile and touch-based device market does not afford them the same luxury and they might just find the Windows baggage too heavy a burden to bare this time round.
I don’t see them backing away from Metro as a product, but I could see them splitting Windows 9 into more traditional desktop and mobile flavours; the former without Metro, the latter with.
17 June 2012
Michael August Pusateri, reacting to Kyle Weins’ lament about the upgradeability of the new MacBook Pro: > To ask that every piece of modern electronics is designed to allow the tiny fraction of hackers to upgrade is the height of hubris, unreasonable, and a huge imposition on everyone else that has no desire to ever crack the case. > > […] > Hackers, hot rodders, and makers will always find a way to do what they want, but it shouldn’t come at the expense of everyone else that simply wants a good, reliable product. Hackers don’t need approval, acceptance, encouragement or permission. They need what they’ve always had; curiosity.
Jack Cheng: > Timely not real-time. Rhythm not random. Moderation not excess. Knowledge not information. These are a few of the many characteristics of the Slow Web. It’s not so much a checklist as a feeling, one of being at greater ease for the web-enabled products and services in our lives. It’s interesting how many of the web-enabled things I use and value fit into this category.
15 June 2012
Transcript of technology writer Shawn Blanc on episode 65 of the B&B podcast, talking about ‘the state of RSS’ and its relationship with Twitter as a way to discover things to read: > There’s a lot of people saying, “I don’t check RSS. I just get all of my breaking news on Twitter.”, […] but what I like about RSS is that I can check it whenever I want. > > […] > If it’s important it will be there waiting for me in my RSS feed. If it’s on Twitter, you could miss it, or not. > > […] > Most of the time I only check those ten feeds that are my favorites; that’s what I look at every day because I enjoy reading those sites. And then for most everything else I find it through Twitter, right? That’s usually where you find the cool stuff. Most of the stuff, for my job, I discover through Twitter. Agreed. I discover far more on Twitter than I do via RSS feeds. > With Twitter versus RSS: You can still subscribe to something in RSS, but that doesn’t mean you’re ever going to see it again. […] Where are people actually engaging with links and articles? Is it in their RSS feeds or is it on Twitter? Personally, I discover and engage with more links and articles on Twitter.
Today I have an ‘Unread’ count of 1803 in my RSS reader. I subscribe to 118 RSS feeds. Of those subscriptions that post regularly I probably read five every single day, because I enjoy the writing. Once a week I skim through another fifty percent of the feeds and actually read about ten percent of those. As I was writing this, I found some feeds that I subscribed to years ago and have never read.
I follow 200 people on Twitter. I read Twitter sporadically and probably see less than thirty percent of the tweets on a given day. Of the things I’ve linked to on this site the majority (~80%) came from Twitter.
To keep the signal versus noise ratio high on Twitter, I have two criteria for following people: I have met you in person and/or you tweet things I find interesting or funny. If we haven’t met in person, I have no qualms unfollowing if your SVN drops. Nothing personal, we don’t have a relationship and I have limited time and attention.
12 June 2012
Apple updated the Macbook Air and Macbook Pro lines of notebooks today. I’ve been looking forward to this update for some time.
The Macbook Air got a significant specification boost including new Core i7 CPUs, up to 8GB of 1600MHz RAM and up to 512GB of SSD storage, on both the eleven and thirteen inch models. The Air also receive two USB3 ports and faster Wifi.
The flagship fifteen inch Macbook Pro got thinner, lighter and more powerful, as you would expect. It also has a Retina display.
This presents me with a dilemma.
Since its introduction in late 2010 I have used an eleven inch Macbook Air as my primary computer. The little Air has been the best machine I have ever owned and despite its size and specifications I have found it to be extremely capable.
But the eleven inch Air has some distinct limitations: The screen is beautiful, but short, which occasionally frustrates. The disk space is very limited at 128GB: I don’t store a lot of music or movies, preferring services like Spotify and iTunes rentals. The CPU is underpowered by modern standards, but it’s not a big deal as I don’t play games or do any intensive graphics work or movie editing.
The Air runs a web browser, the Ruby interpreter and Vim just fine.
My mind was made up months ago: As soon as the Air gets its expected Ivy Bridge refresh, I would upgrade.
Here’s the dilemma: The new Retina Macbook pro weighs almost the same as the thirteen inch Air and is practically as thin. Then there’s the screen. Just as the Retina displays of the iPhone 4 and New iPad called to me like Sirens through the mists of a shipwreck, so the new Macbook Pro is trying to lure me into its comforting glow.
The Retina displays on iOS devices are amazing. Sure, photos look sharper and movies look great, but for me its all about text. If you have an appreciation for the aesthetics of font faces and enjoy reading then you immediately understand why the Retina display is important.
This was supposed to be an easy upgrade. No decisions to be made.
To borrow an appropriate, if hackneyed, phrase: This changes everything.
10 June 2012
I spent twelve months pair programming every day on the project that Chris Turner describes here: > The conclusions that I have had to draw is that working in a paired environment is more mentally tiring that working alone or individually within a team. Compared to the rest of the organisation, the teams Chris and I worked on were extremely high performing. Each team used slightly different technologies and were effectively autonomous, but our common value was pair programming on all production code.
I believe the teams produced far better code, a far better product and in far less time, than we would have done working as individuals.
But my personal experience was similar to Chris’: Pair programming over an extended period of time is exhausting.
At its most effective, pair programming requires a massively high level of empathy, concentration and commitment from two people. That effort has to be sustained for hours in order to get things done.
Being totally engaged with a task and effectively narrating your thought process is a mental workout like nothing I’ve ever experienced. Some days I got home from work and was unable to hold a trivial conversation; I was mentally exhausted.
In our team we rotated pairs almost every day. A change is as good as a rest, as they say, and that was certainly my experience. It’s tempting to stick in a pair when you’ve just had a really great day, but it’s better to quit while you’re ahead and let some fresh ideas into the work.
We tried to maintain an odd number of people in the team and a backlog of non-production work that could be done by a lone individual. CI build scripting, production support, spiking new ideas, fielding questions from other teams and being on hand to help out a pair in distress are all tasks that you relish after a week of intensive pairing. Some of our best solutions to tricky problems and most useful non-production tools were built by ‘The Loner’.
When pairing on RiverGlide work we use the Pomodoro technique, which requires its own discipline. We find it usually helps to reduce pairing fatigue.
Pair programming can seem like a shiny new tool, and it’s tempting to use it all the time. Because it requires such high levels of engagement and experience, use it sparingly in novice teams; a little goes a long way. As the team gains experience using the technique it should start to gain an intuitive feel for when not to use it.
Back off to give individuals a break and recharge. Lean on it even harder to really crank through difficult problems. In pressure situations I’ve found it’s almost always better to have a pair.
Watch the movie and then read this brilliant dissection of the plot’s symbolism.
I was disappointed by Prometheus because I was hoping for a genuine prequel that explained the history behind the Alien movies. Prometheus is something else entirely and deserves to be judged apart from the Alien franchise.
07 June 2012
A potentially useful update to the iOS Instapaper app that will, according to the settings: > […] update automatically in the background when you enter or leave certain locations, such as your home or workplace.
I often remember to update Instapaper seconds before I’m about to enter a no-signal area. With this feature, my articles should already be downloaded by the time I walk from my house to the train station.
The UI for configuring background updating in the iOS app is a little confusing: From the Instapaper “Settings, Background Update Locations” menu, toggle the “Background Updates” switch to “On”. Instapaper then asks to use your current location. Once your location is found, two new buttons are displayed beneath the toggle-switch: “Add current location” and “Clear locations”. Below these label-buttons is another label showing the street name of your current location, with a little red compass icon.
At this point I was confused about whether the app was using the location it had just found, because the list of locations only contained a single item, and I couldn’t tell visually that this location was selected. I clicked the “Add current location” button, thinking that would confirm my choice, but that started the location search all over again. Instapaper found the same location again and added this duplicate location to the list.
I then selected “Clear locations”, and started the process again to get a single location in the list. To help confirm that the location was being used, I switched on VoiceOver, tapped the single location label and received audio confirmation that the location was indeed, “Selected”.
It should be immediately obvious that Instapaper is using a location for background updates but this interface design confused me. Perhaps using a check mark to the right of the list item would make the selection more obvious.
06 June 2012
Well written piece by Danny Sullivan on Google’s shifting policy on paid inclusion: > But disclosure doesn’t mean that Google is not doing paid inclusion, nor that Google wasn’t opposed to it in the past. It did characterize paid inclusion as some type of evil back then to be avoided; it clearly no longer views paid inclusion as evil but rather helpful in the search process.
It’s tempting to jump on the ‘don’t be evil’ bandwagon in these cases, but I think that’s missing the point. Companies are not good or evil, though it’s tempting, and simplistic, to conceptualise them as such. Companies simply reflect the most powerful and influential people at the helm, reacting to the business environment around them at a given time.
It used to be that Google’s organic search results were unequivocally great, but recently I’ve been using DuckDuckGo and found it to be adequate for about ninety-five percent of my web searches (localised listings aside).
The ‘don’t be evil’ mantra has out-lived its usefulness for Google, both publicly and privately. Google will continue to do what’s good for Google: We get to decide wether that’s good for us, too.
01 June 2012
Simon Baker compares the faltering progress of medicine and the corporate mindset that embraces the ‘billable hour’: > The similarities between bad medicine and the prevailing mindset that thinks in terms of billable time and efficiencies are merely illustrative. […] In physics the barriers to progress are perhaps theoretical. In oceanography perhaps they are practical. What are the barriers to progress in knowledge companies?
My terse answer; the people who own and operate those companies.
Whether change is incremental or transformative the dilemma is that markets change faster than mindsets. If a scientific and evidence-based profession such as medicine has been this slow to change, what chance is there of moving away from the labor theory of value – the modern day equivalent to bloodletting – any time soon?
The consequences of failure are not equivalent: People die when medicine is bad because nature is brutal, but in business there are safety nets and loopholes.
Moderately well informed executives and major shareholders have protection against the turmoil of markets via the legal system, which can grant second chances:
“Here’s your golden parachute, and here’s your next executive job. Don’t worry about making your next company more effective, we’ve got plenty more parachutes.”
My theory is that moving away from the labour theory of value takes a mindset shift at the very top of a company. Big, incumbent companies will probably never make that shift; they have too much inertia, too much protection from failure and too much to lose.
It’s up to the next generation of leaders and their organisations to demonstrate the value of throwing out the rule book along with the parachutes.
UPDATE: Simon points out that his comparison is specifically about the progress of medicine between the time of Hippocrates and ~1865.
16 May 2012
Rob Fitzpatrick has saved £10,000 and has four months to successfully bootstrap a product company in London, or go bankrupt trying: > I’ll publish my weekly bank balance, income, and progress, plus running daily updates. The challenge continues in public until I’ve either quintupled my money or have lost it all. I’m cheering for you, Rob!
14 May 2012
Andrew Wilkinson of Flow, talking straight about how he and his cofounders bootstrapped the product side of the company without VC funding or working eighty hour weeks: > Instead of distracting ourselves building pitch decks and flying all over the country, we allocated about 25% of the team’s time to client work and used that money to cover our development costs. This is roughly the same bootstrapping strategy that we’ve been taking with RiverGlide. We run a profitable consultancy company because we genuinely enjoy helping people do what they do, but better. Our numbers are currently inverted, however: roughly 75% of the team’s time is dedicated to fee earning client work and the remainder is spent on developing alternative sources of revenue and pursuing our myriad ideas for “making things easier”.
So far, it’s resulting in a slow-burn: We maintain a predictable income, which stops us worrying about money, gives us the head-space to deliver great consulting services to our clients and focus on other creative endeavours that interest us. It’s an exercise in patience.
13 May 2012
So the next time you hear someone talking about marriage between a man and woman being a Christian tradition, after you mention the same-sex marriages of the 10th-12 centuries, remind them that conventional marriage, marriage between a man and a woman, was derided, ignored, prohibited, diminished or dismissed by the church for ONE THOUSAND FIVE HUNDRED AND FORTY SEVEN YEARS.
09 May 2012
Benjamin Sandofsky discusses the highs and lows of building ‘shell apps’ versus native apps for mobile devices: > When people want a native app, they are asking for an app user experience, which is more complex than the web experience. […] > Web technology is great for many things. Replicating a native app experience is not one of them. I feel this way about the experience of using most web applications, even in desktop browsers. In my experience a dedicated native application, backed by web services, delivers a far better experience than a web application trying to emulate device functionality like gestures or view transitions.
With the rise of capable mobile devices and well crafted applications I feel far less compelled to use web applications. In fact, I often choose not to use an application if its main features can only be used via the web.
08 May 2012
A beautifully produced video of photographer Ian Ruhter’s ambitious project: > I didn’t just build a camera, I created a time machine.
Ian maintains a great tumblog of his images, too.
Via the inimitable @pro_cessor.
02 May 2012
A brief, well written history of chairs and the dangers of sitting: > The best we can hope for from chairs right now is a lesson on the dangers of fashion and a historical counterexample to the myth that the public acts in its own collective interest. If you want to sit healthily, you’ll have to take matters into your own hands; the best habit to develop is not to stay seated for more than ten minutes at a time. I really need to get better at taking frequent standing breaks.
28 April 2012
Great piece from Robert Cringely on IBM’s fixation on process over product, featuring a couple of classic Steve Jobs quotes: > Companies get confused. When they start getting bigger they want to replicate their initial success. And a lot of them think well somehow there is some magic in the process of how that success was created so they start to try to institutionalize process across the company. And before very long people get very confused that the process is the content. And that’s ultimately the downfall of IBM. IBM has the best process people in the world. They just forgot about the content. IBM won’t be the only big company to fall foul of this mentality.
Great story of a British sculptor, turned materials scientist, discovering the formula for her successful startup by chance: > Jane had stumbled on a product idea that mapped perfectly to a deeply held conviction: she hated waste. She was fed up with it and knew she wasn’t alone.[…] > > Her insight was that this space-age rubber she’d invented could be an essential innovation in this cause. She saw the potential in her chance discovery only because she had an overriding purpose that gave her a unique perspective.
22 April 2012
Chris Granger shares his thoughts about the recent buzz surrounding his demo video of Light Table: > This means lots of user testing, lots of iteration, and tons of exploration. In doing that, we ensure we’re not shoehorning features into contexts that don’t make sense and instead providing something that feels natural to the tasks at hand. Smart guy. Smart vision.
[The] team is presented with a detailed project plan and a set of requirements that it then works through, incrementally delivering software (but not to production) as the production release process runs at a different cadence. I’ve experienced the excitement of a high-functioning development team, and watched that team tear itself apart as it ploughs headlong into the process and politics of its host organisation.
The article hints at a solution: help the business close the feedback loop by getting software into production. Failure to remove roadblocks and deploy to production is as much a failure as not delivering at all; you can’t demonstrate value if your software is sitting on a test environment.
If you can’t get to production, for whatever reason, you may as well pack up, go home and stop wasting everyone’s time.
Dream with me for a moment. It’s not that hard to think of a world without cars. I haven’t owned a car for five years and certainly don’t miss it.
13 April 2012
Unlike most schools, there are no grades, teachers, or formal curricula. Instead, Hacker School is entirely project-based. These guys get it.
10 April 2012
Mark Zuckerberg announcing Facebook’s $1 Billion acquisition of Instagram (emphasis mine): > We plan on keeping features like the ability to post to other social networks, the ability to not share your Instagrams on Facebook if you want, and the ability to have followers and follow people separately from your friends on Facebook. It’s no surprise that Instagram have been acquired: Building a sustainable business always seemed like an uncomfortable question.
More interesting is that Zuckerberg sees Facebook so deeply ingrained in its user’s lives, that keeping data out of the social network is considered a feature.
05 April 2012
A wonderful video of Tom Stuart’s talk at the Ru3y Manor conference. The highlight is at ~17:15 where Tom has run into problems implementing the modulo operator using only Ruby procs, and turns to the Y and Z-Combinator functions for help: > The Y-Combinator only works in bat-shit languages, like Haskell… And Maths. I have now added, “implement FizzBuzz in Ruby, using only Procs, in a real programming interview”, to my life goals.
A thirty-minute video of a talk that Antony Marcano and I gave at the CukeUp 2012 conference in London yesterday.
We worked hard to distill the information we had down to just thirty minutes, without compromising the main messages. I’m really happy with how it turned out.
We found that the The Roals, Goals, Tasks model, combined with the ‘Chunk Up, Push Down, Refactor’ heuristic helped solidify our thinking on how we tackle these problems.
It’s hard to see from the video, so take a look at the final feature file and step definitions code for a better idea of the difference these techniques can make.
Having worked in Slough, I can vouch for the productivity boost one gets when not being there.
A video of Julien Biezemans, the creator of the Javascript port of Cucumber, talking about his year-long experience of working on the project. This is a slick thirty-minute presentation with plenty of code and examples of how to get up and running with cucumber-js.
This port seems most useful for people building full-stack Javascript applications; it wouldn’t make a lot of sense to use this where you could otherwise use the Ruby version.
A couple of Cucumber features have not yet been ported, like Scenario Outlines, and speaking with Julien after the talk it sounds like he would prefer not to add them.
I was in the audience for Karl Krukow’s talk at the CukeUp 2012 conference yesterday. Karl’s startup, ‘Less Painful’, is a cloud-based mobile application testing service for iOS and Android; think Sauce Labs for mobile apps.
Calabash, the technology that allows programmers to drive their mobile apps from the outside using a CSS-selector style DSL, is open source and available on Github.
This is an interesting and tricky problem to solve, and I’m excited to see how far Less Painful can take it.
28 March 2012
The Samsung Galaxy Note, ladies and gentlemen.
Jeff Atwood on the user-experience pox that is pagination: > In a perfect world, every search would result in a page with a single item: exactly the thing you were looking for. To me, pagination is a UX smell indicating that we don’t understand the user’s need. We just made someone’s life harder by lazily dumping stuff behind another set of interactions with the system and requiring them to do work to discover what we’ve buried. That means extra cognitive load, and extra clicks that are unrelated to the task the user was trying to complete.
27 March 2012
Incredible account of a start-up co-founder who followed the money, gave users what they wanted, then gave it all up because he hated working on the product.
A great example of profit becoming detached from purpose, and negatively impacting motivation.
Braden Kowitz discusses prioritising features with apparent value over those with discoverable value when building a product: > So when I’m working on a product, and we don’t have time to build all the features we want before the first release, I tend to focus on apparent value. Once we’ve proven the ability to get people in the door effectively, then there’s time to build more discoverable value.
19 March 2012
The Mini Maggie System is the world’s first full-range dipole speaker system that will sit on (and under) your desk. The Mini Maggie (satellite) is essentially a miniaturized version of the 3.7 midrange and tweeter. These look very exciting and the initial reviews seem positive, too.
15 March 2012
Great opinion piece by David Sleight on Stuntbox: > The people you’re calling “thieves” are telling you where you need to be. […] This is what’s commonly referred to in business circles as an opportunity.
AirBnb’s Chad Thornton writing for the Design Staff blog: > Pretend your portfolio is an online dating profile. What would it say if you looked at someone’s profile and all they had was a bunch of perfectly coiffed photos of themselves, with nothing written and little else — visual or verbal — to give you a better sense of personality?
In my precious hour, I am aware that it is quiet. During this silence, maybe nothing at all is built other than the room I’ve given myself to think. I break the flow of enticing small things to do, I separate myself from the bright people on similarly impressive busy quests, and I listen to what I’m thinking.
Every day, for an hour, no matter what. Mine is right now; six in the morning. I’ve already showered, shaved, dressed and made coffee. No one else is around and it’s really quiet. Bliss.
08 March 2012
Matt Hartley reacting to the launch of the new iPad, for the Canadian Financial Post: > In the fourth quarter of 2011, despite selling more iPads than in any other quarter to date, Apple saw its share of the global tablet market fall to 57.6%, down from 68.2% at the end of 2010, according to data from market research firm Strategy Analytics. Hartley doesn’t link to the Stratey Analytics data he cites, so I looked it up. As usual, this is market share based on units shipped, rather than purchased by customers.
One would think that such a subtle difference matters to readers interested in investment, but apparently not.
Hartley continues: > But will that be enough to cause Apple fans to line up outside the company’s retail stores on launch day next Friday (March 16)? I wonder.
06 March 2012
Offscreen magazine creator and editor, Kai Brach, wrote a piece on his experience bringing his idea to life. It’s a great read for anyone interested in Offscreen or the logistics of willing an idea from concept to cash: > When I set out to become a publisher around 6 months ago, I basically knew nothing about the indie publishing industry […]. In retrospect, I think this naïvety was rather beneficial, because at no point did I know what massive task would be waiting for me around the corner.
My copy of Offscreen’s inaugural issue arrived about a week ago and I’ve been slowly working my way through it since.
From the minute I took the magazine out of its carefully bubble-wrapped shipping envelope I knew it was something to be savoured. Each morning last week, I jumped out of bed, made some great coffee and settled in to the stillness of the early morning to pore over each carefully crafted page.
I don’t read a lot of design-related material normally, but Offscreen seems very approachable for non-designers.
Many of the articles are interviews with designers and don’t leave much room for lengthy narrative or expanded opinion pieces, however, the interview questions are direct and relevant, which leads to snappy-feeling answers. I never felt bogged down by excessively conversational dialogue or dull chit-chat. It all seems tightly edited and restrained: No filler.
The typography and layout of the magazine seemed clean, to my inexperienced eye. The choices of colour and use of imagery give the content a light, uncrowded feel that prevents fatigue while reading, unlike some print media.
One of Offscreen’s weakest elements is the photography. While the pictures are generally well suited to the content and have been carefully edited and placed in the layout, in some cases they are clearly amateur shots. The reason, understandably, is to control costs, as Brach explains: > Since there was literally no budget to send photographers to all of our interviewees, they themselves had to get active and ask friends or colleagues to take photos. This is a minor criticism, which didn’t detract from my enjoyment of the content.
Other than the interviews, a couple of unexpected features stood out: The ‘On The Desk Of’, double page spread is a quirky, fun, set of photos and descriptions of objects found on the desk of a guest designer. The company photo montage spots were tastefully done and made me feel a pang of nostalgia for my old chums at CampaignMonitor, whose beautiful offices were featured in images.
Overall I was thoroughly impressed by Offscreen. That this is Brach’s first attempt at a print magazine, and that he learnt all of the skills on the job, makes it an astonishing achievement.
Brach sums up his experience nicely: > The biggest challenge of this endeavour was not fighting off other people’s snarky remarks, but to keep convincing myself that I truly believed in it. Nobody doubted this project more than myself. I can’t wait for issue two.
02 March 2012
A transcribed snippet from a video of Matt Wynne’s talk on BDD, at the Agile Testing and BDD Exchange 2011 (~46 minutes in): > For maintainability’s sake and for the sake of enabling you to write the scenarios in your domain’s language, keep the step definitions really, really short and build a library of supporting code that can talk to your application so your step definitions become really simple; they just become really light-weight mappings between the way the business facing features describe what the test should do and code that can make that happen. Keeping Cucumber step definitions simple and domain focused was one of the problems we tried to address with our Cucumber extension, CukeSalad, which makes it possible to never touch a step definition at all.
In addition to fewer step definitions, with CukeSalad the Goals, Tasks, Actions metaphor helps focus attention on the domain and its capability, rather than the implementation and its features.
01 March 2012
MATTER will focus on doing one thing, and doing it exceptionally well. Every week, we will publish a single piece of top-tier long-form journalism about big issues in technology and science. That means no cheap reviews, no snarky opinion pieces, no top ten lists. Just one unmissable story. Now this is a compelling proposition. Consider it backed.
29 February 2012
What started as an internal collection of scripts has finally turned into a “real thing.” Scratching your own itch and turning the result into a paid product; I like this model.
25 February 2012
Rene Ritchie at iMore on rumours of Apple ditching the venerable 30-pin dock connector: > Not all current accessories would be compatible, of course, even if Apple offered an adapter dongle. It would upset as many customers as it would thrill. But Apple had never been afraid to ruthlessly jettison the past for a better future. Just ask the floppy drive, and now the optical drive and FireWire port. I’m particularly interested in how the recent million-dollar, Kickstarter backed, Elevation Dock project fares in the face of a change like this.
Via Daring Fireball.
20 February 2012
Microsoft’s biggest miss was allowing the world to finally see the truth behind the big lie — they were not needed to get real work done. Or anything done, really. Nailed it.
Via Daring Fireball.
17 February 2012
I’ve been doing a lot of application programming over the last eight months and it’s given me a new perspective on the use of Design Patterns in software.
Rather than “a general reusable solution to a commonly occurring problem”, I currently think of design patterns as a shared vocabulary for discussing the observable commonalities between two or more solutions, after they’ve emerged.1
While the shared vocabulary of design patterns might be useful for discussing something that’s already been done, I don’t find it helpful before or during programming.
I’ve noticed that when we discuss patterns before or during programming – especially pair-programming – it leads the tests and code down a route that they may not have naturally taken if we just focused on the desired behaviour, or the capability, that we’re trying to enable in the system.
Starting with a solution often encourages us to build things that only exist to serve the pattern; a sort of micro-scale YAGNI.
Of equal concern; the finished code tends to communicate more about the design pattern, than about our problem domain. When we return to maintain the code, we spend time identifying and discussing the pattern and reverse-engineering an imperfect understanding of our original intent.
I suspect design patterns are more helpful when building a framework or API, which is intended for reuse by a wide audience. Even so, the use of the pattern pays the largest dividends after the framework is in the hands of its users, who may grasp the intended usage and recommended application structure more quickly, by applying their understanding of the pattern. ↩
16 February 2012
Interesting experiment by Frankie Roberto, taking responsive design to the extreme by selectively displaying copy at different screen widths using HTML classes and media queries.
The tricky part seems to be designing your copy for mobile first.
I tend to edit copy from more words to fewer; the copy equivalent of designing for desktop browsers first. It may improve my writing if I can learn to write more tersely and add copy later.
15 February 2012
A gorgeous looking new quarterly, ‘physical-only’, magazine. From the About page: > […] We want to tell the less obvious human stories of creativity, passion and hard work that hide behind every interface. Sold.
(Via, Dave Greiner)
14 February 2012
Adam Grossman and Jack Turner’s weather predicting app, that we backed on Kickstarter, is starting to take shape.
Today they posted a screenshot of the iPhone interface.
The main interface component of the iPad version; the rain intensity timeline, has been compressed into the top third of the iPhone’s screen to make room for other information.
The middle of the interface consists of two horizontally stacked panels containing written descriptions of a) the current weather situation and b) what the next hour will bring.
Putting this information right in the middle of the screen, in prominent type, calls attention to the most important function of the app: Answering the questions, “Will I get rained on if I go outside now?”, and, “What about if I wait a while?”.
Smart move.
The bottom of the screen has a thin bar dedicated to location information. The compass icon on the left of the lower bar will presumably be for getting your current location, via GPS. The right panel of the lower bar has a text description of the currently selected location and a little cross icon, which seems a little confusing: I assume it’s for manually selecting a different location.
Looks like good progress to me.
10 February 2012
Eolas’ latest patent claim was thrown out of court in “just a few hours”. But, according to Wired’s Joe Mullin, Eolas had already settled before the trial with a number of big companies: > Those companies inculde: Apple, Argosy Publishing, Blockbuster, Citigroup, eBay, Frito-Lay, JP Morgan Chase, New Frontier Media, Office Depot, Perot Systems, Playboy Enterprises International, Rent-A-Center, Sun Microsystems (bought by Oracle while this litigation was underway), and Texas Instruments.
It’s win, win for patent trolls while companies are prepared to settle before a trial.
09 February 2012
Hot on the heels of the Honeywell/Nest patent debacle, from Wired’s Joe Mullin: > Michael Doyle, a low-profile Chicago biologist, claims that it was actually he and two co-inventors who invented — and patented — the “interactive web” before anyone else, while they were employed by the University of California back in 1993. Doyle argues that a program he created at the UC’s San Francisco campus, which allowed doctors to view embryos over the nascent World Wide Web, was the first program that allowed users to interact with images inside of a web browser window.
Via an iTunes Connect email: > Required iPhone & iPod touch Screenshot Upgrade for Retina Display > > When you create or update your apps in iTunes Connect, you must upload screenshots that are high-resolution. We require your screenshots as high-resolution images so that your app is optimized for the Retina display. When browsing the App Store using a Retina device, low resolution images stand out like a sore thumb.
See also, images on most websites.
08 February 2012
The Tumblr Staff blog: >Today you’ll have a new option to Highlight those extra-important posts. For one dollar, your post will stand out in the Dashboard with a customizable sticker to make sure your followers take notice! Tumblr seem to be keeping the monetization of their service meaningful, which is positive news for users.
By improving their service and charging for it, Tumblr users remain its customers, rather than its product: Tumblr are not serving ads and selling your clicks and page views to advertisers.
Enhancing a service, and charging a fair price for it, is a model that users should feel good about.
(Via Nancy Messieh at The Next Web).
Look. The U.S. patent system is protecting inventors.
Awful.
07 February 2012
Travis CI has become a registered company in Germany in order to take donations to support the thousands of open source projects that run automated tests on the service: > Travis CI has run 406,714 tests for 5,442 open-source projects to date, including Ruby, Rails, Rubinius, Rubygems, Bundler, Leiningen, Parrot, Symfony, … > > If you use any of these then you benefit from Travis CI. A great service to the Ruby community and a worthy cause. Count me in.
06 February 2012
Marco Arment, on the iOS Music app’s Previous Track button: > Stop making the “Previous Track” button behave like it does on CD players, where tapping it first brings you to the beginning of the current track, and tapping it again within a short time goes to the previous track. […] > > Instead, make it behave just like the “Next Track” button in reverse: always just seek to the previous track. The buttons are close together and I often hit the wrong one by mistake.
But I use the Instacast app, which skips backwards a configurable number of seconds; thirty by default. When the skip crosses a track boundary, it plays from the bookmarked position in the previous track, or the beginning of the track if no bookmark is set.
The ‘Next Track’ button behaves the same way, skipping forward in time.
03 February 2012
Matt Alexander, guest posting at The Loop: > Decision-makers are far better served by focusing upon building a product worthy of the adulation of its users, rather than attaining complimentary press. Envisioning the pleasure of the end user – let’s call it “user logic” – forces the idea to undergo development until it is something good.
Aside from being informative and beautiful, this is a great example of how horizontal scrolling keeps you hooked on the content.
Via Daring Fireball.
Alan Jones, at The New Agency blog: > Also, the cloud has ‘atomised’ how we advertise, service and support software. > > […] > And you don’t know [what happens if your competitors raise or lower their prices] because you’ve been building products atom-by-atom but selling them in buckets. > > […] There is a better way, and it is this: to atomise your pricing. > > Charge for your SAAS product the way you pay to serve it: in the smallest units you can. How many startups, or any software company, have the skill and discipline to reliably inject features into their product, while maintaining and supporting a growing user base that views their offering as fungible?
My bet: Not many.
02 February 2012
Alex Howard quoting James Stewart, on O’Reilly Radar: > “Most of the application code is written in Ruby, running on a mixture of Rails and Sinatra,” said Stewart. “Rails and Sinatra gave us the right balance of productivity and clean code, and were well known to the team we’ve assembled.” > > […] > The router for GOV.UK is written in Scala and uses Scalatra for its internal API, said Stewart. “The router distributes requests to the appropriate backend apps, allowing us to keep individual apps very focused on a particular problem without exposing that to visitors,” said Stewart. “We did a bake-off between a ruby implementation and a Scala implementation and were convinced that the Scala version was better able to handle the high level of concurrency this app will require.” A step in the right direction.
31 January 2012
Kevin Marks: > […] QR Codes ignore years of research and culture on how to communicate meaning in symbolic form designed to be captured by image processing tools behind a lens. We have this technology. It is called writing. It doesn’t matter how easy it is to scan a QR code, they’re ugly and meaningless to humans.
A transcript from a video of Avdi Grimm speaking at Mountain West RubyConf, back in November 2011 (~18:45 in): > You might have noticed a trend at this point: Going through a lot of strategies to get rid of nil. > > And I really think that nil is overused in Ruby code; it represents so many things: It can mean there was an error, it can mean there was missing data, it can be a flag for default behaviour, it’s the default value for uninitialised instance variables, it’s even the default return value for conditionals when you hit the un-handled case. > > As a result, I find that nil checks are the most common form of timid code. Avdi refactors a simple demo program during the talk, to demonstrate his “zero tolerance for nil” attitude.
The result speaks for itself.
28 January 2012
Neven Mrgan criticising the Amazon iOS app’s search bar: > The starting view promises that it includes a search field, and that when you tap it you will begin to type in it. But it’s all an illusion; that’s not a search field at all. It’s an active area which, when tapped, displays another, differently laid-out view. It’s a button.
I use the Amazon app, and the non-standard behaviour of its search field sometimes confuses me.
Mrgan goes on: > Not every app is made up of stock table-views and tab bars. Getting a bit more custom with the UI is cool. However, breaking user expectations isn’t.
The app continues breaking expectations with its ‘Recommended for you’ panel in the middle of the home screen, which can be horizontally swiped to reveal more recommended products. I discovered this feature by accident and have never clicked a recomendation because I use the app to search for something and then buy it.
Contrast this with the Apple Store app, which only uses horizontal swipe controls on full-screen product image galleries. This is consistent with my expectations for an iOS application: When an app’s chrome fades away I understand that the content is horizontally swipeable because that’s the same behaviour as the built-in Photos app.
Neven suggests a fix for the search problem: > How can this be fixed? In Amazon’s case, the search field should be a real search field, glued to the top of the view. I agree.
To fix the ‘Recommended for you’ panel I suggest removing it from the home screen altogether. Recommendations are already available from the ‘More…’ section of the navigation bar. Removing the panel would free up valuable home screen real-estate where higher value products could be promoted more prominently.
27 January 2012
From the, yet to launch, LiveMigrate FAQ: > Why do I need LiveMigrate? > > As owners of small businesses ourselves, we were frustrated at being locked in to antiquated software and annoyed that there was no easy way to move between accounting software products. If SaaS and Cloud™ services really are a big a deal, then migrating people away from their traditional systems could be a significant submarket.
Natalie Nagele of Wildbit, via Dave Greiner: > If we could go back, I think we would have closed it down a lot sooner. The honest truth is we haven’t loved it in many years. That said, Newsberry solidified some core beliefs we have as a team and a company. Working on what you love, what you use, and are proud of is the key to being successful. > […] We don’t feel a pulse on that industry and that’s ok. What a great experiment we had. Three products, one that we didn’t use ourselves and two that we use every day and love. > > And as expected, one had to go.
It’s sad for Newsberry’s customers, although striking a deal with my old pals at CampaignMonitor seems smart; the products share similar design and user experience philosophies.
The knitting-related community website, Ravelry, have been discussing how they make money: > We offer pay-per-click, pay-per-impression, and flat rate advertising to companies that are related to yarn and the fiber arts. > > I wrote an ad serving system specifically for Ravelry – since we serve our own ads, we don’t pay any fees or commissions to anyone else. > > Mary-Heather approves all of the ads that are placed and she makes sure that ads are as attractive as possible and that they are relevant to Ravelry (something to do with yarn). Ads are displayed in small number of locations on the site. It’s a mostly-free service, but the company is small, independent and profitable. I suspect their attitude towards advertising - respectful of their users - is an important part of building such an apparently loyal, engaged community.
A transcription of Merlin Mann discussing being self-employed, on the excellent Back To Work podcast: >What can be awesome, or awful, about being on your own is having to resell yourself, constantly. You’ve constantly got to show the value of what you do to people who are in a position to potentially pay you. > > If you had to go in and re-interview for your own job - with ‘The Bobs’ - every day, that sucks. I’ve gotten to the point, though, that I’ve realised if I have to convince someone that what I’m doing is valuable, it’s never going to work out. > […] If I have to educate you on the value of what I do, I’ve already lost my position of strength and it’s already told me we’re a bad match and that you’re not familiar enough with what I do; that I would have to tell you why that’s a good idea. This resonated with me. I experienced it early in my career, as a freelancer, and more recently as a contractor. It’s something all small independent businesses face eventually.
If you can’t easily convince someone of the value of your proposition, then will that person be a good customer for you? And will your offering be good for them?
26 January 2012
Jason Kottke, interviewed for ‘5 Minutes on The Verge’, on how he stays focused: > Becoming a father helped because, priorities! Plus, I really like what I do. And I long ago learned the value of unplugging and doing one thing at a time. Oh, and I almost completely ignore my email now.
Almost completely agree. Maybe I’ll give parenthood a try.
06 October 2011
As I sat typing this morning, BT walked into the room and told me that Steve Jobs had died. I stopped writing, fired up Daring Fireball and read the three linked-list items that Gruber had posted.
I felt a momentary flash of sadness and then read the quote from Jobs’ 2005 Stanford commencement address. The best part of the talk is the one that Gruber highlighted:
Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.
The first time I seriously took notice of Apple was in early 2002, as the original iPod was gaining popularity.
As a college student I couldn’t afford to buy a brand new iPod, so I scoured eBay and found that a number of sellers were offering deals that seemed too good to be true, which of course they were. This was the pre-gmail, pre bayesian spam filtering days and I was well aware that Internet scams were rife. Ignoring my head and following my heart I contacted a zero-rated seller who was offering a brand new first generation iPod for a price cheaper than brand new but still far more than I had ever paid for a gadget.
Pushing aside my nagging doubt, I dutifully wired the money to the seller via Western-Union transfer and waited.
And waited.
After several weeks and repeated un-returned communication with the seller I gave up and contacted eBay’s dispute department who put me in touch with the police’s fraud team. Thankfully eBay’s insurance covered the money, which was paid back in full.
I felt embarrassed and stupid. I blamed eBay, the scamming seller and even Apple: How could they justify making the iPod so beautiful and so expensive and so out of my reach?
I consoled myself by becoming anti-Apple; focusing on their lack of market share in the personal computing space, their elitist attitude, their DRM on the iPod and their apparently closed ecosystem. With a classic case of confirmation bias, fuelled by plentiful anti-Apple press, I hoped to quiet the strong emotional connection I felt to the quality of their products. I was jealous.
Six years later the emotional, hormonal roller coaster of life, loves and hates at college was a fading memory. I had dived into the viper’s nest of the financial software industry, where I tried, failed, laughed and cried at its unfathomable nonsense.
In a fit of frustration with work I emigrated to Sydney, Australia and bought a MacBook; the 2007, black, Intel Core Duo model. It was my first Apple product. I paid full price for it.
As I opened the amazingly well designed box I suddenly understood why care and quality go hand in hand. Here was the embodiment of that nebulous principle that I thought I understood. In my hands was the result of a million selfless acts of care.
That understanding I felt, triggered by the physical embodiment of a principle that I had struggled and failed to define, was due to the product of a unique organisation. That organisation is the legacy of a very special man, who remembered that he would die, and so followed his heart.
Thank you, Steve. Rest in peace.
05 September 2011
Using a qualified ‘yes’ helps keep the size of my commitments manageable and lets me get started on something I may not know how to finish yet.
The qualified ‘yes’ was intended to be used before starting work, to agree the rules of engagement; the goal of the task, how much time we’ll spend and which things we won’t do.
Usually the scope of a task fluctuates as we make progress, because we discover what’s really necessary to get it ‘done’.
To keep expectations aligned with current goals and constraints, and prevent surprises, I re-qualify ‘yes’ on a regular basis.
I think of the re-qualified ‘yes’ as a status report that includes ‘opt-in’ terms and conditions; an opportunity for everyone to decide if this task is still worth our time and attention.
30 August 2011
At work we have meetings.
Meetings tend to be self-replicating, self-perpetuating things: The more you have, the less time and attention you spend working and the more meetings you need to talk about how to get the work done.
With one of our clients, during retrospectives, the meeting facilitator draws a segmented circle on the whiteboard. The circle represents an hour and each of the twelve segments represent five minutes. This technique was borrowed from Phil Parker.
Every five minutes the facilitator indicates the passage of time by shading the next segment.
People can glance at the whiteboard to get a sense of how much time they’ve spent in the meeting and how long before it ends.
A simple, visual indication of time passing helps people agree when a topic has dominated the discussion. It also prevents a topic being neglected or worse, needing another meeting.
Motivated by our collective time and attention being sucked into the void I made an automatic version of the whiteboard meeting timer. The timer tells you when to StopThisMeeting.at
Using the timer is simple: Click the circle when the meeting starts. The current segment is coloured blue. Segments change from blue to green every five minutes, indicating elapsed time. Click the circle to reset.
Last week I tried it out during our retrospective. As the facilitator I was able to focus on the content of the discussion without breaking concentration to track the time. When we needed to move on, I simply pointed at the circle.
I’ve also been using the timer on my phone during ad-hoc meetings and stand-ups to help keep things focused. Just make sure the device doesn’t sleep or switch to screensaver mode during the meeting.
Please give the timer a try in your next meeting and let me know how it worked for you.
08 August 2011
One of the most helpful pieces of advice from T4HWW is to consume less information.
A certainty, like death and taxes, is that our time and attention is limited. The more time and attention we spend reading Twitter and cranking through our RSS feeds, the less hours and attention we have available for getting things done.
I’m a big consumer of information and I’m always trying to cut down. I’m usually way behind real-time in my Twitter timeline, RSS feeds and email. I follow too many people, subscribe to too many blogs and mailing lists and spend too many brain cycles trying to absorb and consider each item. It’s an infinite game that I’m never winning.
This full-fat, high sugar, MSG-soaked, trans-fatty-information diet, gives me broad knowledge of a lot of topics, which I rarely use to produce something worthwhile. Consequently, I generate a lot of ideas but struggle to execute on them because I just don’t have a deep understanding of any single subject.
Last year I spent some time learning Ruby in passive mode; reading a lot but producing little of value. Out of nowhere an opportunity came along to use this new knowledge. We were behind schedule at work and needed potentially months of code writing in just two weeks.
It was time to get to work and I couldn’t afford to be distracted. For two weeks I cut out all non-essential information intake and it had an amazing affect on my productive output.
There was no time for the sickly sweet drizzle of tweets, or the brain clogging stodginess of an RSS feed. Newspapers were out. TV was out. Email was definitely out. All Twitter clients (desktop and mobile) remained off for the duration of the two weeks. Email reading and response was cut to a single ten minute slot each day. If people wanted something urgently, they knew where to find me.
I kept my office door open and my RSS reader closed. I wore headphones at my desk, even when I wasn’t listening to music; people think twice about disturbing you when they can see you’re absorbed in something. It’s a subtle cue but it really seemed to work.
By day three I was feeling the itch, badly. Just a handful of tweets, just a couple of articles; something to satisfy the twitchy bit of my brain that loves to sink its teeth into juicy information. It was a big effort but I managed to resist the urge to snack.
I’m not talking about superhuman will power here; going cold turkey seemed extreme, so I allowed myself an hour of fiction reading before bed each night. I actually managed to finish reading a novel started six months before. An unexpected benefit.
On the strength of the first week’s experiment, I extended the information fast to weekends and was pleasantly surprised how much easier it was to relax and engage with the real people in my life. By the end of the two weeks the shakes were gone. I no longer craved social networking, email or articles. I was clean and it felt great.
With a bit of luck and a few productivity tricks (more on that in a later note), I hit the deadline at work and the results were well received.
The volume of work I produced in those two weeks was astonishing from a personal perspective and remains the most productive period I’ve experienced since the caffeine and youthful exuberance fuelled twenty hour programming stints at college. For what it’s worth, I produced over ten thousand lines of code in those ten days, most of it test driven and, for the most part, cleanly factored.
My usable Ruby skills improved beyond recognition and I gained a deeper, more practical understanding of the language and its tools. Those two wonderful weeks gave me more experience than the previous ten months of noodling around with toy projects and consuming reams of literature.
Since then I’ve slowly reintroduced some information consumption. I ruthlessly culled my Twitter-following and RSS lists and now guard them jealously. To this day I generally read and reply to email once per day, sometimes less frequently.
And it’s paid off. I’ve become more selective with the information I consume. I’ve been able to make more sensible choices when it comes to technical literature; only reading as much as I need to complete the most important task at hand.
I suspect most of us could afford to cut out a lot of the information we consume. Unless it helps us complete the task we’re working on right now then it’s just empty calories, and while tasty it probably adds little discernible value to our work.
Try it for a while. Turn off the fire hose, experience some precious mental quiet-time and really do those important things.
08 May 2011
In a recent podcast on programming languages, Dan Benjamin claimed that he prefers to work with a language that ‘looks good’.
Dan used Objective-C as an example of a language that he abandoned due to its poor aesthetic qualities.
Co-host John Siracusa grudgingly conceded that aesthetic quality is a ‘good thing’ for a programming language because humans have a built-in trait of favouring beautiful things purely because of their beauty.
I think, however, that the beauty of a programming language may actually have a benefit in helping programmers understand code.
Here’s an example.
When reading prose I find that my brain subconsciously trips over poor grammar, sloppy sentence structure, incorrect punctuation and spelling mistakes.
Tenuous metaphors make my brain work harder and steal focus from the author’s message.
Ugly writing slows down my reading, comprehension and appreciation of the work.
Similarly, my brain stumbles over certain elements of programming languages.
In the past twelve months I’ve been writing Ruby and C# in even quantities. I’ve noticed that the extra ceremony and non-word characters in C# programs cause the same effect as badly written prose on my brain.
I find it costs me more effort to work with ‘ugly’ programming languages, simply because of the additional mental overhead caused by poor aesthetic qualities.
21 April 2011
Recently I’ve been asked for advice on learning Vim.
If possible, I recommend pairing with an experienced Vim user.
Like learning a language by spending time with native speakers, you’ll pick up the ‘slang’ faster and get a feel for thinking in Vim.
If you don’t know a willing and competent Vim user, then read on for some advice and recommended resources.
If you’re a OSX user I recommend MacVim, which is actively developed, keeps up with the official version of Vim and has a “Mac look and feel”.
Vim is available on other platforms too.
Clear your schedule for an hour, type vimtutor from your shell and walk through this canonical interactive tutorial that ships with Vim.
It’s the best way to get started.
Tip: Vim is either in Insert Mode, which lets you type text, or it’s in Normal Mode, in which you enter commands.
Always be aware of the current *mode*.
When in doubt, press ESC to get back to Normal Mode.
Vim has a steep learning curve and I don’t know any shortcuts for mastering it.
My advice is to use Vim in your real work every day.
Once you’re familiar with opening and saving files, moving around a buffer (home-row keys only) and basic editing it’s time to move up a gear and get productive.
The screencasts Smash Into Vim parts one and two are brilliantly produced, packed with information and great value (currently $9 each with a PeepCode subscription).
Watch them in order and follow along. They’re suitable for absolute beginners but more experienced users will probably pick up something useful, too.
Vimcasts.org is the creation of Drew Neil.
This fantastic collection of screencasts covers a range of topics. If you’re wondering how to do something practical in Vim, it’s likely Drew has covered it. Browse through the back catalogue for ideas.
If you like your learning in bite sized pieces, then consider following @vimtips on Twitter.
The companion Vim Tweets website aggregates ‘official’ and user contributed tips.
Now you’re moving around text files with ease and Vim has become your go-to editor.
You’ve made some tweaks to your configuration files and maybe automated common actions with macros and scripts.
It’s time to unlock more power and learn from the masters.
Gary Bernhardt of Destroy All Software fame is a true power user.
Check out his vimrc on Github and watch his Vim-heavy PeepCode screencast to see some turbo charged Vim usage.
Once you get Vim into your muscle memory you’ll want to use it everywhere that text is edited.
Here are some plugins that imbue other programs with Vim.
Use familiar Vim movement keys to control Google Chrome with Vimium.
The Eclim and Vrapper plugins are available to give Eclipse a little Vim.
Firstly, my condolences that you’re forced to use Visual Studio.
Now go forth and install the ViEmu plugin for Visual Studio to make your editing a little less painful.
13 April 2011
Last night, at the Ruby on Rails Oceania (RoRo) meetup in Sydney, some folks from Salesforce.com came to discuss their recent acquisition of Heroku and what it means for developers in Australia.
No one from Heroku came. The Salesforce contingent consisted of two developer/evangelists and a couple of PR people and the main message was:
“Don’t worry, nothing will change. Everything will be fine”.
There were a lot of new faces in the crowd. Most identified themselves as being from The Enterprise. There were a lot more Thoughtworkers present than usual.
The talks covered some history and future strategy. Salesforce started as a Software as a Service provider but now have their sights set on offering a ‘Platform as a Service’.
As a platform provider the Heroku acquisition made absolute sense. Heroku are the model of PaaS for Ruby and Rails. They’re disrupting the sector, genuinely innovating and have a growing, passionate user base.
Another reason, not explicitly stated, for Salesforce to acquire a company like Heroku could be for its potential influence on The Enterprise.
That may sound strange. Ruby hasn’t really made a significant dent on the stalwart Enterprise platforms like Java and C#/.NET and there’s no real indication that such a thing is even likely in the near future.
But Ruby mind share is growing among developers, who are beginning to use the language and platforms like Heroku in small skunkworks projects within big companies.
An embattled project team can take a couple of Rails developers and build a working application, that business people can actually use within weeks, rather than months or years or never at all.
Forget long requirements phases, forget expensive architects, endless requirements documentation and acceptance testing dances. Just build something, ship it and see if people like it. Rinse, repeat.
Salesforce want a channel into The Enterprise. They want their platform and services hooked into as many big companies as they possibly can. Their revenue, presumably, depends on it.
From a business perspective it seems that Salesforce has been looking to the senior Heroku management to help them build their Platform capability, using Heroku as a model.
Some of that work will be winning over big integrators, as another route to getting Salesforce services into big companies from within the trojan horse of Heroku and Ruby.
If Ruby and Heroku are becoming the go-to technology choice for skunkworks projects in The Enterprise, and if a business can add Salesforce services to their shiny new Rails application via a Heroku add-on, then that seems like a pretty good looking channel.
03 April 2011
Lately I’ve been thinking a lot about capturing thoughts as they happen.
Last year during Rocktober, thanks to Andy and Antony, I developed a crippling addiction to index cards, post-it-notes and Sharpie pens.
While we worked, ideas were written on post-it-notes and stuck on the desk next to our keyboards. Once we’d collected a few related ideas, or observed a theme emerging among the notes, we’d write that theme on an index card, stick the related post-it-notes to the card and stick the whole thing onto an ‘Idea Wall’ behind us.
Over the course of the month we collected dozens of cards and hundreds of post-it-notes. From afar, the Idea Wall looked like a sort of city street, covered in flyers, posters and assorted graffiti. Looking closer revealed the story of dozens of conversations, thoughts, ideas and moments of inspiration.
Motivated by this I’ve since abandoned electronic note-taking tools and exclusively use notebooks, index cards and post-it-notes to capture and organise my thoughts.
Among the many great advantages of paper, cards and pens are immediacy and flexibility. Whatever I’m doing, wherever I am, ideas can be captured without breaking my concentration on the task at hand. I can organise and arrange the post-it-notes and index cards using any system; prioritise lists, annotate diagrams and construct complex threads of thought. I can write text notes or draw pictures. It’s a really versatile medium.
Lately I’ve run into some limitations of my system. The chaotic nature of many hundreds of notes, cards and scraps of paper is becoming a problem. They can’t be searched, or easily retrieved later. They don’t remember their context or when they were created in relation to other notes. They have to be manually maintained, kept up to date, edited, destroyed and recreated as the situation changes. They aren’t easily portable or shareable.
The system doesn’t scale.
In the past I’ve tried different electronic tools for ubiquitous capture and while there are excellent examples out there, they all create friction with the way I work and none of them solve all of the important problems I have.
Inspired by Marco Arment on The Build and Analyze podcast this week, I’ve decided to build my own system.
I want this system to be as fun to use as paper and pens; so maintaining the immediacy and malleability of physical tools is really important. At the same time I also want to make it elegant, powerful, and useful by solving some of the problems I outlined earlier.
Being a part-time project, for now, expect updates to follow sporadically.
Time to get started. Wish me luck.
28 March 2011
For the past year I’ve been working at CampaignMonitor. I mentioned them in my review of 2010. It’s been an enlightening experience and I’m massively grateful to Ben, Dave, Trish and the rest of the team for making me feel like part of the family.
But all good things must come to an end and so I’m leaving for pastures new. My next step will take me back from whence I came; to London, England. What could lure me back to that dank isle and away from the warm, sunny shores of Sydney? Something pretty special…
In October 2009, at the Agile conference in Chicago IL, Andy Palmer, Antony Marcano and I spent a whirlwind four days dreaming up the kind of company that we wanted to work for. In a tiny, cramped coffee shop named after some dead philosopher, that offered decent espresso and free wifi (the conference wifi was truly appalling, as is traditional at tech conferences), we talked, wrote, researched and deliberated over our shared values and beliefs. We retold war stories of hard fought and won experiences out in the real world, with real customers, working with real people and shipping real software. It was an eye-opening experience and shortly after we returned to our respective corners of the globe, RiverGlide was born.
In the two years, plus change, since that inception, Andy and Antony have been willing RiverGlide into life; working with clients who share our beliefs and values, presenting their experiences at conferences, teaching people how to be better at making software and shipping the occasional “product”:https://market.android.com/details?id=com.mofoapp along the way. I’ve largely been a spectator up to this point; isolated by sixteen-thousand kilometers of geography, ~11 hours of timezone difference and my own work. We speak regularly via Skype and rekindle a bit of that Chi-town magic but it’s not quite the ‘real deal’.
That’s all about to change. After a two week holiday in the US (San Francisco and New York) with friends, I’m moving to London to jump into RiverGlide with both feet. This feels like the right decision; based on about 30% brain, 30% heart and 40% exhilarating-fear-of-the-unknown.
Whatever happens, I’m keeping the following firmly in my mind:
There will be no regrets. This is an opportunity to build something with people I love, trust and respect. How many people get to do that in their careers?
One of the useful things I took from The Four Hour Work Week was that even if everything goes completely wrong, you can recover. This perspective is helping me keep that ‘fear-of-the-unknown’, or ‘The Lizard Brain’, as Merlin Mann calls it, in check.
Another paraphrased Merlin-ism that I love, is that happy people tend to focus on three things; ‘good decisions’, ‘good relationships’ and ‘good work’. I’m convinced that this move represents all three.
And I can’t wait.
This means that there’s now a job opening at Campaign Monitor. If you’re an incredibly talented software tester, programmer and all round excellent human being who is able to work in Sydney, Australia, and are looking for a new challenge with some of the greatest people I’ve ever worked with, then you should think about applying for my job at Campaign Monitor. You won’t regret it, I promise.
02 February 2011
In January of 2010, after five roller-coaster years, I resigned from the full time job that had brought me from London to Sydney via four continents. After working three months notice, I took three weeks of holiday, which I spent inert in bed accompanied by the worst flu I’ve ever had.
Then I started my new job at CampaignMonitor. It was a startling change of pace and a bit of culture shock as my working life went from 70-80 hour weeks, stuffed full of impossible high-pressure ‘just ship it’ deadlines to relaxed, 40 hour weeks with quality as the primary release driver.
I had been aware that a change of pace might affect me, like when you’re sick for the first few days of a holiday, but I never imagined the amount of sickness the first half of 2010 would bring. It truly was the worst year of my life for colds and flus. Every week I caught something new and eventually ended up in hospital for three days with suspected appendicitis, undergoing every kind of scan known to medical science[1], narrowly avoiding a precautionary appendix removal operation and ending with the exasperated medical staff proclaiming that it was ‘some kind of infection’, after I eventually responded to antibiotics.
My physical reaction to this new work environment, combined with the amazing quality and lifestyle-focused culture at CampaignMonitor was an eye-opener. In my humble opinion and limited experience, this really is a model software company; founded on simple, honest principles of creating a useful product that delights its customers, creating an awesome place to work[2] and being a sustainable and profitable business. There really is no bullshit here and that’s very liberating and inspiring.
After reading the Pragmatic Programmer in 2009, I decided to ‘learn a new language every year’ and in 2010 that language was Ruby.
Learning Ruby has been an absolute joy. Instead of gushing for paragraphs about how wonderful Ruby is, here’s a few tips I wish I’d had before starting out.
git reset --hard) until you don’t have to think about it anymore. The lessons in these koans are fundamental and having them ingrained into your mental muscle memory has served me well.I’d never really blogged before this year and don’t feel that any of my writing has been particularly useful, however, it has helped to crystallise some thoughts and I hope to continue in that vein this year.
To help with my Ruby learning I used this website as a breakable toy, experimenting with new tools and techniques. As of this writing it’s powered by Ruby, Sinatra, Jekyll, Heroku and a few assorted gems. I’m planning to push the source publicly to Github at some point in case it ever does something novel that will be useful to others.
A satisfying moment this year was having an article published for the Software Testing Planet, with my Campaign-Monitor-co-consipirator, Trish. We wrote about our experience with the wonderful, flexible, creative world of low-tech reporting using dashboards. We also collaborated indirectly on a bunch of other writing; most of the other notes I wrote last year feature thoughts and ideas that were formed after lengthy debate and mental jousting with Trish[5].
In October I journeyed to London and spent four weeks jamming with my fellow Riverglide co-founders Antony Marcano and Andy Palmer. ‘Rocktober’, as we dubbed it, was a month-long product development ‘jam’. We hired a beautiful office in Central London, generated dozens of product ideas, built prototype applications for Android, iOS and the web, got involved with local user groups and charities, sponsored and attended a great conference and generally just had a blast.
I could, and should, dedicate more time to talking about Rocktober, which I plan to do in a separate note. Getting together without the pressure of producing something for a paying customer is extremely liberating. I highly recommend it!
On top of all the great personal development I did in 2010, I still managed to squeeze in some real work! At CampaignMonitor we released a bunch of exciting new features, which all provided their own challenges. From testing the dynamic functionality of Autoresponders, to the technical challenges of checking a new REST API and webhooks, while supporting an aging legacy Soap API with automation coverage, it’s been an exciting and challenging year.
On my travels this year I met some fantastic people from all over the industry and all walks of life. From the guys and gals at XTC in London, to the Sydney Testers, it’s been a blast getting to know everyone a little better, hearing their stories and chatting about our lives, loves and losses. Thank you all for being great!
We’re already over a month into 2011, or ‘Oh-Eleven’ as I’m calling it and my next writing task will be a belated plan for the year. I foresee more Ruby, a new programming language (functional this year) and more travels, trials and tribulations. Here’s to a fun 2011!
fn1. OK, OK, there were probably a few scans I didn’t have.
fn2. We’re currently hiring designers right now, if you’re interested.
fn3. If you’re interested in metaprogramming, check out the Sinatra gem; it’s a quirky but fun example of idiomatic Ruby code.
fn4. Actually, I learned ‘just enough’ C# and ASP.NET MVC for work purposes
fn5. I encourage you to check out Trish’s blog, which she updates far more frequently than this one.
05 September 2010
Lately, I’ve noticed a trend in some of the writing and blogging about the software industry[1], which seems to advocate purposely limiting personal learning and development based on professional categorisation[2].
For example: If your professional categorisation (or label) is ‘tester’, then you should not be expected to study or learn anything outside some preconceived notion of a ‘tester’s responsibility’.
Perhaps these people missed the memo on T-shaped people, or are scared that the industry is changing and leaving them behind.
Categorisation and labels in software teams seem to be a subtle kind of silo. So, is that a bad thing? Should we care?
Why are labels a bad thing for people on software teams? What’s the problem with having a defined role and responsibilities? Why not categorise people?
People have been categorising (and labelling, once language came along) things forever. Categorisation is inseparable from cognition. In other words, humans can’t process information without applying some categorisation strategy to every single thing they can see, smell, touch, taste or hear. Categorising (and labelling) things helps us to communicate what we want, what we need and what we want other people to do for us.
So it would seem only natural to categorise ourselves in our professional lives. If you have a tooth-ache, you go to see a person who is categorised as a ‘dentist’. Need someone to help you out of a sticky legal situation, better find an expert in the law; a ‘lawyer’. Nice and easy.
Of course, your ‘dentist’ and ‘lawyer’ don’t only fit into a single category. When they leave the office, they also become a ‘motorist’ or ‘commuter’ on their way home. When they get home, they become ‘Mum’ or ‘Dad’ and at the same time they become ‘sweetheart’, ‘best friend’, ‘companion’, ‘competitor’ and simultaneously a bunch of other things, depending on who they’re dealing with and what they’re trying to achieve.
If our dentist or lawyer were only interested in learning about the things that allowed them to fulfil their professional obligations, then they’d find it difficult to integrate with the rest of the world. I’m sure you can think of at least one person who never really learnt how to interact in social situations and seems awkward and out of place at a party or family gathering.
Conversely, professionals inevitably bring knowledge and expertise from their other categorisations into their work. For example, our dentist might have children and know how to speak and act in order to gain the trust of a frightened toddler who is required to sit still while having their teeth examined.
Our lawyer may be an avid amateur mechanic who rebuilds classic cars in their spare time and uses some of that knowledge to help prove (beyond reasonable doubt) that you didn’t tamper with the brakes on your bosses car, when he dumped that surprise weekend overtime on you and made you miss that fishing trip.
Sticking to the boundaries of an understood professional category can be limiting; for ourselves and for our customers.
Why shouldn’t a ‘system-programmer’ know about the science behind user experience?
Would it be a bad thing for a ‘tester’ to know why violating the Liskov Substitution Principle will probably cause maintainability problems for a codebase in the future and likely causes understandability problems in the codebase right now?!
Being able to communicate effectively with people playing different roles on a software project, means studying and learning some of the things that make them an expert in their role.
Putting yourself in their shoes and understanding some of the problems they face, the constraints they work within and the heuristics they use to solve problems, makes you more able to help them do their job. It will probably help them to help you do your job.
Can you know too much? I think it’s unlikely that studying something outside of your role’s commonly understood sphere of knowledge will ever be completely useless to you.
We’ll never be an expert in everything (sorry about that). You’ll probably not even be very good at most things.
So if learning about something outside of our professional categorisation is a good thing, and we can never be very good at most things, then what should we study?
Start with your passions:
Like the idea of data visualisation? Have at it!
Social science and psychology is your thing? Go forth, consume that subject (you may be surprised how relevant your passion is to software projects)!
The idea is that learning itself becomes the passion. If you awaken your appetite for information, regardless of its relevance to your professional situation, then you’ll find it easier to learn things that actually do help you in your work.
Nowadays I think we’re mostly agreed that effective face-to-face communication is important for software teams. We’re also agreed that placing people into silos (read ‘applying labels’) reduces communication and can lead to unwillingness to take responsibility for things because they don’t fall specifically into the definition of their role.
It comes down to personal choice. Refusing to be bound by the limits of a category doesn’t have to be something encouraged by management, or fostered as a cultural change initiative.
As individuals, please don’t limit yourself, or each other, with labels.
fn1. It’s probably been the case for a long time, but I only just noticed it. And yes, someone is wrong on the Internet! I was surprised, too.
fn2. Don’t worry, naming names isn’t necessary for the remainder of this post to make sense and it’s more than likely to distract from the message.
01 August 2010
Picture the scene. You’re interviewing a tester.
The interview has gone great so far. The candidate appears personable, bright and has relevant experience for the role. You’ve set some traps in your interview questions and they’ve skillfully negotiated each one; deftly turning potential road-blocks into opportunities for you to learn about each other. You’ve spent a little time pairing on some software, alternating between ‘driving’ the testing and ‘navigating’, comentating as you go. Now for one final question - a formality, really…
“What do you most like about testing?”. You ask.
The tester turns to you, a thin smile forming on their lips. You’re convinced that you see a glint in their eyes as they answer:
“I like to break things.”
First and most importantly, a philosophical question: Is it possible for a tester to ‘break’ software?
Think about this question for a minute. I would argue that a tester can no more ‘break’ software than they can assure its quality. If you don’t have access to change the source code[1], then it must have been ‘broken’ when you received it.
A tester can use software in a way that demonstrates a potential problem for some person, under some conditions, at some time.
So if the tester didn’t break the software, does this mean that the software is ‘broken’ at all? Is there any advantage to describing it as such?
In this case, I contest that using language like ‘broken’ gives us no advantage when describing information revealed during testing. Consider the following example statement about a potential problem:
bq. “I was trying to run the ‘Widget quarterly sales report’ from the dashboard, but the ‘widget selection criteria’ dialog is broken!”
We can infer that the tester was looking at the ‘dashboard’ screen of the application and probably entering data into the form that allows the ‘Widget quarterly sales report’ to be customised before it runs. We can also infer that the tester was attempting to limit the results of the report to a particular widget or widgets, using the ‘widget selection criteria dialog’.
Unfortunately, from this statement, we can’t infer much more. Is the ‘widget selection criteria dialog’ not accepting input? Is it accepting input but not returning the expected results in the report? What are the expected results? Is the system crashing when we select items from the dialog? Is the system crashing when we run the report with this set of widgets? … Why should we need to ask so many extra questions?
The answer, lies partly in the use of the word ‘broken’ in our problem statement[2]. Think about how much easier it would be if we replaced ‘broken’ with this:
bq. “I was trying to run the ‘Widget quarterly sales report’ from the dashboard, but every time I try to select a widget from the ‘widget selection criteria’ dialog, an error message popup is displayed saying ‘invalid widget selected’.”
bq. “The widgets were available in the list, so as a report user I felt confused because I assumed they were available for selection.”
This is significantly better for anyone interested in the problem. Programmers can pick up this description and immediately attempt to reproduce the problem. They may even be able to look at the associated unit tests and production code that powers the widget selection dialog box and see what’s going wrong.
Project stakeholders now have an idea of the impact of the problem. They know who it will affect, report users, what the experience will be, a confusing error message, and how frequently it will occur, when the user attempts to do something fairly common with the reporting interface. Already the stakeholder is in a good position to make a judgement about the priority of changing the behaviour.
Not only do we provide more useful information when we avoid using the word ‘broken’ but we potentially avoid taking an adversarial stance on our bug reports.
The word ‘broken’ implies that someone is to blame. Who broke it? We established earlier that it wasn’t the tester who broke the software (they couldn’t, even if they wanted to). So it must have been the programmer.
In my experience, placing blame whether implicitly or explicitly is not a helpful thing in a software team. It’s not constructive, it won’t get the problem fixed sooner or better, and it certainly won’t endear testers to programmers.
In fact, I’ve seen projects and teams completely derailed by blame[3]. It’s a powerful emotional device and can quickly undermine a positive team culture.
What does it mean to be a tester driven by the need to destroy things? One outcome could be that this kind of tester’s favourite (and default) strategy involves using the software in ways that are dramatically different from the intention of the software designers.
Is this necessarily a bad thing? Certain kinds of perfectly reasonable tests involve purposefully misusing software and discovering information about its security and ability to be penetrated by attackers or malicious users. There is merit in this kind of testing, if it matters to people who matter. But is this information always important? Is it important enough to neglect other types of testing? As with almost everything in software; it depends.
If, as a tester, you’re always focused on a certain kind of test, or always using the software with a ‘break it’ mind set, then are you under reprsenting other kinds of users? What about the users who are just trying to get something done? How will the information you’re revealing about misuse of the software impact those regular users?
Why do testers claim to love breaking software? What’s the real motivation?
Is it the excitement of exploring the depths of a product and finding out how to cause a failure? Or is it the fact that it can be caused to fail and you were the one to find out? Do you just enjoy seeing something fail? Or is it something else?
Assuming that the reward is a ‘feel good factor’ associated with ‘liking to break software’, then at what point do you get your reward?
Is it when you find the failure? Is it when you share your findings with someone else? Is it when someone else acknowledges your destructive prowess?
Perhaps the reward lies on the positive side of the failure. Perhaps you feel good when the bug gets fixed? Or when the product ships without the bug and the customers are happy?
If so, how much of the reward is actually down to the ‘breaking’? What if it’s a small proportion? Does that mean you like some other aspect of testing more?
I find it interesting that people highlight the destructive aspect of testing as being one of the things they love about the job.
I wonder, if they were honest, they actually love helping their team create a great product, by asking questions, exploring and uncovering important value-threatening information. That’s certainly a big part of my motivation.
I’ve made some statements about the potential pitfalls of over-focusing on ‘breaking’ software and about how using ‘broken’ as a language device may be detrimental to a software team. Now I’m genuinely interested to hear from the self-proclaimed destructive testers.
Why do you love breaking software?
fn1. Modifying the software’s binary representation not withstanding, of course. How are your hex editing skills these days?
fn2. OK. The example is contrived, but I have seen and heard worse bug reports from testers and I suspect you have too.
fn3. I’ve seen blame used more regularly and to more destructive effect in larger organisations in almost every team and at every level. I would be interested to hear the experience of others on this topic.
25 July 2010
I recently changed my organization. A new job in a totally different ‘vertical sector’, for a company with a very different culture to the last.
For five years I was happily earning good money[1], travelling regularly for work to exotic locations, and working on difficult and interesting problems in a very demanding and dynamic.
I had fun, worked with interesting people and helped to deliver the odd project successfully. My career seemed to be progressing along a socially acceptable curve.
It wasn’t all roses though; the hours were insanely long, to the point that my social life was literally non-existent. The dizzying deadlines, budget constraints, finicky clients, difficult consultancy firms and legacy software were all starting to become a real drag[2].
Slowly my priorities were changing[3]. The company’s motivations appeared to drive its culture and shape our working environment, which I recognised as an obstacle to me doing work I could be really proud of. I was becoming increasingly aware that my motivation was quite different from that of my employer and many of my fellow employees[4].
I stuck with it and tried to figure out the cause of my discontent: After all, the people were pleasant, I was ‘succeeding’ and I still found the work interesting.
At first I thought we could work better. Perhaps there was a formula for this; a secret sauce[5] that could make us deliver amazing software, keep our customers happy and help us leap tall buildings in a single bound. If we all pulled in the same direction, change was possible. Right?
I started researching the ways other people were working in the software industry, joined mailing list discussions, took some training, attended a couple of conferences and met with like minded people. It was an eye opener but not in the way I expected.
Rather than discovering a series of rules or perfect methodology for success I found that the people I looked up to were actually motivated by a genuine passion for the work and a desire to better the industry.
They wrote books for almost no financial gain, they contributed with great care to open source software, they shared their knowledge in helpful blogs and articles, they spoke at conferences for little more than the cost of their hotel room, they recorded themselves programming and shared it for free and they patiently fielded questions from a wider community of frustrated software-industry workers.
And it was infectious. Just being around people like this seemed to switch on bits of my brain that had long since been suppressed by following the path of least resistance.
My priorities began to reorder themselves almost immediately: Building great products, working with like-minded people and customers, contributing to communities and working with joy, all took on new meaning and bubbled to the top of my list.
Towards the bottom of the list went the social-norms of the motivational world; salary, bonuses, ‘perks’, big companies and impressive sounding, but ultimately meaningless, job titles.
At first, it was frustrating and depressing. Realising that your motivation is incompatible with your employer’s can make you feel quite isolated. You want to behave in a way that befits your new priorities but doing so will likely not endear you to your co-workers and management (trouble maker!).
This was the moment when I knew it was time for a change. The company and I were just too different to make each other happy. We wanted different things now. I could continue doing good work for them (they were very happy with me) and they could continue remunerating me more than adequately, but we’d be living a lie.
They were the same as they’d always been. It wasn’t them, it was me. It was time for a change.
fn1. I got into ‘IT’ quite late, when I was thirteen, because I’d heard that there was a lot of money to be made. The dot-com bubble bursting as I left University was an excellent grounding in reality.
fn2. Yes, I can hear the tiny violins now. I understand that this is probably the software industry norm. But does it really have to be this way?
fn3. For context, my fascination with making piles of money evaporated at University where, ironically, I learned about the joy of self-education, which continues to top my motivational priority list today. I certainly learnt very little of any value from the lectures I attended but used the unlimited Internet access to teach myself about things I was interested in. I also played a lot of Quake.
fn4. I’m certainly not saying that if your motivation is different from mine that we can’t work together, or that you’re ‘wrong’. I suspect we will, however, naturally not see eye to eye on certain things. If those things happen to be important motivators for either or both of us, then that might cause friction.
fn5. For what it’s worth, I originally hoped that the magic formula for software success (there probably isn’t one) was buried somewhere in Agile (it isn’t), but I think that’s more a failing of the way Agile has been marketed and people’s - mine included - belief in marketing rather than a failing of Agile, per se.