Using Git as a Backup Tool

It had been a hellish week, and at this moment sleep was not an option for Phil. maybe it was the kimchee, maybe it was the realization that his blog almost shrugged off its digital coil as a result of The Great Blogtastrophe. Phil was tossing anxiously in his bed – visions of hard drives melted in his head and then…

Oh CRAP – his spine straightened in horror: “OMFG I don’t know if ROB HAS BACKED HIS BLOG UP!”. There was no time to waste – this has to be fixed. Phil raced to his machine, fear mounting as he visualized a world without Rob’s blog… horrifying… [diety] help us…

The Harsh Reality

The laptop hummed to life, bathing the room in deep red light from his Masters of the Universe desktop wallpaper. He quickly typed in his shortcut for Remote Desktop Connection, entering the address for Rob’s server in the Server Address box. And then froze. He didn’t know the login and password…

Relying on intuition and a deep dark secret he knows about Rob, Phil guessed at the login/password and nailed it the first shot. It couldn’t be that easy… is Rob such an amazing haack that he used THAT for his login? Oh no… this could be really, really ugly.

Phil was greeted with a sea of desktop icons – dlls and text files co-mingling in digital sin. Shortcuts to nowhere. He was tempted to kick up a game of minesweeper – but a glance at the clock made him realize time was running out. He pulled up SQL Server’s Management studio to analyze Rob’s backup plan and quickly saw he had none. The horror… the horror… the… horror….

“I can’t let this happen to the most awesome person I know… even if he is a complete hack” Phil thought, and his fingers went into action – creating the missing backup plan. He dropped open the Management directory and right-clicked on Maintenance Plans – selecting “New Maintenance Plan” (“Wizards are for CHUMPS” he thinks to himself). He quickly creates a backup plan and schedules it to go off 3 times a week:



He decides to be as tidy as possible – Rob needs some kind of role model here and while he’s tempted to throw the .BAK file onto the Desktop (oh delicious irony) he can’t bring himself to be that cruel. Well, he can but in this case he has a plan…

The Missing Backup Plan

Phil scanned Rob’s server in a panic, praying that his ISP had performed some type of Backup Intervention – instead all he saw were traces of tough love and Rob insisting on living life the hard way. Phil knew the hard way – knew it all too well. His blog was almost lost to his folly – he couldn’t let this happen to his most favorite person – he needed to make sure that all of his data as well as uploads was safe for all posterity!

DropBox, LiveMesh, X-Drive, SkyDrive, Mozy – the digital world is awash with people pushing backup space. Why in Fowler’s Name did Rob choose to live in this Geek Ghetto? There was no service available – nothing had ever been archived. Phil was stuck.

And then he remembered… “Didn’t Rob do some kind of post that I never read about deploying sites with Git and FTP? Hmmm, I wonder if he’s got Msysgit installed on this box. Would be weird if he did but… I wouldn’t rule it out…” Phil right clicked on a directory and was shocked and relieved to see the most wonderful prompt he’s ever seen in his life:

Git Bash Here

Setting Up The Remote

The pieces of the puzzle were starting to fall into place – he’d push Rob’s blog to a remote service! And then he’d set up a shell script using Scheduled Tasks to repeat the operation! Oh SHAZAAAM!

In a rush of inspiration Phil logged into his Unfuddle account, loading up a new Git repository just for Rob. “Happy Holidays you troll…” Phil thought. He could also have used Github since he paid for the service upgrade to have a private repository.

He added the entire directory, including the new database BAK file, to git:

git init

git add .

git commit -am "Saving Robz Assssss"

Once the initial setup was completed, he added in a remote:

git remote add backup git://

The final part was adding the script to a CMD file, with the recursive trick of adding this shell script to the archive itself:

git add . & git commit -am "Periodic backup %DATE%" & git push backup master

The only part left was to run the script to make sure it worked:


“Damn I’m good. No … no… I’m a frickin super star” Phil thought to himself. He thought these things a lot but in this case, in this one strange turn of fate, he was correct. It felt good to be correct and Phil sat back in his Aeron, savoring the moment.

The Scheduled Task

