The Hiltmon

Text Editing Fonts and Colors

2012-02-23T20:33:00-05:00

In The Markdown Mindset I described how I use a variety of different editors to write Markdown in different contexts. I also use different fonts and color schemes to help me differentiate as I go along.

For the record, everything was done in Monaco a few years ago.

Cousine

Blogging is done in Byword using Cousine 15pt and the light theme. It’s pretty close to Nitti Light as used in iAWriter, but has variable sizing and is free from Google. I really like it in Byword because they render the font a tad large and it matches their cool anti-aliasing scheme.

Menlo

Programming is done in TextMate using Menlo 12 and the RailsCasts theme. I switched from Monaco to Menlo in Textmate 2 and I’m not going back. Monaco’s line spacing in TM2 was too tall, Menlo is just right.

Cocoa work is done in XCode using Menlo and the default theme. After seeing all the Apple demos, to me that’s what Objective-C needs to look like.

Long form writing in Scrivener is done in Menlo as well now. I really do not like the default Optima. I used Cousine for a while until one day I tried Menlo and it just looked smoother.

My terminals are also set up to use Menlo, and I use a custom theme that integrates cyan and yellow into the prompt and ls colors.

Consolas

Note taking is done in BBEdit using their tweaked version of Consolas and the default theme (I have set up RailsCasts for code files as well). Something about working in BBEdit makes we want to use Consolas and get that old-mac editor look.

So bye bye Monaco, my old friend. You served us all so well for so long.

Apple and Facebook

2012-02-22T14:05:00-05:00

Ben Parr in Cnet’s Apple vs. Facebook: Why users are the losers gets it wrong!

In the article, he postulates that Apple’s favorite social media service is Twitter and that Apple just hates Facebook (really?). He then explains there is no integration between Apple and Facebook because of some old Ping issues and some HP rubbish and some unsubstantiated hatred. Then he mentions that there actually is some Facebook integration, but its sandboxed in iPhoto.

The real reason there is no integration between Apple and Facebook is because Apple is not in the business of selling out its customers. In the Twitterverse, the tweet is the product, and integration requires a login and password with no other data sharing with Twitter. With Facebook, the user is the product, and integration requires Apple to share the user’s information with Facebook to make it work.

Apple is not prepared to that with Facebook without their user’s consent. So no general Facebook integration.

I am a Facebook user, and I totally agree with Apple’s stance on this one.

The Markdown Mindset

2012-02-20T20:07:00-05:00

Over the last year, I have moved all my non-code writing to Markdown format. I don’t even have Microsoft Word installed on my laptop anymore. Here’s why:

It’s just plain text

I have been using personal computers of some kind or another since 1981 (my first being a Sinclair ZX81). One of the problems I have faced time and time again as I have jumped to newer computers, different operating systems, and different tools is that I have been unable to convert my documents from the old to the new. In many cases, I could have done it, but now it’s too late. Nothing these days reads some of the old proprietary file formats I still have. Which means the data is probably lost.

Markdown is text, just plain text. Its the one format that has not changed over all the years. Oh sure, we’ve gone from a 7-bit ascii code to UTF-8, but all text editors happily handle the old text formats. And when they stop, a small C program will fix it.

Plain text, and therefore Markdown, are as future-proof as you can get in computing.

It’s all about the writing

The big problem with many tools used for writing (ok, mostly word processors) is that there are too many things you could be doing instead of writing. You could be playing with fonts or styles, futzing for ages trying to make the document look right, work the number styles, headers and footers and resizing the margining.

Or you could be writing.

With Markdown, the font, style, margin and other stuff all comes later. All you have is the text, the basic structure and the options for bold, italic, lists and tables. That’s it! There’s nothing else, so the writer is encouraged to write.

It’s also easy to read. As I write, I often go back and read what I just wrote, to check flow, spelling, grammar and content. Since the markup in Markdown is unobtrusive, it’s easy to read. And since the markup does not change the style, you focus on the content instead.

It’s tool-agnostic

Plain text, and therefore Markdown, is tool-agnostic. One can edit it in a myriad of tools. On a myriad of platforms. In whatever way the writer likes.

What I actually do is to use different tools to help me get into the mindset for what I am doing in Markdown. When I am blogging or writing short articles, I’m writing Markdown in Byword, previewing in Marked. When I am doing a manual or a bunch of related documents, I work with Markdown in Scrivener. When I am taking notes, logging my programming work or creating release notes, I use Markdown in BBEdit. Programming readme files, Markdown in TextMate. I could use any of these tools for any of these tasks if I choose, and I can move the files from one to another without any loss of fidelity.

It just gets better with sharing. When I share these files, those shared with can use any tool of their choice to modify the document. They don’t have to have or use the same stuff as I do. As long as it stays a plain text Markdown document, they can use what they want and I can still merge in their changes. They may want to use vim or gedit on linux, Notepad or UltraEdit on Windows or pretty much anything on the Mac. But the file remains the same across all.

It transforms into any format

The initial use of Markdown was to create HTML content. These days, with tools like Marked and Scrivener, and the MultiMarkdown scripts, the Markdown plain text can become PDF’s, Word Documents, RTF Documents, even Latex files (See MultiMarkdown Features) without any effort. One simple source format for many delivery formats.

Which also makes each file reusable. The same source file can be used in the web site knowledge base, in the manual and in an email.

And a whole bunch more

Being plain text is great.

Plain text is searchable, some of the proprietary formats are not.
Plain text works on all platforms, not all formats can be read on them.
Plain text files are small. Plain text is fast to read and write to disk. It makes for small mail attachments.

Daily uses of Markdown

Here are some of the things I do almost every day in Markdown:

