Wednesday, October 31, 2012

Why Google should get behind Markdown

In the war against complexity, Markdown has emerged as the winner in the
simple-text-formatting battle. There are others - notably Textile (supported
by Basecamp prior to its refresh) and reStructuredText (heavily supported by the
Python community) - but Markdown is the clear leader in its field.

In recent days there's been a bit of a hoo-hah about the lack of a formal spec.
for it (@gruber, the BDFL of Markdown doesn't seem that bothered), and the pro-
liferation of different variants / flavours. For instance, StackOverflow and
GitHub both have subtle extensions that favour their own specific use case.

I don't want to get involved in that debate, but now that it has appeared in
the 'public' domain, I thought I'd add one idea that occurred to me this
morning (whilst writing and sharing some notes).

I use iA's writer for taking notes in meetings, which supports .md, and I use
Sublime as my general purpose writing / coding tool, which also has a great
'preview in browser' function for .md files. What I'm missing however is a good
online tool for a.) making notes online, and b.) sharing those notes as HTML
pages (as per the preview in browser function) with other people.

At the same time, I use Google Docs for sharing docs online; one of the
ongoing complaints about gdocs is that it's such a poor relation to Office. So
here's what I suggest (to Google) - instead of chasing Office and adding
features, how about removing features, and simply becoming the de facto Markdown
editor / browser / publishing platform of choice. Put your weight behind the
specification effort (i.e. write a bunch of formal compliance tests for .md),
then allow people to write in .md in gdocs, and to publish them as HTML for

They already have partial support for *bold* and _italic_ markup on Google+
posts, so they clearly have thought about this.

(And yes, I know that people who understand Markdown are a tiny niche audience,
but then I'm not expecting anyone from Google to actually read this, so I don't
need to be practical.)

Monday, October 22, 2012

[draft] Estimation is guesswork.

Estimation (in software development circles) is neither an art nor a science - it's guesswork. And yet we continue to perpetuate the myth that it's possible to predict how long something will take to build.

I have a post in me about the 'immutablility of developers' and their inability to change the rate at which they work, a fact of life that very few project managers seems to have grasped.

This is just a placeholder (note to self to write it!)