Phil opened the Task Scheduler wizard and created a basic task. He set the schedule to go off 3 times a week, and in the “Start a Program” dialog entered the path to the script he just created:


Surveying the summary, Phil felt the rush once again. He was the shine of the sun, a beacon of correctness and excellence in the dark of Rob’s world:








One Upping Rob

It was good to be right, and Phil couldn’t get enough of it. He decided that he needed to one-up Rob on his own turf, using Git and FTP to back up Rob’s blog to his own hard drive.

“I’ll show him that I’m awesome too.. ” Phil thought, “… and I’ll use his precious SubSonic to do it… yes… yes…”.

Phil headed over to SubSonic’s source at Github and grabbed the latest drop of SubSonic 2.2 – knowing that there was a handy tool called “SubCommander” that would not only script out the schema of a database, but the data as well.

He dropped the binary files to his C drive, into his SubSonic folder, and once again kicked up his text editor to create a shell script for Rob’s SQL Server Database:

C:\SubSonic\sonic.exe scriptschema /override  /out Z:\RobsBlog\ /server /userid cody /password ------- /db shwerko 

As he ran the script he wondered why Rob named his database “shwerko”, and also if he would ever be dumb enough to publish the real credentials on his blog in some ridiculous blog post. “No”, he thought, “not even Rob is capable of such silliness…”.

When he was done, he saw a SQL script file placed in the Z:\RobsBlog directory:


He added another command to the script to pull the data as well:

C:\SubSonic\sonic.exe scriptdata /override  /out Z:\RobsBlog\ /server /userid cody /password ------- /db shwerko

And this dropped another .sql file right under the first, full of INSERT statements. Perfect!

Now for the fun part…

Hooking Up FTP and Git to Pull Rob’s Blog To an External Flash Drive

Just in case Unfuddle explodes, Phil decides to be prudent and backup Rob’s blog to his 250g external flash USB drive that he got for last Christmas from Jeff Atwood after they got into an argument about who could do the worst job backing up their blogs. Phil recalls that perhaps Jeff won this argument:

One thing’s for sure: until you have a backup strategy of some kind, you’re screwed, you just don’t know it yet. If backing up your data sounds like a hassle, that’s because it is. Shut up. I know things. You will listen to me. Do it anyway.

Redundancy. That’s what Rob needs. Redundancy. That’s what Rob needs and I’m sure of it. Phil decides to map a drive to Rob’s FTP server so he can do some Git magic over FTP. Phil’s running 64-bit windows and knows that the only thing he can do is to purchase WebDrive since it’s the only reliable way (as of this crazy, stressful evening) to wire a hard drive to an FTP site. He used to run NetDrive happily on his 32-bit installation of Windows ME and it worked great.

He kicks up WebDrive and maps his W: drive to Rob’s site root, happy to see the “.git” folder in there. He knows that if it wasn’t in there he could easily put it there by using the following commands (since Git doesn’t see the FTP part – only another drive on the machine – WebDrive handles the plumbing):

git init

git add .

git commit -am "Loading up Robs sorry blog"

Phil creates a directory on his backup drive and calls it “BlogArchive” and then issues the simple clone command for Git – pulling down Rob’s blog – noting that WebDrive is acting as middleman here:




To complete his masterpiece of extraordinariness, Phil puts this all in a script which he can execute as needed, pulling down the data as well as all the assets at once, storing them on his flash drive:

git pull origin master && 

C:\SubSonic\sonic.exe scriptschema /override /out K:\BlogArchive\Hana\ /server /userid cody /password ------- /db shwerko && 

C:\SubSonic\sonic.exe scriptdata /override  /out K:\BlogArchive\Hana\ /server /userid cody /password ------- /db shwerko

In reviewing his work, Phil thought it was good. He felt a restfulness come over him as he realized he had just saved Rob’s blog from possible oblivion. Not only that, he could now look at Rob’s source code for Hana and maybe plug some of it in to Subtext…

The room stayed lit that night, bathed in the red glow of Phil’s desktop wallpaper… and his feeling of accomplishment.

“I wonder if Galloway has a backup plan…” thought Phil, and kicked up Remote Desktop Connection once again…

Posted in Uncategorized | 2 Comments