Update my DayOne journal in Markdown
Write my software development and project notes in Markdown using BBEdit
Write a blog post in Markdown using Byword
Add to the KifuApp Knowledgebase using Scrivener in Markdown
Maintain the documentation for my projects in Markdown in TextMate

And one thing I never expected to do in Markdown:

Log all messages from my “Import to Kifu” process in Markdown, so that the import log can be sent prettily formatted to clients

Getting started in Markdown

It’s easy. Start with your favorite text editor next time you need to write something instead of using whatever you usually use. Learn the markup as you go and need things. That’s all there is to it.

Just write.

You’ll be surprised how productive you will be.

Markdown references

Markdown, the original, by John Gruber
MultiMarkdown by Fletcher Penney, which adds new exports, syntax features and document metadata which I love.
Byword MultiMarkdown Guide, a great one page reference by the makers of Byword.

The 4G deception

2012-02-17T12:45:00-05:00

These days, all the US mobile carriers are touting their allegedly hot new 4G networks, pushing people to upgrade their phones and get up to 10x faster mobile data speeds.

Note the only single consumer benefit touted is a possibly faster download time, it is not guaranteed.

This whole thing is a deception. Here’s why.

The 4G Deception

Sprint and Verizon are making 4G networks, using WiMAX and LTE. This is real 4G. In 2011, AT&T and T-Mobile were not using LTE yet, they just rebranded their HSPDA+ 3G networks with faster speeds as 4G. (Reference: How AT&T and T-Mobile conjured 4G networks out of thin air). In 2012, AT&T says it has a LTE rolling out, but it’s promoting that it’s 4G service is really a dash of LTE and a lot of HSPDA+.

But what does an LTE network actually do for customers, over and above the possible speed increase? It’s the next global standard, so roaming will work, okay, and it should have less cross-interference between cell users, rare but okay, and, and, thats it! No better coverage or in-building penetration, no longer battery life, no cheaper services, nothing.

And only available in big metros, so you pay the 4G price for 3G service is most places anyway.

The Cap Deception

It really sounds great to have a faster network, but in this world of data caps and throttling, all it means is that customers get to their data caps faster. Benefit to customer, none. Benefit to carrier, they get to nail more customers with overages and gouge them mercilessly. Its the ‘free credit-card’ scam where they hit you with an usurious interest rate all over again. They can almost guarantee that most 4G customers will exceed their caps early in the month and often exceed the next level cap as well. I mean, 2GB then two more, that’s nothing when people are watching movies over the mobile data network.

The carriers, especially the LTE ones, are absolutely drooling over customers who roam. They see not only gouging on roaming rates (which they already do), but even more roaming data transfer, and therefore more roaming data rate income. Given that roaming rates are already insanely high (and even more profitable), this means they get to take more out of the customer’s pocket before the customer even knows about it.

The Service Deception

They all promote 4G as the best new thing, Verizon especially selling on the brilliance of “the network”. But they do not discuss any improvement to existing services on these networks. Consumers assume new means better, and consumers do assume that 4G will reduce dropped calls, coverage issues and slowdowns. None of the carriers explain that the 4G networks will do none of these things, you’ll get the same coverage issues, same dropped calls and the same slowdowns at peak hours. This magical network may be better is some imaginary way, but the consumer’s service will still suck. (See 3G vs. 4G: What You Should Know Before You Switch)

The Hog Deception

As with any service, there are those who use more than others. Some mobile users use more data than others. The carriers coined the term “data hog” as a derogatory reference to them, then set out to blame these customers for terrible network service all customers get, and used this made-up excuse to cap plans. This is the most egregious deception.

It costs a little money to add capacity to the network (and a lot if the cell towers need upgrading or adding to). It costs nothing to add a new subscriber, it makes them money instead. So carriers skimp on adding capacity and go nuts trying to add subscribers. To the point that they are so far oversubscribed for the capacity that they have, that even ‘normal’ users notice the slowdowns. So, instead of fixing the problem and bringing capacity up inline with subscriber growth, they deceive. They imply that network capacity is limited, not true, that adding capacity is expensive, even less true (unless new towers are involved), and that the reason the network is slow is because these made-up customers are using all the available capacity! If you believe them, I have a nice bridge to sell you in Manhattan.

When called on this subscriber vs capacity issue, the carriers have stated that everybody does this, so its normal and OK. ISP’s oversubscribe internet access capacity, cable companies oversubscribe television channels on their cable feeds, airlines oversubscribe flights. Just because everyone else does something does not make it right! The idea behind oversubscription is based on the concept that all users of a service will not all need it at once, so the service can be shared. But the carriers have long gone past the point where even the few using the network at a time are not exceeding that network’s capacity.

The Open Deception

And interesting omission from all the carriers on 4G data is that none of them actually promise that this magic new network will actually deliver what people want. The FCC allows carriers to throttle, censor and block services on the mobile data network. Consumers incorrectly assume that the 4G network, because it is faster, and so much ‘better’, means that this throttling, blocking and censorship is no longer necessary. Not true.

None of the 4G networks promise unfettered access. None of the carriers offer an open network. All of them are trying to create their own content services to compete with iTunes and Netflix, and are shaping their traffic so that mobile users will turn to their expensive services rather than deal with throttled or limited access to better and cheaper services. 4G does not, in any way, open up the network, no consumer benefit here either.

The Benefits Deception

You can watch movies on your phone. You can download and listen to music on it. Watch live TV on your mobile devices. These are the touted benefits of 4G. In reality, all they are saying is that you can get these things faster, with less waiting.

What they are not saying is if you can do this faster, you will do it more often. Which means you will use more data, and rely on using more data. In which case, you will reach your cap sooner and let the gouging feast begin. This means that on 4G, with the ‘standard’ 2GB cap, if you download a movie on day one of your billing period, you will exceed your cap, and have to pay insane charges for additional data.

