Until I came across this video I hadn't realised that: a) TweetDeck was a UK creation b) It was the work of one man: Iain Dodsworth
TweetDeck is a phenomenal piece of work to be created by one man. Hats off to the guy!
But why does someone go to the trouble (and it must have taken a serious amount of work) to create application as superbly usable as TweetDeck? To make some money out of it? How do you make money out of something that's given away free? Iain Dodsworth explains his plan:
So we all know about Steve Jobs. But, what the heck, let's trot through the well-worn path of his public life.
The early years where he hooked up with a brilliant young engineer called Steve Wozniak and got him to design circuit boards that people still consider works of engineering artistry. The huge success of the Apple II in the late '70s when the microcomputer industry was in its infancy. His immediate grasp, on visiting Xerox PARC, of the business potential of the mouse and graphical user interface. The Apple Lisa and then the phenomenon that was the Macintosh. His sacking from Apple in 1985 and the launch of NeXT (identifying UNIX as the operating system that would allow him to continue pursuing the ideas he'd been trying to develop at Apple). The $10M purchase of a division of Lucasfilm the following year (which went on to become Pixar). The transformation of that $10M into a $585M share value when Pixar went public in 1995. The stagnation of Apple without Jobs. His return to Apple in 1996 (shortly afterwards taking on the mantle of "interim" CEO - as if anyone was fooled that he wouldn't stick around). The uber-stylish iMac in 1998 (the first of the iBrands and the fast-selling Macintosh ever). The license to print money that was the iPod/iTunes application/iTunes Music Store triumvirate. The successful replacement of the old Mac OS with Mac OS X, an operating system based on the work done at NeXT. And then in 2007 the launch of a mobile phone - but not just any mobile phone - of course it's not - this is Apple, so it just has to be, indisputably, the best mobile phone ever.
So that's all well and good. But out of all his background of success and his personal qualities - his obsession for beautiful hardware design, his extreme attention to detail, his ferocious determination to protect Apple's intellectual property, his own personal self-branding, his Wonka-esque control over what information comes out of Apple - out of all this, what is it that makes people follow Jobs, and hang on his every word, like no other business leader.
For an answer, look no further than this footage from Apple's sales conference in Hawaii in October 1983:
It's his passion, his complete commitment and his palpable belief in the importance of what he's saying that make this so totally captivating. If Jobs had been an army recruiting sergeant, looking for recruits to fight the evil Big Blue, I'd have enlisted on the spot.
I've often heard technical writers say: "I'd have liked to have had a few more weeks on it. There's some information I didn't manage to get in there and there are parts that I would have like to have restructured ... and some of the input forms got changed at the last moment and I really should have redone the screenshots, and those diagrams were just intended to be Visio roughs, I meant to do a final version in Illustrator ... and really it could probably do with one last round of reviews ..."
OK, to be honest, that's me. That's usually what I'm saying - or at least thinking - when it's time to ship the product to customers. And I've always told myself the reason I'm like that is because I'm a perfectionist and the reason I find it difficult to wrap something up - and say "It's good enough. Customers will get more value from getting this documentation now than from waiting a couple of weeks and getting it late" - is because I have such high standards. Turns out I'm probably kidding myself.
The lizard brain
In this video Seth Godin (author of Linchpin: Are You Indispensable?) explains why the resistance to shipping (and by shipping I mean getting stuff finished and despatched/published/released) is just another symptom of our lizard brain at work.
Another concept Seth Godin raises in his presentation is one of Steve McConnell's: thrash early. "Thrash at the beginning because thrashing at the beginning is cheap." In this context, "thrashing" means working without making any progress. The expression was coined, I believe, by Frederick Brooks, in The Mythical Man-Month where he described great beasts, long since extinct, that had strayed into a tar pit, thrashing about with all their might but not making any progress to escape their predicament.
In the following diagram McConnell illustrates the situation where a lack of process and planning at the start of a project results in an increase in thrashing, and a decrease in coding progress, the longer you spend on a project.
When a project has paid too little early attention to the processes it will use, by the end of a project developers feel they are spending all of their time in meetings and correcting defects and little or no time extending the software. They know the project is thrashing. When developers see they are not meeting their deadlines, their survival impulses kick in and they retreat to "solo development mode"—focusing exclusively on their personal deadlines. They withdraw from interactions with managers, customers, testers, technical writers, and the rest of the development team. Project coordination unravels.
As a manager who never set out to be a manager (but who, nevertheless, is trying to be a good manager) Scott Hanselman's recent follow-up interview with Chris Sells about management struck a chord with me and I wanted to share it.
Among the things Scott and Chris discuss are:
Being an advocate for the people you manage
Getting things done means ignoring emails ("At Microsoft you either write code or you delete email")
"No meeting Wednesday"
Weekly or daily task setting and progress reporting
Prime motivators for getting things done: shame and fear
Chris talks about Scott reduced posting to Computer Zen since becoming a manager. I think what he's saying is: you can be a good manager, a good website contributor, a good husband, a good father - but you only get to choose one of the above.
I'd like to think that's not true.
Please note: This video is from Microsoft's Channel 9 website and (I'm guessing) is the copyright property of Microsoft, or maybe of Scott Hanselman. Go to the original page on Channel 9 to see the video in its Channel 9 context, complete with comments.
I've got a MadCap Flare project that I want to publish as open source code for anyone to go and download. It turns out this is extremely easy to do using Google Code. And Google Code has the benefit of allowing you to sync your work with the online source files using SVN (Subversion).
Multiple people can work on the project simultaneously and each time you open the Flare project the SVN plugin for Flare asks you if you want to use the most up-to-date files from the online repository. When you've finished making changes you just commit your changes, straight into Google Code, without having to leave Flare.
Here's how to create a project in Google Code and add a Flare project.
Prerequisites:
For the initial upload of files into a Google Code project I'm using TortoiseSVN. You can download this from http://tortoisesvn.net/downloads. TortoiseSVN allows you to work with a Subversion repository from the right-click menu of Windows Explorer.
You will sign into Google Code using a Google account, so you need one of these if you haven't got one already. If you use Gmail you've already got a Google account, so use that.
You are going to commit files into a publicly viewable repository. Even if you delete a file from the repository, people will still be able to browse previous revisions of the project and view the file. Versioning repository systems like Subversion are designed to keep a historical record of everything that happened to the repository, so there's no easy way to remove all trace of a file that you didn't mean to upload.* So, before adding a project, make sure that you remove any files that you don't want other people to see.
You will now have a Google Code project with one project member: you (or, to be more precise, your Google account).
You are the project owner. To allow other people to commit changes to the project, you can add more project members from the Administer tab.
Click the Profile link (top right of the page).
Go to the Settings tab and copy your googlecode.com password.
Now go to Windows Explorer and browse to the directory that contains the Flare project you want to add.
Within the project directory select and cut the Analyzer and Output directories.
Paste the Analyzer and Output directories somewhere outside of the project directories.
This is to avoid these directories being added to the repository.
Do the same to the Project/Reports and Project/Users directories, moving them out of the project for now.
Right-click your Flare project directory and choose TortoiseSVN > Import.
In the Import dialog box, enter the following as the URL of the repository:
https://<PROJECT-NAME>.googlecode.com/svn/trunk
When prompted, enter your user name and password.
These are the user name of your Google Code account (e.g. the bit before the @ symbol in your Gmail address) and the googlecode.com password you copied to the clipboard.
Click OK.
This will now add all of the files/directories to the SVN trunk in Google Code.
TortoiseSVN displays the progress. If you have a lot of files in the project this may take some time.
When the import finishes, click OK to close the dialog box.
Move the Analyzer, Output, Project/Reports and Project/Users directories back within the Flare project directory again.
Still in Windows Explorer, in the directory that contains your Flare project directory, right-click anywhere on the background to the main pane of Windows Explorer and choose SVN Checkout.
In the Checkout dialog box, enter the URL of the repository:
https://<PROJECT-NAME>.googlecode.com/svn/trunk
and the Windows path to the Flare project directory (that is, the directory you just imported into Google Code) as the checkout directory.
Click OK.
The files you imported are checked out and marked as under version control.
A little check mark on the file icon indicates that TortoiseSVN knows they are part of a Subversion repository.
In your browser, go to the Source tab of your Google Code project.
Click trunk and you should see all of the files you uploaded.
You can now start Flare and open your project and (if you have the SVN plugin) you will be asked if you want to load the latest version of the files from the SVN repository.
* Note: If you forget about clearing out sensitive files and you discover you've uploaded something you really don't want anyone to see, then you can remove all the revisions within the project - in other words you can empty the project and return it back to its initial state before you imported any files. You do this by resetting the repository.
To do this, go to the Source tab in your Google Code project and click the reset this repository link near the bottom of the page. Be aware that this removes everything from the repository, so you should never do this for a project that has an active community working on it, or a project with any sort of a history because this history will be destroyed by resetting the repository. But if you've just started and then realised there's stuff in there that shouldn't be, then it's a way out of a fix.
So we all know about Steve Jobs. But, what the heck, let's trot through the well-worn path of his public life.
) explains why the resistance to shipping (and by shipping I mean getting stuff finished and despatched/published/released) is just another symptom of our lizard brain at work.
where he described great beasts, long since extinct, that had strayed into a tar pit, thrashing about with all their might but not making any progress to escape their predicament.
. 