My Enemy, My Self

I’m building an application which I’ll talk more about later – but this one’s different from other applications I’ve built: this one’s for me. In the same way teaching your spouse/significant other how to do X is a major pain in the ass, building your own application makes you do dumb, silly things (I think Jeff Atwood might be able to back me up on this one…). This, friends, is a story of my pain to ease your Monday blues.

Starting Out Seemed So Simple…

I had an idea, and the idea was good. So I decided to build an application around this idea and I got together the various tools and things that I thought I would need. I played with the idea of using Rails (for a change – why not), but then a curious thing happened: my inner Type 1 Ass-kicker decided to wake up:

This aint no disco butthead. Build using something you know, stop dicking around!

He’s a real dick – that inner Type 1 Ass-kicker (we’ll call him Bad Rob) and if I don’t listen to him – or at least make him *think* I’m listening to him, well things will just get ugly.

I ditched my Rails musings and plowed ahead with ASP.NET MVC. I grabbed my favoriteTylerDurden testing tools, updated jQuery with my favorite plugins, and I was off to the races. With one exception – I snuck in a last-minute substitution while Bad Rob wasn’t looking: DB4O. Here are the tools I went with:

  1. ASP.NET MVC 1.0 
  2. Machine.Specifications (BDD testing stuff)
  3. XUnit (love u Brad!)
  4. jQuery UI – full suite, ajaxForm plugin, validation plugin
  5. DB4O – just because.

I’ve written about using DB4O before – I love the thing. Persistence made easy! I kicked up VS and got ready to roll…

Good Rob, Bad Rob

That’s when the fun started. See, Good Rob (the guy who likes to write tests *first*, the guy who tries to vet just WTF he’s going to do and why) would have sat down and cranked out some specs against some type of iteration and time plan. Then maybe tied everything to a nice build server (which is purring away at my webhost) and… yadda yadda yadda.

Whatever Nancy-boy, it’s not like you’re getting paid to dick around here and no one’s gonna see your code! This site needs to go LIVE so get ON IT. Yah testing is fun – test whatever you want – AFTER YOU’RE DONE.

And there it is: business vs. process. The best part is that this Fight Club dialog is taking place right inside my skull, and Bad Rob is playing on my fear of “getting something done” while Good Rob wants to do it right.

Yikes. Dueling success metrics (such a lovely corporate term): “results” vs. “quality”.


Yes, this kind of thing is common – in fact it’s expected – in every software project ever undertaken. It doesn’t matter the company and in fact it happened to me at Microsoft. I was working with a team right after I started and I was about a week into the work when we had a team meeting and I was asked to “give a demo”.

“I don’t really … umm… have anything to show… oh wait yah I do – take a look at my test results so far.”

And the room erupted into laughter. “Nice! We don’t have an app but we can show our users some great test results!”

Granted – they were teasing me. All the same I couldn’t help feel that the expectation was that I needed to Show Something. Next time I’m in that situation I’ll be smarter and bring some HTML mockups – either that or Balsamiq.

Good Rob Loses

As always, time is short when doing these things. Bad Rob was continuously reminding me that I needed to get this thing done and out and I gave in to the pressure. It really sucks to give in like this, but Bad Rob can be awfully, awfully convincing.

So I appeased him – I wrote the app quickly and cranked out the initial spec, and the decided I would back everything up with a set of tests. I really, really like the BDD approach so I started with that, and I gave myself 3 hours to write as many tests (errrr specs) as I could.

And then all hell broke loose.

I wish I could surround the following paragraph in glitter and flashing lights, because it’s something that I had forgotten by being “out of the mix” for a few years. I was surprised at myself – so much so that Bad Rob started to panic and got really pissed off at Good Rob for writing “such crappy code”. Here’s what happened:

  1. In my haste to write said application, I managed to goof up one of the main specs. I thought I was doing it right, but…
  2. When I started to write my tests I realized this error, and I started to fix it. This “fix” led to me refactoring a lot of “slop” that I had left until later – the “technical debt” if you will that I figured I’d refactor when I was testing.
  3. The slop started to build, and the refactoring started to spiral. I was fixing things that I knew I shouldn’t have done – things I would have dealt with properly had I slowed down. Next thing you know the entire app was in pieces on the floor…
  4. Including my tests. I had about 50 or so written and now I was commenting out my tests liberally – they were invalid and I felt really dumb for writing them in the first place without using them to validate the code I was going to write!