Consumers want the benefit and convenience of using more mobile services and data, but the cost to consumers of these benefits outweighs the benefits themselves. Buy and download a $4 3GB movie on your mobile phone and it will cost $4 plus $20 for exceeding your cap. Some benefit that is!

So what can we do about this?

Man, I wish I knew. The carriers own the FCC so this mess is allowed. There is no consumer protection agency on the USA to protect us from them. And given that 320 million Americans are covered by just 2 carriers and 2 mega carriers, there’s no competitive reason for them to offer consumers anything more than the current rip-off.

In short, the only thing we consumers can do is complain and be ignored, write ranty blog posts like this one and stay on our 3G contracts.

All to Octopress

2012-02-16T19:51:00-05:00

I have moved all of my sites over to Octopress by Brandin Mathis. This means hiltmon.com, noverse.com and shukaico.com are all on the same platform.

Why?

Markdown everywhere: I pretty much use markdown, or really the multi-markdown variant, format for everything these days. I just love it. All files are just plain text so I never have to worry about vendor lock in (I still have some old Lotus Smartsuite files I cannot read), they are searchable and easy to maintain. All posts in Octopress are just plain markdown files.
Baked: Unlike most other blogging systems, Octopress has no database, no server software to install, no dynamic caching needed and no need to configure the server. The web site is generated as plain old HTML files with a bit of Javascript. This means that user requests are just plain old HTML requests, requiring no processing on the server to serve, and leveraging the servers built in caches. It’s the fastest way to serve a blog, and it can handle being fireballed (when you get linked to by Daring Fireball and millions of geeks try to load your web at the same time).
It’s ruby: I do all my web work in Ruby on Rails or Sinatra, so using the mojombo/jekyll engine on my local machine just fits the bill. Tools like rake and formats like markdown just work for me.
I can hack it: A few tweaks to the rake file and I have the new_post action logging to DayOne and opening Byword with the new post.
Great, simple design: I think Brandin Mathis did a great job on the default layout, fonts and color schemes. A lot of influential bloggers (Matt Legend Gemmell, I’m looking at you) feel the same way. So I have pretty much left it alone.
Easy to set up: Clone it from GitHub, fill in a few fields, create a few files and generate. You have a site. Set up a few more fields and you can rsync it to the server without a hassle.

But I do miss a one thing though, I miss editing and maintaining my blog in MarsEdit. Oh, I know there are hacks and workarounds to manage an Octopress blog with it, but they are messy and leave my system feeling all dirty.

So thank you, Brandin Mathis and the Octopress team for a wonderful platform for us all to enjoy.

The App Store playing field

2012-02-16T18:52:00-05:00

Excellent article by Emeric Thoa in The Game Bakers called Money And The App Store: A Few Figures That Might Help An Indie Developer where he covers some myths about the app store and provides advice to indies trying to make it there.

I’m going to borrow his myths and reference my own experiences with my own apps.

Myth #1: There are so many iPhones and iPads out there that any decent app can make you rich.

I had a free app and a paid app. When I made the free app 0.99c for a few weeks, I had no sales. When I made it free again, I had the best day ever in terms of downloads (but no money). My paid app grossed less than $500 over 2 years!

The point here is that the user base might be huge, but a lot of people never pay anything on the App Store, so don’t get blinded by the potential and stay rational.

Myth #2: Making an iPhone app is fast and cheap

I have covered this before in How Much Does It Cost to Develop an iPhone Application? and agree with Emeric here.

If it costs less than $100,000, you’ll never be competitive.

The sad thing is, there is a large number of cheaply made, rip-off and copycat apps out there that are made on the cheap and sold on the cheap, that the diamonds get lost in the glass shards.

Myth #3: Updating your app will make your sales increase over time

2 years ago, app updates made the news. Today, they do not. You may get a small spike in downloads on an update from your active users, or a small spike in response to your tweets, but that is all.

What is worse, the App Store is creating a group of users who believe they ‘deserve’ free updates, no matter how much the upgrade costs the developer.

Myth #4: Being visible on the App Store just takes a good post on reddit or a good viral video

And a whole lot of luck. In order to get reddit or viral traffic, you need to hit the jackpot and post your news as and when the most influential people on these services happen to be there and looking for your kind of thing. In reality, reddit and the like posts last about 1 hour on the new page before getting pushed down the list.

Getting exposure so people learn about your app is what you do the rest of the time after shipping. It’s a long hard slog. And few hit the winning numbers.

Myth 5: Getting featured by Apple is completely random

Not true, Apple has editorial guidelines, choosing apps that are unique, well designed, target the largest audience of the store, showcase their products well and you are a publisher with a track record. Now you know what to do to get on the list.

It seems to me that getting featured by Apple is one of the biggest wins, but rarely happens.

The reality

2 years ago, when launching my paid app, I issued a press release via the reputable PR firm prMac. They did a fantastic job, with over 18,000 hits on it on release day, which led to a few conversions.

After half a year on the store, I dropped the price in half, to see if it was the pricing that kept users away. I had a few more conversions, but the number was not significant. I left the price at half, and sales trickled, one here, one there.

The reality was that the app got lost in the app store dog-pile. When I spoke to people about it, they all were surprised that they never saw it, did not know about it, and that I was not making money out of it. The feature set was what they wanted. They just could not find it.

The Next App

The next app that I will release on the app store will cost me at least $250,000, before marketing. It will be professionally designed, the art will be by the best graphics artist I can find, and it built to showcase the latest iOS technologies, all that is needed to get noticed by Apple. Even that is not enough.