What was supposed to be a 3-hour fun session of writing tests turned into much more and ended with a shouting match between Good Rob and Bad Rob, with Good Rob threatening that he was “going to BLOG THIS” (looks like he went ahead and did that…).

Back On Track

I wasted hours and hours retro-fitting my little application and stuffing Bad Rob back into his id-box. As I say I knew better, but feel prey to the “we need it NOW” bomb that Bad Rob kept lighting off.

What I should have done was this:

  1. Use Tools you know. I like DB4O a lot – and it worked perfectly as a testing “Fake”. I ran into some problems with it (which I’ll talk about later) and what I should have done was go with something I know.
  2. Write out your specs. I should have written out the specs and behaviors of my app and formalized it into a testing suite. At least 20 or so to get going. Adjustments are easy and reading the behaviors crystallizes WTF you are doing in the  first place. If you’re not a BDD fan – then write your tests in “comment form” – just to get the ideas down.
  3. Have some damn discipline. I know I’ll need ViewModels to handle complex UI logic, I know I’ll need Service classes to handle specialized domain logic as well. I’ve built this application many, many times before – I know what’s out there. Yes – YAGNI and all but in terms of structure, there is arm-waving   and then there’s reality. These things I know.

What I ended up doing was:

  1. Moving to SubSonic. I know it like the back of my hand and the SimpleRepository fit the bill nicely. I was also able to add some cool features in (which I’ll talk about later). DB4O is great, but if I’m really in a hurry then I need to stick with what I can make sing.
  2. Stopping everything and specc’ing (how the hell do you spell that word?) out every last element of what I was building while thinking it through from end to end.
  3. Write code *only* when you have a mandate to do so. Yah I’m a smart guy and yes, I can juggle things in my head – I’ve been doing this for a long time. I was wrong, however, when I started to assume.
  4. Stopped worrying about domain names and CSS and didn’t look at the web app for the rest of the day.

The Score Card

For those of you who don’t think “qualitatively” – here’s the breakdown on lost time:

  1. I had a 40% loss on rewriting existing tests
  2. a 25% loss on refactoring things the way they should have been done in the first place (using Services, View Models, etc)
  3. a 40% loss on removing DB4O and going with SubSonic. Caveat: I didn’t *need* to do this but I had a gut feeling.
  4. a 30% loss on restructuring my repository to be less DB4O-specific (using Add/Update methods, removing Flush/Commit). This was dumb.

Overall I would have been 1/3 ahead had I “done things right” – or more appropriately I would have finished in 2/3 of the time. That’s a lot of time!


The only reason I got so derailed is because I have a major stake in this thing’s outcome. I can forgive myself – just this once – for getting carried away and I’m happy that the damage wasn’t too great.

Bad Rob is happy that the app works and it’s lighter and more nimble than before. Good Rob is happy because his assumptions are covered and he can see the light at the end of the tunnel.

Posted in Uncategorized | 7 Comments

You’re Not Your Data Access

Seems I touched off a bit of a “swirl” with a comment I made on my last blog post:

I think, in general, the .NET crowd overthinks and over-engineers just about everything

I said as much in my MIX presentation, where I basically challenged ASP.NET developers to “embrace their inner scripter” and stop building rockets. I have a fairly strong opinion on this – and I’ll save that for another time – but I think it’s high time to remind folks that there’s a lot more to an application then how you get your app gets it’s freak on with your database.

Good Morning!
I remember watching Fight Club for the very first time back in the thick of the very first DotCom bubble. I was feeling pretty ill that day so I stayed home and watched the DVD, and was pulled in pretty dramatically. One line still resonates with me:

You’re not your job. You’re not how much money you have in the bank. You’re not the car you drive. You’re not the contents of your wallet. You’re not your f******* khakis.

I feel the same way about building software: You’re Not Your Data Access.