There’s more. I will get the most influential bloggers in iOS-land to be my beta testers. My experience has been that people buy apps based on recommendations from friends and key influencers, because searching the App Store does not work.

The best way to get an app noticed on the App store is to get the right people in the industry to become fans during the beta and then recommend it in their blogs when it gets released. People buy on these recommendations. Bloggers blog on other bloggers recommendations. Then the tweets come, and the Facebook messages. And this buzz drives people to hear about your product, and buy it.

If the buzz is big enough, you’ll make enough to cover your costs.

Taking down my old iPhone Apps

2012-02-13T10:16:00-05:00

Its time.

As of right now, my first two iPhone App Store apps, Emergency List and Sights to See are no longer available for sale, anywhere. I have taken them down.

These apps were developed two years ago, for old versions of the iPhone, and no longer represent the best we can do. We were learning iOS at the time, did not have access to the right designers and did the best we could back then. It got us the business we did the last 2 years. But they are not good enough to keep alive.

It’s sad to do this, these apps put me on the indie developer map, got me my first clients, and were a very pleasant learning experience. But it’s also wrong of me to keep selling product that I am no longer proud of, is no longer representational of my skills, that I am no longer maintaining and is no longer selling.

So off they go.

For more see End of Life - Sights to See and Emergency List at noverse.com.

Hiltmonism - Fix instead of Blame

2012-02-11T09:49:00-05:00

I was saving this one up for later, but events of this week prompted me to write it now.

Whenever something goes wrong, the first reaction of many people is to find someone else to blame. Arguments and vitriol erupt, things are said or smashed, as each team member tries to protect themselves from being blamed.

I, for one, do not ever again want to be on a team that does this. Nor should you.

Things go wrong, people make mistakes, software fails. It’s what unintentionally happens when us imperfect humans try to create perfection. It’s natural and normal. It should be expected, planned for and dealt with.

When something goes wrong, the first reaction of a team should be to identify and fix the problem. Find the error, correct it, write a test. Find the design flaw, solve for the best way to fix it, and implement the fix. And then, get back to creating the product you were working on. No blame, no vitriol, just professional calm.

Back in the late 1990’s, when I was a Project Manager, several of my engagements were to see if I, as an external person, could jump in and “fix” some broken projects. Its crazy to think back that a 20-something year-old whippersnapper Project Manager would be called in for this, but it shows how messed up these projects were. In all but two cases(¹), the projects had stalled because things had gone wrong and the team had become lost in a never-ending cycle of blame and coverage, so much so, that they spent all their time doing this and none of of in actually doing the work. The people were angry, hurt and scared they would lose their jobs. Clients were unhappy because they were not getting their projects completed.

The solution was to get rid of the blaming and get back to the doing. Sounds simple, but hard to implement of you are in the blame circle. As an independent, I could stay out of the fray, focus on the project instead of the anger, and re-motivate the people back to work. To do this, the first thing that had to happen was the removal of any histrionics, what someone said or did before I arrived was taken off the table. Anyone who went back to sayings and doings before I arrived was shot down, and in some cases, taken off the team as they destroyed morale. The second step was to encourage communication again between the team members, it makes it easier when they felt like they were starting from scratch. And the third step was to encourage the now communicating team to find issues, describe the found issues clearly in terms of the product and practice getting together to resolve them. Oh, and blame was banned.

The “what” is wrong is important, not the “who”.

Blame incorrectly assumes intent. If someone is blamed for a problem, it is assumed that they intended to create that problem. Why else would they be blamed? This kind of uninformed, ignorant and just plain stupid assumptive question is what causes blame cycles in the first place.

Blame also requires defense. If you do not defend yourself, you will get lumped with whatever you are being blamed for, whether right or wrong, and your career will suffer. If you do defend yourself, you’re not doing your job, and the project suffers.

Fixing, on the other hand, correctly assumes that the team is focussed on the project, and that they are smart enough to assume things will go wrong. A fixer team works together to get things done. Fixing requires communication to identify the problem, the team to focus only on the problem, and to figure out a solution. Successful teams are always fixers. Their members are free to work without fear or distractions.

I do believe that the issue with blame often boils down to the issue of intent. Did the person who messed up do so intentionally or unintentionally. It is in this space that the blame thing gets out of hand. Since intent is incorrectly assumed in blaming, the blame then gets spread out far and wide.

This week, it was announced that Path uploaded its user’s complete address books to their servers so their “find friends” function could work. The blame cycle went nuts. Path was accused of stealing people’s data without their knowledge, people closed their accounts in disgust and the press went wild. The Path CEO tried to calm the waters by explaining why they did this. He honestly though he was doing his user’s a favor, and he honestly admitted that Path did nothing untoward with the data. But the blame machine drove this issue quite out of context.

How far, far enough that by the end of the week, Path has apologized, deleted all the data and released a new version of their app that requests permission to do this. Far enough that by the end of the week, the blame machine had found a new target, Apple, for allowing Path to access the address book and allow Path to do this.

The fix, however, for this whole brouhaha is simple, and is used by a lot of developers who do the same thing as Path but are not blamed for doing anything wrong. The fix is to hash the address book data using a one-way hash and to then use these encoded hashes to find friends. With hashes, Path can still match friends, but have no knowledge of who they really are, protecting user privacy. If they get hacked, the data is useless, and they cannot ever share it, because the hashing algorithms are 1-way.

The whole Path issue could have been resolved by just hashing the user’s address book. But the blame cycle has probably destroyed their business, and has tarnished the reputation of Apple as well. It was a waste of everything, and wholly undeserved.

So back to fix, not blame Hiltmonism:

Fixing is productive, blame is a productivity killer. Fixing is fun, blaming is painful. Fixing gets the job done, blaming prevents it. Fixing is good for your career and karma, blaming is not. So why do we tolerate it? Next time the blame cycle starts, nip it in the bud with a “It does not matter who is to blame, we all need to get it fixed” statement and move on.

Or leave that team and find a better one.

The other two were caused by miscommunications between client and team, so the team actually built the wrong software. This all happened before agile development became common, and is why it is so popular and successful now. ↩

Speculative Developers

2012-02-07T09:19:00-05:00

I totally agree with the sentiment in David Sparks’s note Speculative Developers where he compares developers who ‘barf’ out volumes of bad apps versus developers who lovingly craft a single great app.

They are, however, completely wrong. Their chance of hitting it big with two (or twenty) crappy apps instead of one good one is about the same as their chance of retiring with their lotto winnings. Infinitesimally small.
If you want to develop apps, take your time and make something awesome. Make it fast. Make it beautiful. Make something you’re proud of. Don’t make 60 crappy apps: Make one really good one.

I wholeheartedly am not a speculative developer, I prefer to make and buy lovingly crafted applications.

Design needs an Advocate

2012-02-07T08:58:00-05:00

Felicity Evans, writing in the Smashing Magazine article When A Thousand Words Is Worth A Picture writes:

Design is itself a process of deduction. It involves a number of decisions, both conscious and unconscious. During this process, the designer dismisses some ideas as unworkable and pursues others in order to arrive at a solution.
But this process is completely opaque to the client. The client likely views the design not as the outcome of an in-depth process, but as a response to the brief, merely a visual representation of the constraints and considerations set before the designer. As the designer, part of your job is to educate the client and reveal the design process to them.

and

Good design stands up to criticism, because it is more than a matter of taste. View criticism as an opportunity to explain the reasons behind your decisions, to invite the client into the design world so that they feel like a part of the process.

You know what, just take the time to read it.

Structure First. Content Always.

2012-02-07T08:54:00-05:00

Mark Boulton makes good points in Structure First. Content Always.

Let’s stop siloing content, shall we? We did it for a while when we were designing a largely brochureware, templated web. Now, we’re trying to move that silo from one end of the process to the other. Let’s focus on structure to begin with, and think about content all the time. There is a symbiotic relationship between content and design. One cannot thrive without the other.
Let’s start with structure. Let’s know what our content is made from. Not, necessarily, what it is.

Agreed.

Your idea sucks, now go do it anyway

2012-02-03T10:26:00-05:00

Lovely article by Jason Cohen, worth a read, called Your idea sucks, now go do it anyway makes a great point on how the original idea for something usually evolves into something completely different, and success comes from embracing that evolution.

“My idea isn’t good enough yet” explained a friend who is thinking of starting his own company. He’s waiting for the idea to be completely fleshed out before taking the leap.
Newsflash: Your idea probably sucks, and it doesn’t matter because your business will probably turn out to be something completely different.

I often find myself talking to people about their their software ideas, and my usual response is “go for it”, even if I do not wish to participate. Some of the examples in the article prove that the original idea may have sucked, but by going for it, by adapting as they learned more about the idea and its use cases, by evolving the idea, they were successful. You’ll know their names.

Pursue your ideas. Know that they will evolve into something unexpected. Pursue the evolution. At worst, you’ll gain some experience and go nowhere. At best, you’ll be the next big thing.

Cheap iPhones, Wealthy Workers, Pick One?

2012-02-03T10:19:00-05:00

Randy Murray presents a different view in An Observer From Shenzhen—Thoughts on Apple’s Recent Bad Press.

Do workers in Foxconn factories who build products for Apple, Dell, HP, and others, work long hours at tedious tasks? Yes they do. Do they work for a fraction of what a worker in the US, Japan, or even Korea would? Yes they do.
Are they being enslaved? Clearly, they are not.
I suspect that a lot of the heat from the recent press comes from a lack of understanding about Chinese culture, their rapid change from manual agrarian life to high-tech manufacturing, and the significant differences and scales of our economies.

I don’t know what the truth is, but I am glad to see a reasonable dissenting discussion on this issue.

News Logic

2012-02-03T10:12:00-05:00

Paddy Harrington, writing in Wanna Figure Out If Your Product Is Any Good? Think Like A News Editor

At its heart, news logic is about value creation and the primacy of the design output instead of a story that traditionally gets applied after the fact. Where in the old days (i.e., five years ago), you designed something and then told a story about it in the hopes that it was a story worth telling, more and more of tomorrow’s design projects will have a story worth telling built into their hearts right from the get-go.

I try to apply this thinking here, only posting links to articles I think are great, or creating articles I think are newsworthy. If there are any topics you’d like me to expound upon, comment here or tweet me.

The paradox of choice

2012-02-01T10:41:00-05:00

People desire more choices, yet are unable to choose when the selection is greater, that is the paradox of choice.

Sheena Iyengar, a professor of business at Columbia University, conducted an interesting study in 1995. She set up a display of 24 samples of jam for customers to taste, and every few hours, she switched to a 6 sample set. The results were astonishing: 60% of customers stopped to try the jams when the selection was large versus 40% when small; and 30% of those that stopped when the selection was small purchased a jam, versus 3% when the selection was large.

In short, more people were attracted to the greater selection, but 10 times more people actually made a choice when the selection was smaller.

That study “raised the hypothesis that the presence of choice might be appealing as a theory,” Professor Iyengar said last year, “but in reality, people might find more and more choice to actually be debilitating.”
New York Times www.nytimes.com/2010/02/27/…

In a similar study, Surgeon Atul Gawande found that 65% of people surveyed said if they were to get cancer, they’d want to choose their own treatment. Among people surveyed who really do have cancer, only 12% of patients want to choose their own treatment.