When I watched that movie I had just bought a nice pair of $180 Kenneth Cole shoes to wear to a client’s VC meeting, to go with my groovy business-casual Cornflower Blue button down shirt. I clearly remember looking over at my closet – the feeling of fashion sobriety coming over me – wondering what I had turned into (if you knew me then you’d know I don’t like wearing that kind of stuff. I’m happy in a white t-shirt and shorts).

I had this same feeling when I popped my head out of the .NET community just 4 years ago (before I worked at Microsoft) to see what this “Rails thing” was all about. I remember the feeling well – and it was very, very sobering and inspiring at the same time. I remember creating an application in fairly short order with all the requisite pieces put where they needed to be put, with every tutorial urging me to “stop thinking – just build”.

Camaro Programming
The .NET platform is pretty dang powerful. It lets you build your own personal Tower of Babel if you so choose, and it can abstract away the very fabric of space-time if you let it. In short it’s a killer set of tools that any mechanically-inclined tower-of-bableperson would love to use. So naturally it can be very easily abused!

Consider my good friend Eric. I’ve written about Eric a few times before – but in summary he’s my token wrench-head friend that loves his engines and American cars. I lived with this guy for years and he rapidly  filled up our garage with parts and *crap* from every car he’d ever owned. And he could dutifully tell you which part went to which car and what that part did – no matter if it was useless.

Eric built and maintained a hunk of junk 1968 Capri which we used to call “The Crappy”. This thing could drive – and I mean really drive – I think Eric pushed it to 180 mph once on a closed race course. It had that sound that all muscle cars make – the sound that makes your ribs shake and your inner 16 yr old say “coooooolll!”.

The problem was that no one ever wanted to drive in it. It smelled, it was ugly, and it absolutely sucked the gas down. Eric would steadfastly defend his Crappy because “it was the easiest car in the world to work on” and “could blow doors on any production car from any country”.

“Yah but when do you really need to go 180 miles an hour man?”

“When I race dammit”

I don’t need to draw the parallels here. I think you get it.

Let it Go Already
I want to be perfectly clear about what it is I’m saying here, and that is that it’s very, very easy for the geek inside us to whisper sweetly in our ears, saying “this Super Massive Paradigm Shifter will be the biggest application EVAR… don’t mess it up!”. I felt this very sensation when starting … well every app that I ever made.

I don’t like being wrong – no one does. So defensively I’ll be sure to include patterning where I can, making sure to separate out my projects whenever it … seems like I’ll crap for not separating out what I’m doing into another project.

I’ll use enums instead of boolean parameters.

Oh wait, no I won’t.

I’ll be sure to avoid Singletons

I’ll absolutely never use Stored Procedures, I mean seriously never, ever, ever (unless Rob Howard tells me to). Or maybe unless my boss tells me to. I’ll let Jeff decide.

I’ll always use Stored Procedures.

I won’t use NHibernate

I won’t use any ORM for that matter. Seriously – Never.

Well I might use both

I won’t use Code-coverage to tell me anything.

I’ll be sure to use Code-coverage data to tell me everything.

I’ll make sure my method and variables are named properly on Fridays.

Reflection? Not a chance. Unless Rick says it’s OK.

I won’t use Extreme Programming (I’ll be sure to use Lean… whatever that is)

I’ll be sure not to have scrums.

I’ll also be sure not to multi-task.

I won’t use configuration either – hard-coding FTW!

I won’t use static methods

I won’t use extension methods

I’ll keep Native American stereotypes out of my code.

I’ll make sure that all my methods are public and never sealed or internal

I’ll check twice before I use any of these evil keywords.

I’ll also make double damn sure not to use regions in my code – ever.

I won’t use VB (who would?) and I’ll be sure to use C# with great care.

I won’t use Composite Keys in my database

And I’ll be very, very sure to keep away from Norway.

You wake up at Seatac, SFO, LAX. You wake up at O’Hare, Dallas-Fort Worth, BWI. Pacific, mountain, central. Lose an hour, gain an hour. This is your life, and it’s ending one minute at a time. You wake up at Air Harbor International. If you wake up at a different time, in a different place, could you wake up as a different person




Simplicity is beautiful. Simple doesn’t mean hard-coding, it doesn’t mean cutting corners or being sloppy – it means building what you’ve been asked to build, not a rocket to Saturn and most of the time it’s a skateboard to the corner store.

Not every application needs to be stitched together from Codebetter posts and Twitter rants. Focus on what’s important – the experience, not what’s under the hood. You’ll change that quite a few times no matter what you think :).

Posted in Uncategorized | 34 Comments

Jumping The 20 Fence

Before I worked at Microsoft I worked at/with/for various startups. Depending on who you talked to, I was involved in building rockets, the Next Big Thing, and a Super Whamadyne Paradigm-Shifter. Since I’m not a millionaire and you don’t see my face on Wired you can guess that those things didn’t quite pan out.

There are a lot of reasons why projects don’t “pop” – but in some ways I think people can tell if they are “gazing wantonly in the pond’s reflection” by constantly asking a set of simple questions:

    • What are we doing?
    • Why are we doing it?
    • What do we hope to get out of it?

A lot of people would say “sure – that’s what ya call a Mission Statement Rob!” and in some ways, I spose it is. But the next part is the hardest:

Does it motivate you?

The Hard Truth
In every human endeavor the 80/20 rule (aka Pareto principle) cruelly applies – which is effort/payoff are inversely related. This principle is at the core of the just about any time/management book/philosophy – and these things usually boil down to constantly shifting your focus to “what’s important” (aka the 20%).

It seems the 80/20 thing is built in to the fabric of the universe, along with some other groovy numbers. Most large software companies have come to realize this – including Microsoft:

"One really exciting thing we learned is how … a relatively small proportion [of bugs] causes most of the errors," Ballmer wrote in his three-page memo. "About 20 percent of the bugs causes 80 percent of all errors, and–this is stunning to me–1 percent of bugs caused half of all errors."

If we apply logic here then the opposite of this statement must be true as well:

80 percent of the bug-free functionality is produced by 20% of the code.

If that’s true – we’re writing way too much crappy code. Let me reword that – 80% of the code we write does 20% of the work and contains the bulk of the bugs (my math skills got lost there). Which side of the 80/20 code pool are you swimming in?80-20-rule-coops-manhattan-real-estate[1]

Sherman, Set the Wayback Machine
It’s 2000 and I’ve just ordered a tin of Pringles and The Fragile (Right and Left) from Kozmo. It’s 11pm and I should be at home, but I’m hammering away on my client’s app, trying to get a demo ready for Yet Another VC Who Wants To See Stuff Spin. I’m cranky, tired, and my wife is getting tired of this constant circus of late nights.

The phone rings as the speakers are blaring in our Live/Work Loft/Office on 2nd and Brannan and I’m listening to Trent growl his way through “The Wretched” and I see the area code – it’s New York. My client. Crap.

After 10 minutes of telling him everything’s on pace, he recaps what he wants to see. Amazing – he added 4 new requirements! How very … like him.

I ask him the question:

“What are we doing again? I mean what’s your goal here anyway once all of these demos are done and you’re really rich.”

I hear gasps on the other end of the phone, some choice swear words that involve an ice-pick and my retina, and then *click*.

The phone rings 5 minutes later and it’s The Client. “Do you mind telling me just what the **** you’re asking me these questions for you ****in moron?”. I’m used to “the East Coast” thing by now and I reassure him I know his requirements – I understand the specs and priorities – we’ve been through it a ton. I know about the demo.

I want to know about the day after the demo.

His answer was simple: “We’ll be millionaires. Who gives a **** what else – we’ll be the next tech IPO and you can buy your wife a maserati so **** off and build my ******* app!” (the East Coast thing gets annoying at times – but you get used to it. Don’t get me wrong – I like the other side of the country and all, but they can get pretty spun up over there).

We got the funding – a lot of it. And the company still managed to fail – I think it’s when investors figured out my client was full of crap. I should have figured it out too – but back then everyone was involved in an IPO or buyout. It was a “Craigslist Party” of geeks and power money and you just didn’t ask questions. Or so I thought.