Too many choices in software

In software, we have the same disconnect between number of choices and user’s ability to make those choices. Our users declare that they want extensive choices, but they rarely, if ever, make or change those choices. For example:

The Mac has hundreds of choices in the System Preferences application, yet very few users ever venture in there and change them.
Apple recently released a simplified version of its Wireless Router software that removed the advanced menu of choices from the application, and almost no-one noticed.
Lots of software comes with customizable report writers. Very few customers ever use them, yet all RFP’s require it. As an advanced tech geek user, I have only once in the last 12 years used one of these (and that was in Billings to customize the layout of my invoices).

Letting the user decide

One of the key burdens of a Software Designer is to make decisions on behalf of users. What features and functionality to implement, how to structure it, what the flows should be. When software designers get stuck, a common pattern is to let the user decide, create choices for the user to make and implement the necessary features for each choice.

Each and every setting or option in your application preferences is a decision by the designer to let the user decide. SAP software used to have 22,000 of these. And users love this, they call your software customizable and seem more comfortable to buy it.

But there are some problems with this. First, you have to design and implement the functionality for each choice, which means more programmer time, testing time, integration time, debugging time and of course, cost.

Secondly, if the designer cannot decide what is the right or best way is, how is the user supposed to make that decision? Your expert user, the 3% of your user base, who understands the problem domain, and knows what they want, will make a choice and be done with it. But your regular user will be just as stuck as the designer as to what choice to make, which of the 24 jams to choose. We designers solve for this by choosing a random default setting. Our users solve for this by assuming we did that on purpose (see Almost No-one Changes Their Settings), so they leave it alone.

Letting the user decide is the software equivalent of creating all 24 jam flavors, putting them on the shelf and assuming that users will be capable of choosing the right one. Evidentially, only 3% of them can. Its a cop-out.

More Choices, Simple Software, Pick One

Users also want simple, intuitive software. If there is no choice on how do to something in your software, then that’s all users can do. Try printing from your current application, or opening a file. You always get the same operating system dialog (unless you use Adobe products, of course). Users do not get to choose which print dialog to use, or which file browser, they always get the same (Adobe users excepted). Imagine if each time you wanted to save a file, you first has to say which file browser to use before you saved. It would make the software cumbersome to use and complex to implement since the developer has to support all different file browsers available. By using the Operating System supplied print and save dialogs, developers have removed choices and made the software simpler.

Lets take another example. I’m writing this post in Byword, but I could just as easily be writing it in Microsoft Word. What’s the difference? Well, Byword has no toolbar, limited formatting and makes it easy to write. Microsoft Word has a ton of menus, ribbons, colored squiggly lines, page breaks, formatting options, change detection, stylesheets and the like, oh, and you can also use it to write. I launch Byword, and write, that’s it (Byword has already chosen the font, view and styles for me). But because of all the choices in Microsoft Word, my usual process is to launch Word, choose a template, change the font and screen views to hide page breaks, check my stylesheet, and write, and format and write some more and format some more. Byword is simple, Microsoft Word is complex, both enable me to write, but Microsoft Word forces me to make more choices as I go along. Hence, I prefer Byword for writing.

It goes even further when I realize I use 80% of Byword’s functionality, yet less than 15% of Microsoft Word’s.

Note that I am not saying software should have no choices, that may be too few, and may make the software too simple to even do its primary function. For example, I also have a copy of iAWriter, which is a writing application that has even fewer choices than Byword. Why not use that? Because iAWriter made too many choices for me making it harder for me to use (but not for a lot of other people).

Is it not information overload in the 24 jam case?

I don’t think so. In some cases, too many choices just overloads the chooser, if and only if the choices come with too much supporting information.

For example, as a new arrival in the USA I went to the local supermarket to purchase milk. Where I come from, milk comes in two varieties, whole and skim (the soy stuff is not called milk). In my local supermarket, I can choose from whole, skim, 1%, 2%, organic vs non organic, local vs interstate, fresh vs reconstituted, soy vs cow, pasteurized vs non, and from several brands. It’s a multidimensional matrix of choices with many axes, and all I want is milk.

On the other hand, too many choices may come with insufficient information, the overload being the sheer number of choices. I recently had to choose a new healthcare plan, and all the plans I looked at had hundreds of options, yet most of those options offered were not explained. I had to call up the company and ask a whole bunch of questions just to understand a few of the options available. I picked a plan because the few options I did get explained to me sounded right, but I have no idea if its the right plan for me, or what I really purchased.

So what about how the choices are presented?

If fewer choices are better, so the jam study proves, how come people still struggle to choose from a smaller selection? It boils down to how the information about each choice is presented, just like in the overload case.

If you want an iPhone in the USA, you have three choices, AT&T, Verizon, and Sprint. Seems a simple choice, pick a carrier, get the iPhone. Yet it is almost impossible to choose a carrier, because the carriers present their services in complex, incompatible and vague terms, make no promises, hide their restrictions and limitations and therefore leave the chooser in the dark as to what they are really getting. The chooser has insufficient information to make a choice, no way to get that information and has, therefore, no way to make the right or best choice for them. Cable companies, airlines, electronics vendors and the like do the same. It gives the seller the power to persuade choosers versus giving them actual choices.

A whole industry has arisen to try to make these choices easier. Kayak, Hipmunk and Expedia, for example, all exist to help people choose flights from the morass of airline data and deals, but even they cannot simplify it enough.

Making choices easier

As a software designer, our first goal is to make the best choices for our users. If there is more than one way to present information, calculate a number or execute a process, we should choose one and implement only that one. Almost all of our users will be happy with our choices, and we’ll only hear from the few who wish we made the other choice.

We also sometimes do need to offer the user a plethora of choices. It’s how we present those choices and the supporting information we provide that will help users choose. For example, reports. Most systems have a reports section. Most systems have a lot of reports. And most systems rely on the report name to tell the user what the report does. But most report names on incomprehensible to users. What is the difference between an aging and a collections report, they both show overdue balances? If the designer added a 1-2 sentence blurb about what the report contains, and when to use it, users will be able to choose the right report quickly and easily. Otherwise, they will have to run heaps to find the one they want, or give up.

The paradox of choice

The paradox of choice means our users want more choices, yet cannot choose between these choices. We need to find the balance between choices for users to make and the choices we make for them. If we get that balance right, we create happy users and brilliant software experiences.

References:

Childlike Wonder

2012-02-01T10:31:00-05:00

Ever watch a child with an iPad? They seem to get it immediately, they prod and tap and swipe and rotate and in no time at all seem comfortable with it.

Ever watch an adult with an iPad? They hold it, and stare at it, and, well, stare some more, and maybe wave a finger near it, but hesitate to touch. And after all that staring and hesitating, they remain uncomfortable with it.

What is going on?

What is happening is that the adult is attempting to map the item to their own pre-existing mind models. If the item fits, for example, the new toaster works kind-of like the old toaster, they are immediately comfortable with it (albeit they will not use any of the new toaster features). If the item does not fit a known mind model, most adults get stuck in a loop. Its kinda like a computer, but kinda like a phone, but kinda like a book, but kinda like a computer, which model to use … and the brain enters an infinite loop. After being shown a few things, the adult takes this training, merges it with an existing mind model, and uses only the features they were shown. They ever even look at the new toaster features, they never even look at all the other iPad features.

Children, on the other hand, start with no preconceived mind models. Each thing they encounter is a new thing which requires a new mind model. The new toaster has knobs that need to be figured out, oh, this one makes the pop higher, this one makes the toast darker, this one burns in a Hello Kitty face. The child is building a mind model for this device. The iPad contains a plethora of things to build a mind model on, and children gleefully spend hours prodding each button, swiping each screen, and quickly building a new mind model for the device.

At some stage in our lives, we stop having this sense of childlike wonder and start trying to map the world to the mind models we already have. Some call it maturity, I call it sad.

So how does this apply to computer software design and my areas of expertise?

Our users are not children. One cannot deliver unto them a product and expect them to use their childlike wonder to explore the application and build the right mind model for it, no matter how intuitive we think it is. One cannot even give them a manual to explain the product, because they will not understand the text, the terminology or have time to read it.

Instead, software designers have two choices here. The first is to make the product fit a common mind model, the second is to provide demos and training.

In the first case, your application needs to look like, work like, and use the same terms as the user’s mind model. Which means knowing what that that is, and conforming to it. It applies design and functionality constraints on the product, and it makes it harder to innovate. Ever wondered why all graphics manipulation apps look like MacPaint (yes even Photoshop!), because they target the same mind model. Or all spreadsheets still look and work like VisiCalc, same reason. Email clients and Eudora. You get the picture.

In the second case, where you create something new that requires a new mind model, you know that your users are going to stare at the product, not use it and complain that the old way was better. Get off my lawn and all that. You need to train them. The very best training is hands on, give them tasks to complete, walk them through it the first few times, and wait for the time when they proudly announce that they know what to do. It is at this stage that you know they have built a mind model, albeit a very weird one. Create tools to then help them learn new features. Screencasts are great for this, and easy to create. And before you know it, you’re back on the lawn, the new way is the better way. It just takes a lot of time and patience.

To help figure out the nest way to train adults, next time you are ready to release a feature or a product, put it in front of a few children and watch where they go first. Ask them what they see, why they prodded that first and what have learned by playing with it. Then do the same with adults, but this time, lead them where the children went. It may not bring back a sense of childlike wonder to the adult, but it will help them learn, build a mind model and get comfortable with the product sooner.

But it is in yourself that you can make the change. Next time you are faced with an unfamiliar thing, don’t try to map it an existing model. Instead, try to find your sense of childlike wonder, play with the thing, poke it, prod it, rotate it, open it, don;t be intimidated or afraid of it, try to figure it out and see what happens. You will have fun, and you will build a whole new mind model.

Fragility of Free

2012-01-29T11:49:00-05:00

A great article by Ben Brooks called Fragility of Free, well worth a read:

The fragility of free is a catchy term that describes what happens when the free money runs out. Or — perhaps more accurately — when the investors/founders/venture capitalists run out of cash, or patience, or both. Because at some point Twitter and all other companies have to make the move from ‘charity’ to ‘business’ — or, put another way, they have to make the move from spending tons of money to making slightly more money than they spend.

I also like to, and do prefer to, pay for things.

Test Driven Development Really Works

2012-01-26T11:09:00-05:00

In 2008, Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, and Laurie Williams wrote a paper called “Realizing quality improvement through test driven development: results and experiences of four industrial teams“ (PDF link). The abstract:

Test-driven development (TDD) is a software development practice that has been used sporadically for decades. With this practice, a software engineer cycles minute-by-minute between writing failing unit tests and writing implementation code to pass those tests. Test-driven development has recently re-emerged as a critical enabling practice of agile software development methodologies. However, little empirical evidence supports or refutes the utility of this practice in an industrial context. Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

In 2012, Ruby on Rails development practices assume TDD. I personally rely on tools like rspec for writing tests and mocks, factory_girl for creating objects, capybara for browser automation, simplecov for code coverage and guard for automating these tests.

As a result of using this methodology and these tools, I tend to agree subjectively with Nagappan et al:

It does take more time to write tests. But a 15-35% increase in time seems excessive. Most tests are short, quick and simple to write. Using mocks and factories helps a lot.
It takes no time to run them if you use a tool like guard that continuously monitors and runs them as they change. Add growl notifications on the Mac and you only need to pay attention when you see red.
Tests help me write better code. Because thinking up and executing tests often shows up code defects early, and this is a very good thing. I often find myself writing a function that I think is great, then throw a few additional tests at it and find my logic or execution was flawed.
My defect rates are much lower, just like Nagappan et al state. I think this is simply due to the use of TDD to identify and catch defects earlier in the process. And I get far fewer bug reports from Beta testers.
I am no longer afraid to refactor mercilessly. The tests will tell me if the refactor breaks anything. This is probably the most important point. I know that its safe to change code, I know if the change affects other components and I can see where and how it does so, so I can fix it.
I can trust the code base. No need to tiptoe around API’s or functions. I can trust that calling an API or module will work, and that the tests will tell me if they break. I can trust the work of others because their tests work too.
I seem to have found, empirically, that writing tests after the fact is just as fine as writing them before. The important thing is to have the tests, and to have good tests, to have tests that go after both expected and unexpected cases, outlier cases, failure modes and are in some cases ridiculous tests.
It also helps when taking on legacy or other people’s code to spend time writing tests to help you learn that code. Or at least trust that code by testing the components you use.
Testing for 100% coverage does not seem to be all that worth it. Using my toolkit in Rails, I can test the workflow, UI and all models and business logic. In reality, getting 100% coverage on models and libraries pays off, but the UI and workflow stuff changes so much during development that the tests for that stuff get in the way.
Adding tests for bugs found is another great way to document not only the bug but your bug checking and fixing process. You know something is wrong when a bug is found, tests can help you to corral it, and then be sure that it never happens again. Tests also ensure that your fix does not break anything else. I often find new bugs by fixing one bug and watching other tests fail.
I don’t release unless all tests are passing, obviously.
I also don’t skip testing to meet deadlines. I estimate with tests in mind, I develop with tests in mind. And if I have a deadline, the few minutes more it takes to create and run tests make no significant difference.
I make no secret that I use this methodology. My clients understand that the small increase in development time pays off handsomely in later iterations, and reduces beta testing and maintenance issues. Based on my experience alone, TDD actually reduces the net time to develop and ship quality software because you don’t spend time later in the project trying to figure out what went wrong.

For many developers, introducing Test Driven Development, is a challenge. You have to explain it to your team, to managers and clients, then find the time to write tests, then find the time to learn how to write good tests, build a process and infrastructure to automate testing, and the payoff is difficult to see until far later in the project timeline. I hope just some of the benefits I have found above help you get there. With TDD, you will make better software, you will be a happier developer and your manager and client will see the benefit in the end.

Where the light is better

2012-01-26T10:30:00-05:00

A woman comes across a man crawling under a street lamp. “I’ve lost my car keys,” he explains.
The woman tries to help the man find his keys. After a few minutes of searching, she asks “Where exactly did you drop them?”
“Down the street, next to my car.”
Puzzled, she asks “Then why aren’t you looking over there?”
“The light is better here.”

People often look where it seems easiest or most convenient to look, rather than in a more difficult, but more correct place. Opinions regarding where the best place to look often comes down to “Where The Light Is Better”.

Support teams base their knowledge of a software system upon specifications and documentation, rather than observing the actual system in action or examining its source code. Documentation is usually incomplete and out of date.
Analysts make decisions based upon easy-to-collect metrics, rather than on detailed study of the complexities of a situation. Not enough time to do it right, so find a short cut.
DBAs prefer that database query logic be written as stored procedures in the database, where they can get at it; whilst developers prefer that it be in the application code, where they can get at it. More convenient location, not necessarily the right location.
When a bug is found in someone else’s code, developers will generate complex workarounds in their code, rather than trying to get the bug fixed. Either it takes to long to get it fixed, its too hard to fix it yourself or something else may depend on it. Workwround instead of finding out.
Almost everyone uses a tool they know well to try to solve a problem, even if that tool is poorly suited to that problem, rather than to try and learn an unfamiliar tool that is far better suited for that job. Use your “hammer” tool instead of the right tool. We’ve all see abuses of Excel and Powerpoint, no?
Architects try to gather existing knowledge informally, through conversations, online forums, and wikis, rather than reading papers and books. More convenient to ask than to learn, see the success of StackExchange.
Consultants try to gather information on industry practices through reading academic papers, rather than examining real-world work and case-studies. Hoping someone else saw and solved the problem first.

Having alternate places to find and gain knowledge is a good thing. But you need to make sure that the alternate location is referring to the same knowledge. And that you truly understand the problem and solution space. Searching where the light is better does not necessarily mean you are searching where the keys are, where the solution exists.

Expedient is not necessarily efficient.

Rephrased without requesting permission and hoping for forgiveness, from http://c2.com/cgi/wiki?WhereTheLightIsBetter (Last updated November 2004).

Less Wasting Time

2012-01-26T10:18:00-05:00

The sub-theme this week is on trying to find ways to improve developer happiness and to reduce unpleasant time wasters.

Rafe Colburn in Don’t order your team to work more hours talks about bosses who ask staff to work more hours:

Every time you’re tempted to do so, sit down with members of the team and ask them how many hours a week they spend dealing with stuff not related to shipping and work to make those things go away instead.

David Heinemeier Hansson gets specific in Refusing administrative minutiae, picking on expense reports.

Optimizing your business for happiness is about a lot of things, but taking out all the needless administrative minutiae seems like one of the easiest. Why aren’t you?

Pass these on to your boss.