What’s Your Answer?
Twice I’ve worked on a winning application – and it feels great. And by “winning” I mean the client and their clients were stoked, and it literally made people cry. One of my very first applications – an info portal for Ameritech (now PacBell) was one such application. It was so very, very simple that it had to work – it was a classic ASP app (I wrote this in 1998) that used IndexServer to crawl over 12,200 documents scraped from their mainframe.

Their existing app was a terminal-based app and it was all paging and CTRL- shortcuts the user had to memorize. I made a web interface (we called it the “Yahoo UI”) that worked on fuzzy search and BAM – scraped 30 seconds off the average “satisfaction timer”. This meant the call center reps could answer people 30 seconds faster than before without the carpal-tunnel and by using the “new web thing”. I’m not kidding you – one of our User Acceptance participants (an actual rep) started to cry.

If you asked me or any member of that team what we were doing we would have said the following (with minor variations):

    • We’re building a web app to reduce the time to answer for call centers
    • We’re doing it because our existing app sucks and it’s too hard to learn. Turnover is killing us.
    • We hope to have happier call center folks and happier customers

These answers are all kinds of win because they’re grounded in something real: making a job easier/better/faster. They don’t involve greed and aren’t out to change the way the Earth spins – simple and direct and dare I say truthful.

Smelly Answers
I’ve asked these questions various times over the years and aside from my client from hell above, I’ve received some real winners:

  • “We’re going to be the Premier [WHATEVER] and direct all buyers of [X] to use our service and we’ll make wads of cash”
  • “We’re going to Change the Game with this app, and in doing so make wads of cash”
  • “We’re going to dominate the [BLAH BLAH] space – we’ll actually become the internet. We’ll make wads of cash”
  • “Right now there’s a massive void out there and we’re going to fill it. We don’t know how we’re going to make money – but we’ll get there soon enough”
  • “I don’t know really – I’ve been told to build this thing so I called you. I need a beer.”

People and technology are funny and scary at the same time. Sort of like clowns. When I tell people what I do they get a really weird look in their eye (you know the look I mean) and sometimes I don’t know if I’ll be “fixing their internet” or hearing their great new idea to make tons of money. I, evidently, am a bit like Willy Wonka:

We are the music makers, and we are the dreamers of dreams”

Mr. Wonka also offered a followup – which I hold to very tightly:

“You should never doubt what no one is sure about”

If we agree, by now, that this 80/20 thing has some merit, then it stands to reason that there’s an 80% chance you’re working on a project with a smelly set of directives. You ended up here by the various laws of the universe that sprinkle geeks across projects like salt and pepper – but you don’t have to be the 80% tripe!

You can change this: you can jump the 20% fence. You just have to help your team face the problem plaguing them – which is usually a weird direction that has to do with wads of cash, changing the game, or shifting some paradigm.

Get their heads back in the game and make sure you’re kicking ass for humanity – and you can figure this out pretty quickly by asking some simple questions and listening for:

  1. Delusions of grandeur
  2. “Wads of cash”
  3. “I don’t know yet” spoken 2 or more times
  4. The solution isn’t a win/win (you, client, end-user)
  5. Frustration at the question

If you don’t get concrete answers point to YouTube: a really dead-simple app that makes people really happy. Just like a puppy or a kitten – without the poop. Or Twitter – one of the silliest, most relevant applications ever made (that has yet to make a dime… but anyway).

You can change things – you really can. As long as your team is willing to listen and engage and if they’re not, well maybe it’s time to look for the golden 20% out there.

Posted in Blather | 5 Comments

What Should Microsoft Do For .NET Open Source?

I’ve been reading a lot of old blog posts tonight regarding Microsoft and Open Source – it really reminds me of the interesting stances the company has taken over the last 5 to 10 years (I’ve only been working with Microsoft for just about 2 years now). For instance – I read a post from Scoble that goes over why "Web 2.0 entrepreneurs" don’t trust the M$ Stack – and I must say, it’s a pretty interesting read and the points that Scoble raises are still felt pretty strongly:

As I’ve been going around the world I’ve been meeting with many people who’ve built their companies on non-Microsoft stuff. Some of whom have companies worth billions of dollars now. Some of whom you’ve never heard about unless you read TechCrunch. Here’s 12 reasons Web 2.0 entrepreneurs like Ross tell me that they aren’t using Microsoft’s stuff:

1) Startup costs. Linux is free. Ruby on Rails is free. MySQL is free.
2) Performance per dollar. They perceive that a Linux server running Apache has more performance than IIS running .NET.
3) Finding tech staff is easier. There are a whole new raft of young, highly skilled people willing to work long hours at startups who can build sites using Ruby on Rails.
4) Perception of scalability. The geeks who run these new businesses perceive that they can scale up their data centers with Linux and not with Windows (the old “Google runs on Linux” argument).
5) That Microsoft doesn’t care about small businesses. After all, Microsoft is an evil borg, but Ruby on Rails comes from a single guy: David Heinemeier Hansson. He has a blog and answers questions fast.
6) That open source makes it easier to fix problems and/or build custom solutions. A variant of the old “Google or Amazon couldn’t be built on Windows” argument.
7) On clients, they want to choose the highest-reach platforms. That doesn’t mean a Windows app. Or even an app that runs only in IE. It must run on every variant of Linux and Macintosh too.
8) They don’t want to take shit from their friends (or, even, their Venture Capitalist). Most of this is just pure cost-control. I can hear the conversation now: “OK, you wanna go with Windows as your platform, but is the extra feature worth the licensing fees for Windows?”
9) No lockin. These new businesses don’t want to be locked into a specific vendor’s problems, er products. Why? Because that way they can’t shop for the best price among tools (or move to something else if the architecture changes).
10) More security. The new businesses perceive Linux, Apache, Firefox, and other open source stuff to have higher security than stuff built on Windows.
11) More agility. I’ve had entrepreneurs tell me they need to be able to buy a server and have it totally up and running in less than 30 minutes and that they say that Linux is better at that.
12) The working set is smaller. Because Linux can be stripped down, the entrepreneurs are telling me that they can make their server-side stuff run faster and with less memory usage.

I’d love to know if these opinions have softened at all – or if they’ve been further reinforced – especially given the release of ASP.NET MVC (and it’s subsequent listing on Codeplex under Ms-PL). I’m going to guess that they’re roughly the same: people will believe what they’re going to believe and for some reason, when it comes to Microsoft, changing people’s minds is really hard.

One thing that’s particularly interesting to me is that Microsoft, at least some divisions, are actively changing their "thinking" if you will to a more open posture. The Ms-PL of ASP.NET MVC (mentioned above), some of the work that Developer Division is doing with the Mono team, and the source availability of the entire .NET stack (yes, I know it’s still not open) are evidence of a shift in thinking.

Great! But now what?

Clearly openness and transparency is super groovy – but then what? I’m a huge champion of the open and transparent thing and I’ve been able to do some great stuff in the open with the MVC Storefront and I’ve taken you along with me. I like to think that I was brought to Microsoft to help keep "rolling the bubble" towards more openness – but I have no way of knowing where the rowers are a-rowing; so I just keep plugging along and thankfully they’re letting me :).

The Storefront has been a great learning tool, and a lot of people have thanked me for it (and you’re all very welcome! I learned a ton too). But now what?

It was always my intent to pop what I did up on Codeplex and share it with people with the idea that if it had legs – well hooray! So far I have every reason to think it will become quite the open, flexible, "new thinking" type of application that people can learn from, use, extend, and so on. It fires me up and makes me pretty happy because I really like Open Source and what it can do.

But then again – I’m a Microsoft employee and this is a Microsoft project, after all. They’ve given me tremendous latitude to do with it what I will so people can learn core concepts surrounding ASP.NET MVC. That part is sort of done, and now we have Kona – an app that I’m hoping will be somewhat influential with respect to Open Source apps built on ASP.NET. Nice idea – but then there’s the fact that I work on the ASP.NET team.

What does it mean to you that I’m an MS Employee, on the ASP.NET team, building an OSI-licensed ecommerce app? Do you think Microsoft should do more things like this in a more formal way? Or should it stay out of the picture and let others run with this kind of thing?

There are so many questions that I have in my head – and I’m very, very interested to know what you think here: What do you think Microsoft should do with respect to Open Source and .NET?

Posted in Philosophy | 33 Comments