SteveStreeting.com

It’s that time of year again, the end of that artificial construct we call a ‘calendar year’ that prompts so many of us to cast our minds back over the last 12 months. So, apart from rocketing helplessly through space at 107000 km/h, only to return to where we started (relatively speaking, ignoring where Sol and the Milky Way have moved since then), what’s up?

As I talked about in my review of 2010, my goal had been to simplify and take back more control in my professional life, revolving around making my own products and cutting down contracting to just single, more significant projects. To that end I’d created SourceTree – this surprised many people, who asked “Why would you go from making a 3D renderer to writing a source control system?? Isn’t that boring?”. Well, actually no – I like learning new things, and I like solving problems, particularly the ones that I have myself, and so SourceTree ticked those boxes, giving me the opportunity to do some native Mac development and scratch my itch for a DVCS tool that worked the way I wanted at the same time. It also made perfect sense from a business perspective, because it was self-contained, deliverable with my modest resources, and there was a proven market for selling independent Mac apps.

Another subconscious reason that I’m aware of more now was that I needed to prove to myself that I could do something unconnected to my (long!) history on Ogre and make it work. I was starting to wonder whether I was capable of repeating the (popular) success I had with Ogre elsewhere, and particularly with a commercial product – was being free & open source the only reason I’d managed to build such an audience? Could I compete when I’m asking people to pay, and without that previous backdrop where many people feel they owe me a beer for all the free code & help I’ve given them in the past? I kinda needed to know.

On the whole, it went a lot better than I expected. At the beginning of 2011 SourceTree was just starting to get noticed, and was slowly growing, with lots of really nice feedback from people (even when it was critical). It was still a very nervous time; numbers were still well below where they needed to be and success was far from certain, and I’d already invested a fair amount, so I took a contracting job for a few months in parallel to help replenish the coffers. This was actually a really cool project, a Mac app based on Ogre that simulating lighting rigs for music concerts for a UK company that ran the real things, and I loved doing it. But following the launch on the Mac App store, and with word of mouth recommendations building – I’m not very good at marketing, so I really appreciated my users helping me do that – within a few months SourceTree was self-funding, just in time for that contract to finish. I hadn’t expected to start breaking even until about the 18 month point, so this was a lovely surprise. Not wanting to get complacent though, I started planning other projects, with the intention of running one in parallel with SourceTree to make sure I wasn’t completely reliant on it.

Everything changed though when Atlassian approached me about acquiring SourceTree, which completed in October – I’ve already talked about this in detail so I won’t repeat here. So now, by a curious twist of fate, I’m in the unexpected position of developing a free product (at least for now) again! I’ve certainly enjoyed the spike in users that’s provoked, and I love being able to tell people they can just go grab it for nothing, but it’s also nice to know that people were willing to pay for it too, before those nice people at Atlassian subsidised it for everyone.

In summary, 2011 has been really good to me. I’ve had lots of new experiences and learned a hell of a lot, which alone I count as a very positive thing. Managing to build up a successful new product and to go through my first acquisition in 12 months was pretty demanding, but very satisfying and confidence building at the same time, something I’m sure I’ll benefit from in future.

Much of the tech media would have you believe that creating a technology business requires you to court VCs, move to Silicon Valley and do something ‘fashionable’ (which right now means having ‘social’ in the brief somewhere), but that’s simply not true. Sure, if you’re expecting to rake in millions of dollars in seed funding and expect to retire on a private yacht in your 30s then that might be the only way you can do it; assuming you’re happy with running that gauntlet with a chance you’ll become one of the many roadkill that the press don’t talk about. But if you just want to make a good living and prefer to do it working on projects of your own creation, it definitely is possible, even if you’re just one guy living on a rock in the ocean. 2011 reinforced that belief in me, and for that, above all, I’m very grateful.

I hope you had a good 2011 too Best wishes for the holiday season, and have a great New Year.

This week I implemented a much-requested feature in SourceTree for the upcoming 1.3 release (beta 1 went out on Monday, this will make it into beta 2) – a command-line tool so you can quickly pull up SourceTree for the repository you’re in from a terminal. Writing the command-line tool was trivial, but when I came to implement the menu item which would install it in /usr/local/bin, which inherently needs privilege escalation, it turned out to be a lot more complicated than I expected.

How so? Surely lots of people have done this sort of thing before? Well, that’s true, they have – but the problem is that just about all of the existing examples of this use the Authorization Services API call AuthorizationExecuteWithPrivileges – and this method is deprecated in OS X 10.7 (Lion). Now, of course that doesn’t stop you using it (yet), provided you’re willing to turn off the warning that building against the 10.7 SDK gives you, but any programmer worth his salt should take deprecation as a hint that they should be looking for another way.

There are basically 3 ways to escalate privileges on OS X, and only one of them is now recommended:

1. Use a helper tool which has its setuid bit set so that it runs as root. Risky if that tool gets compromised, and the setuid bit can be lost, needing reinstatement by another privileged task.
2. Execute a command as root via AuthorizationExecuteWithPrivileges. As mentioned above, this is now deprecated, and again if a hacker compromises either the app or the tool being launched, bad things can happen.
3. Ask Launch Services to install a privileged helper tool via SMJobBless. This helper is subsequently run by launchd as root when invoked via a Unix socket, and can perform privileged tasks. Importantly, code signing is verified at both ends by Launch Services at install time to prevent tampering with either binary.

Clearly option 3 was the way to go – the only ‘downside’ about it is that is does require that you have the ability to sign your application and helper tool. I already have valid code signing certificates because I deploy on the App Store, so this isn’t an issue (even though this functionality won’t actually be in the App Store version of SourceTree because Apple disallow installer behaviour there, I still sign with the same certs). In fact, the fact that I know my app and helper tool can’t be interfered with without the code signatures becoming invalid is very reassuring. Given that it only costs $99 per year to be on the Mac Developer Programme which allows you to get certificates (even if you don’t deploy on the App Store), it’s something serious developers should consider strongly.

SMJobBless is ideally suited to installing daemons, but it’s perfectly acceptable to install tools which run simple one-off tasks too. When setting up the plist for the helper, you specify that it is ‘OnDemand’, with no ‘KeepAlive’ which means it’s not started by Launch Services at startup, only when a Unix socket is opened, and shuts down very quickly if there’s no activity. Unfortunately the SMJobBless example doesn’t do anything except to show you how to install a tool, it doesn’t tell you how to implement that tool to do anything useful, or how to call it from your main application.

To see how to do that, you need to refer to BetterAuthorizationSample , which includes a re-usable library for this. Ironically though, this example uses AuthorizationExecuteWithPrivileges to install its helper (this example pre-dated its deprecation in favour of SMJobBless). So you have to remove all the code associated with installation; you won’t need it anyway since SMJobBless does that function better. You keep the rest which gives you a framework for implementing and calling the helper. So here’s what I did:

1. Implement the installation of a privileged helper, based directly on the SMJobBless example. I needed to change the bundle IDs and the certificate CN’s to match my setup of course.
2. Extend the plist files from SMJobBless to register the helper with a socket. This was basically a case of copying the settings from the BetterAuthorizationSample plists, which already does this.
3. Bring in BetterAuthorizationSampleLib.c/.h to assist with implementation of the helper, and the code for calling it in the app, but remove everything in the ‘Installation’ section. This eliminates all the references to AuthorizationExecuteWithPrivileges – we’re doing the install with SMJobBless so don’t need that.
4. Follow the BetterAuthorizationSample for the implementation of the helper, and the bit in the application where you call the helper to perform privileged operations.

So in my case, the following happens when you click ‘Install Command Line Tool’ in SourceTree:

1. A privileged helper is installed in Launch Services using SMJobBless. OS X checks the code signatures on both ends to ensure that the helper and the application asking to install it are valid (must be signed with my cert, and that cert must be issued by Apple).
2. A connection is opened to the privileged helper over a socket which causes launchd to start it up
3. I ask the helper via the BetterAuthorizationSampleLib to install the command-line tool in /usr/local/bin. As an additional check, the helper validates via ‘codesign -v  -R=”conditions”‘ that this tool is code signed with my cert (again, must be issued by Apple) – this is to prevent anyone else sniffing out this socket and trying to use it to install other things. If that passes, it installs the command.

This is quite a long-winded process compared to just calling a ‘cp’ command via AuthorizationExecuteWithPrivileges, but it’s also a lot more secure, since a malicious person can’t alter any of the moving parts without invalidating the code signatures. You’re also insulated from future changes when inevitably AuthorizationExecuteWithPrivileges is removed entirely.

I apologise for the lack of a pre-packaged example here – I haven’t had time to extract one from my own implementation yet. However, as described above if you start with the SMJobBless sample and add-in the BetterAuthorizationSample, removing from the latter everything associated with installation, you’re basically there. If I get chance later I’ll post a shrink-wrapped example.

I hope that helps someone – I found there to be little information on this subject that was up-to-date, and lots of older information that was misleading so maybe this will save someone some time. Ideally, I hope Apple will combine the SMJobBless and BetterAuthorizationSample some time to produce a 10.7-compliant official example.

A lot of you will already know, but SourceTree, a Mac client for Git and Mercurial I created over the last 18 months, has just been acquired by Atlassian. There’s a press release, articles on TechCrunch and VentureBeat, and an official FAQ on the SourceTree site. But this is my personal blog, and I’ve had a few requests for a personal angle on this, so here you go.

I said in a previous post that in my experience, the best opportunities often come along when you’re not looking for them, and that was certainly the case here. I wasn’t even thinking about looking for acquisition opportunities for SourceTree – sure, the idea had crossed my mind as something I might want to consider eventually, but it certainly wasn’t an active line of thought this early in the product lifecycle. SourceTree had grown to become a viable business for me, and I was very much enjoying the process of just creating a software product that I used every day myself too.

So, when the Atlassian opportunity came up, I wasn’t at all prepared for it, and I had to make some decisions. I was enjoying being master of my own destiny, and was managing just fine – so my initial knee-jerk reaction was to be very cautious. However, the more I thought about it, and the more I learned about Atlassian, the more I realised what a huge opportunity I’d be turning down, both personally and for SourceTree, if I said no.

Any acquisition kicks off with a financial offer (don’t expect details, they won’t be forthcoming ), but that’s far from the whole story. In my case I didn’t have any pressing need to sell, and I’ve learned from experience that being happy about what you do is extremely important. I also have a strong attachment to the products I create – that’s why I stayed with Ogre for 10 years and it was/is still a wrench to leave – and that’s the case with SourceTree too; not to mention that I’m a daily user of it myself. So if I was going to sell, it had to be to the right company who would look after it just as well, or better, than I did.

Luckily for me, I discovered that Atlassian was about as perfect a fit for SourceTree as I could have asked for. Atlassian lives and breathes developer tools – that’s their entire product focus, which in itself is a good start. They’re investing heavily in DVCS tools – hence the 2010 Bitbucket acquisition and its recent enhancement to handle Git as well as Mercurial (which of course SourceTree does too) – again spot-on on the compatibility chart. I learned, particularly when I visited their HQ in Sydney, that everyone at Atlassian really ‘gets’ developers (well, most of them are developers after all), and care a lot about giving them good products. Development tools permeate the entire company – the CEO is a regular user of SourceTree, and people in marketing understand when you talk about version control. Even though they’re quite a big company now, it retains a startup feel. Then there’s their corporate values, which are very much in evidence when you talk to people there – things like “no bullshit” and “don’t f**k the customer”. And it’s not just on the wall, it’s really how people in the company make decisions. These are the kind of people I can relate to, and definitely the kind of people who can add a lot to the future of SourceTree.

Another thing I found reassuring is that at no time was there any question that Atlassian would want to railroad developers into their own tools at the expense of others. Clearly Atlassian already owns Bitbucket, and SourceTree supports Bitbucket, GitHub and Kiln already. It was made abundantly clear to me that no-one at Atlassian took the view that restricting developer choice to favour Atlassian tools was a good idea. Their ideology is to make developer’s lives better by giving them choice, and of course they’re going to want to offer good Atlassian options in there, but if a developer wants to use an alternative, no-one is going to stop them.  The view I got from everyone was that giving developers a positive experience that reflects well on Atlassian, including giving them their own choice of integration, is far more valuable than artificially chaining them in. Obviously, I concur.

My final reason was that while I really, really enjoyed creating and supporting SourceTree myself, the workload is quite high, and was increasing. It’s not a continuous death-march, but the availability requirements are very high – since I was developer, webmaster, sales, customer support and everything else all rolled into one, taking a day off was basically impossible. Making sure the website was still up, and making sure customers got a quick response to support calls, was a 24/7 responsibility. After a while, that gets tiring, even just checking on things all the time means you never have ‘proper’ downtime. A big advantage of joining Atlassian is that I get some extra backup. That’s good for my health & mental wellbeing, and I’m sure that will be good for SourceTree too long-term. I really didn’t want to start resenting SourceTree for preventing me having a proper holiday occasionally

So based on all these factors, I decided that the future for both myself and SourceTree would be better within Atlassian than continuing alone. I learned a lot along the way to this acquisition – dotting all the i’s and crossing all the t’s turned out to be more time consuming and stressful than I expected, so I wouldn’t say it’s a process for the faint hearted, but if you’re as lucky as I was to be approached by the right company, it can lead to a really great outcome.

I’m still fully committed to developing SourceTree, like I was before, but now it has a more robust support structure around it. Taking things to the next level, both in terms of user base and features, is so much more practical now within Atlassian. I’m very confident that they’re the right company to take SourceTree forward – our thinking is very similar, I respect their values a great deal, and the people are great. My decision was a lot easier than it might have otherwise been because of this!

“So, where do you see yourself in 5 years?”

I’m willing to bet every person reading this has had that question posed to them at some point, most likely in a job interview, but possibly during an appraisal, or if you’re really unlucky, by a potential father-in-law at a dinner party. I’m going to call it out right now – it’s one of the stupidest questions you can be asked. It’s a test, of course – does this person have a plan? Are they committed to their career? Or, more accurately, can they make something plausible up on a whim, by accurately judging the kind of crap that I, the questioner, want to hear?

OK, so maybe there are some people out there who genuinely plan their career out 5 years in advance, but I also imagine they’re rather dull people to be around. I can’t recall for sure, but to my regret I think I may have asked this question myself in interviews many years ago, embedded as I was in an environment of conformity and convention which demanded certain inexplicable behaviours handed down from forefathers whose underlying reasoning (such as it was) was long forgotten. If I asked this question of a recruit now (and I wouldn’t, but if I did), I’d only be asking it as an ironic anti-question, since I now believe the only honest and vaguely correct answer is “How the hell should I know?”. At which point I’d probably give that person the job just for being honest and we’d figure out what to do next on the fly, which is what we’d have done anyway of course.

Because when it comes down to it, plans (of any kind) are one part fairy tale and one part straight-jacket. Not only are things not going to turn out the way you think now on any time scale beyond the life of your average housefly, leading to the very real expectation of self-abuse for not delivering on ‘The Plan’ (choral accompaniment), but by being fixated on past expectations you’re very likely to be less adaptable to change, and to pass up alternative opportunities that you didn’t expect. And that’s not a minor issue: the best opportunities I’ve ever had have always been unexpected, and my primary successes have been universally unplanned. Looking back, choosing and setting a direction in life at any point in time was important, but planning specific goals was not, because all the best stuff just kind of happened along the way.

So, if you do interviews, please stop asking this question, it’s meaningless. Everyone has a current direction, but let’s not kid ourselves about the immutability of that vector, or that the destination is knowable. If it was, life would be pretty boring anyway, right?

I was In Sydney when the UK riots broke out, and I didn’t hear about it until it had become an international story which showed Britain in the worst possible light. Much hay will be made about this over the coming months, but I thought I’d add my tuppence worth.

Firstly, there can be no justification whatsoever for this behaviour, regardless of your background or surroundings. But it is a good idea to try to understand it, because locking people up after the fact only goes so far. None of what I raise here excuses what we saw on Britain’s city streets, but it does provide a context.

Society is based on the concept that most people will be law-abiding, because it is in their collective interest to be so. It’s one of the defining characteristics of being human that we have the self-control to defer our own short-term gratification in order to achieve longer term objectives, particularly shared objectives. What is happening with increasing frequency is that some people are no longer willing or able to do that – and they’re not all wearing hoodies.

Now, it’s quite easy to point at an obvious example of self-absorbed gratification from the last week, such as someone looting expensive electronic goods from their neighbourhood store. But on a more subtle level, this lack of willingness to defer gratification is something that increasingly pervades our modern society, just at a less visceral level. Our consumer society has for years encouraged people to buy things they can’t afford through the high availability of credit – don’t save up, have it now! Even worse, at every level of society now there is a general attitude that what matters isn’t “what’s right”, it’s “what you can get away with”.

There are myriad examples of this. Politicians scamming their expenses system because it wasn’t strictly disallowed, even though anyone with an ounce of sense should have known it was immoral. Bankers risking all to get rich in the good times, knowing that in the bad times someone else will pick up the tab. Patent trolls gaming a broken legal system to make money from doing nothing at all, by taking it from those that do. Basically, the message at all levels is: if you think you can get away with it, go for it. Even if common sense would tell you that you’re being a dick, it doesn’t matter – law of the jungle and all that.

What we’re really seeing on Britain’s streets is the very ugliest incarnation of this, but it’s rooted in exactly the same attitude, and we can’t pretend they’re separate things. The political or white-collar side of amoral behaviour doesn’t result in houses burning down and people dying, so we don’t notice as much until it goes really badly wrong (like in the credit crunch), but it’s ultimately the same thought process – I know this is wrong, but I’m going to do it anyway, because either I think I won’t get caught, or there’s some clever legal wrangling that lets me off the hook even if I do.

Some might cite the demise of religion as a cause of the lack of moral fiber, but that’s not it at all (the Catholic church is one of the worst perpetrators after all). No, it’s really very simple – more people need to stand up for a singular and easily communicated principle: “don’t be a dick”. And stop pretending that you don’t know when you’re being a dick, or that you have some kind of justification for it. We need to stop looking for technicalities to excuse behaviour we know is wrong, and for ways to avoid getting caught. Laws are there as a distillation of this concept (sometimes they get it wrong too), but the original form is much simpler to understand – you really don’t need a lawyer to tell you when you’re being a dick. All the people involved in the subprime mortgage crash knew they were doing something dodgy, but they carried on anyway. Take this same attitude and put it in the mind of an ill-educated thug with a brick in his hand, and what do you think is going to happen?

If you want to live in a pleasant society, live by example, whether you wear a hoodie or an Armani suit. You really don’t want to live in a society where everyone just does what they think they can get away with. Maybe it took thugs in the street burning and looting to demonstrate the eventual trajectory of this to you, but that’s just the tip of a particularly dirty iceberg that every one of us has a part to play in cleaning up.

I left Facebook about a year ago and have been using Twitter as my primary social tool ever since. At the heart of this decision were my main gripes with Facebook:

1. Facebook misrepresents relationships
   It’s clear that Facebook was designed by a young person with borderline Aspergers. Relationships are black and white, you’re either a Friend or you’re not, and they’re symmetrical – information has to flow both ways. The real world doesn’t work like that, I have real friends, family, casual acquaintances, people I like to keep up to date on but who I’ve never met, and people who like to follow me but who I don’t know. I interact with every one of these groups of people differently, and very often in asymmetrical ways. The concept of a ‘Friend’ who I’d share private information with online is completely unrealistic. I know Facebook bolted on ‘lists’ but everything is totally hobbled by this misguided overarching ‘Friend’ concept.
2. Facebook’s signal-to-noise ratio is unmanageable
   Whether it’s automated posts from games & other poorly considered apps, or just people pouring every trivial little element of their life into it, I was drowning in trivia in a few months to the extent that it was a chore to keep up to date. This is a function of the people you’re connected with of course, but here’s the problem – because of the way Facebook simplifies relationships, you can’t really do anything about it without offending someome, because:
3. Facebook creates social awkwardness
   Because Facebook only recognises one type of connection as pointed out in 1, it makes managing your information stream impossible without offending someone. For example, I may very well have real friends / family who I want to connect with, but who I don’t necessarily want to listen to 24/7 because they have .. ahem.. ‘very poor communication filters’. That doesn’t mean I don’t like them, we just communicate very differently. Sure, I might want to dip into their updates every so often, but I don’t want to have to wade waist-deep through their posts every time I go online to find the gems from people who are better at filtering themselves.
   On Twitter, I just unfollow people who I don’t feel like listening to every day, and trust others to RT things that are good (I can always re-follow later). They don’t get told, and generally it’s not considered offensive. Conversely unfriending someone on Facebook is equivalent to saying you never want to speak to them again – it was literally easier just to close my entire Facebook account than to deal with it any other way. Sure you can create a Facebook group, but since groups are visible to all, creating one called ‘People I like in person but who are kind of annoying online’ isn’t going to avoid the problem.

So I went with Twitter because it basically sidesteps all these issues by being public (lack of ‘pretend’ privacy leaves no-one under any illusions about appropriateness), asymmetrical (I can follow someone without them following me and vice versa), and easily managed / filtered without offence. I largely had given up on a ‘rich’ social network that worked the way I wanted, because everyone else seemed to swear by Facebook’s way, which I hated.

Then, last week Google came out with Google+, their latest answer to the problem. Invitations are hard to come by, they’re still in limited testing, but I managed to sneak in before they closed a loophole, ironically via friends on Twitter. I didn’t expect to like it – I expected another Facebook – but I was wrong. Key to what makes Google+ different is that it doesn’t use the concept of ‘Friend’, but instead uses a core concept of ‘Circles’. Google have done what Facebook have refused to do, and have recognised that relationships aren’t binary, aren’t always symmetrical, and are all different. Circles can be used to filter the things that you post into groups of people who can see it, but just as importantly to filter incoming posts too. Most importantly, the person can’t see what Circle you’ve put them in! So if you like the person in real life, but find their online posts a bit vapid, you can put them in a circle that you don’t have to read as often, and they don’t have to know. No-one has to get offended, and you get to keep your stream sane. Perfect.

So far, I like it – it’s taken the best bits of Twitter (control without offence) and Facebook (rich media platform) and slapped them together. Of course, there’s the question of whether people wedded to Facebook will switch or not, although for me that’s a moot point since I already ditched it, so any people on it that do come across to G+ are a bonus, but I lose nothing if they don’t. Twitter users seem to be quite eager to adopt it, probably because they’re natural early-adopters and appreciate the Twitter-like circle setup for the same reasons I do.

And it’s for that reason that I think Twitter has most to fear from Google+. Facebook will probably trundle on with all the people who don’t particularly care about managing their streams in an optimal way and don’t feel a need to switch. Twitter though is used by a lot of people (like me) who are a lot more picky about this sort of thing, and those are exactly the people for whom Google+ will resonate the most. Right now, the main limiting factor is that there are no native tools for Google+, and using it on a phone or iPad is still a bit clunky compared to the kind of optimised native tools you can use for Twitter. But that’s coming I’m sure.

I haven’t even talked about the group video chat, or the really nice photo viewer, how Google+ notifications appear when you’re on any Google site (search, GMail, Reader – a huge advantage for adoption), or how they’re iterating really fast on this. In all, I think it has great promise to be a social network that doesn’t annoy me – yet. One of the big challenges as they develop will be how they handle bot-posting from the inevitable games and other applications once the API is released (I hate it when people hook up everything under the sun to auto-post to social networks, and I unfollow them on Twitter even if they’re friends). We’ll see.

A common requirement in any Cocoa application is a preference pane style window where each toolbar item switches to a different view in the main window, resizing as necessary. I’ve used BWToolkit to do this in the past, which provides BWSelectableToolbar. However, there are a few issues with using BWToolkit:

1. If you want to deploy on the Mac App Store, You have to customise it to remove all uses of private methods, since those are banned on the App Store.
2. It sometimes crashes Interface Builder – usually not fatally but it can get awkward
3. Sometimes it gets the window height slightly too tall when switching panes – I’ve patched it to try to cope with this but it still happens sometimes
4. It relies on using IB plugins. XCode 4 does not support IB plugins anymore – although you can still build the code, you can’t edit the nibs anymore

I’ve just been coping with 1, 2 & 3 so far, but 4 was the killer which made me come up with my own alternative: SSSelectableToolbar.

With SSSelectableToolbar, you can still do the preference pane setup entirely within Interface Builder, but it doesn’t require any plugins. There are a couple of extra steps required because of this, but they’re not onerous and still better than setting it all up in code.

The license is permissive MIT, usage is in the README, and there’s an example demo to show how it works. I hope it’s useful to someone else too.

These days I’m a free agent, and I’m lucky enough to be able to choose what projects I work on, but in a past life, I was what I suppose is properly referred to as an ‘enterprise software developer’. Yes, I once functioned in an environment where terms like ‘mission-critical’, ‘project life-cycle’, ‘stakeholders’ and ‘change management’ came up quite a lot. I’m grateful for the experience I gained over 12 years of doing that, but I’m also very glad to be free of it now.

One term which was bandied around a lot in this environment was ‘software engineering‘. The implication of this term, and the expectation of many people using it, is that designing and creating software is very much like physical engineering disciplines, such as erecting a bridge or building a block of flats. When a software project starts to go off the rails, and fingers are starting to be pointed, a common question is why large physical engineering projects can come in on time an budget, when most software projects beyond a certain size don’t? Surely if the people who create software claim to be ‘engineers’, they should be able to adhere to the same standards of other engineering professions?

At face value it sounds like a fair argument, and I’ll be the first one to admit that software engineers are very often not as rigorous as others bearing the title. But there’s a good reason – the belief that software projects are akin to building bridges is completely misplaced, and it is a belief which too often leads people to think that software projects should be run using techniques such as fixed prices, up-front design, and waterfall life-cycles. This is despite decades of case studies indicating that such techniques rarely work, and are more often a collective delusion adopted because the reality – that you’re never going to be able to predict a large software project accurately up-front – is too terrifying to be contemplated. The term ‘software engineering’, while indicating some of the responsibilities of such a person, is an incomplete definition of what building software actually entails, and just reinforces these misconceptions.

So, why is making software so different to building a bridge?

1. Software is intangible.
   You can see and touch a bridge, it has a physical presence you can measure and its purpose is absolutely obvious to any observer, as are its success and failure conditions (getting people across a gap without falling down). Even though there are parts of the bridge the user will never see, their purpose can be easily unambiguously defined – carrying utility cables/pipes, providing maintenance access, etc. Software is intangible, and even the part that is seen by those defining its purpose is often hard to evaluate until it can be seen and used directly, never mind the internal working processes. Evaluating and defining software ahead of time is like trying to describe a dream seen through a keyhole – incomplete and everyone has a slightly different impression, and regardless of how much you try to write it down, you can’t capture or communicate its essence completely to others, or guarantee that they interpreted it the same way.
   People are just naturally very bad at defining and evaluating intangible things. There’s no point pretending they can with 300-page requirements documents, you’re just wasting everyone’s time – accept that people won’t know what they like until they can play with it – iterate!
2. Interaction complexity
   There’s only a small number of ways to use a bridge, and they’re each quite straight forward. Yes, there’s much complexity to the structure of the bridge itself, but that really doesn’t matter to a person driving or walking across it – that doesn’t need input or feedback from people except for whether they like the look of it.
   Software is basically defined by complex interaction, which is often context- and data-sensitive. The number of variations mean that even if every one is bug free (yeah, right), there’s the question of whether it’s solving the correct problem, which is a function of people and their interpretation / opinion. While building projects can be complex, those complexities are most often a function of the engineering challenge, whilst most complexity in a software project is a function of the involvement of people, which are far more difficult to pin down.
3. Change is a constant factor
   Change happens everywhere of course – maybe the bridge builder discovers that the ground isn’t as firm as they thought, or suddenly someone wants to make an extra deck available for trains. Big disruption, and an effect on time and budget – all understandable. The problem when it comes to software is that the perception of change is very different. If suddenly you have to sink massive extra foundations or double the amount of steel you need to use, people understand the magnitude of that intuitively and accept the effect on the schedule. Changes in a software project tend to be perceived as ‘just a little tweak’ by those requesting it, which tends to mean tolerance for schedule impact is lower, and indeed the potential for interaction between changes in unexpected ways is often overlooked. Now, I’m not for a second advocating that change should not be allowed, but often the mechanisms that have been established for managing a project – up-front estimation, fixed feature sets and so on – prevent the efficient integration of change, or at least obscure its impact to a point where things become critical. It’s important to appreciate that change is more common and expected in software projects, by nature of the issues raised in the previous points, and therefore setting your expectations based on a discipline where change is less common is not a smart move.
4. Lack of hard limits
   Building  a bridge involves respecting some hard, unchallengeable limits. As a wise man once said “You canna change the laws of physics, Cap’n!”. When you’re building software, however, there are very rarely any unbreakable limits, and even the soft limits that there are tend to be invalidated very regularly as new technology comes on stream. No-one can realistically stand up and say ‘this is impossible’ when faced with a request, because almost nothing is impossible. Hard limits in physical projects make all stakeholders ‘get real’ – you can’t use more land than you have, you can’t build a skyscraper out of paper, there are non-negotiable rules for safe load-bearing and so on. Barring some really crazy and ground-breaking structures (which BTW, rarely come in on time & budget), these limits ground everyone involved in the project to realistic expectations. In a software project, reining in those feature requests, or those ideas that the implementors have for a new tech they could use, is much more abstract affair, and everything is up for debate.

All these things put together mean that if you think you can use the same kinds of techniques to run a software project as you would use for a building project, you’re kidding yourself. They’re so very different in fundamental ways, it’s like trying to catch a shark with a shrimping net (because it’s just a fish, right?).

So please, stop with these delusions:

1. that estimating the cost of any non-trivial software project (that isn’t just a carbon copy of something else) is any more sophisticated than mildly informed guesswork.
2. that it’s reasonable to think that a fixed-price can be realistic for any software project longer than a couple of weeks
3. that ‘change control’ is the about exceptions, rather than the norm

Of course, agile approaches attack these particular delusions rather well. But try to get those adopted in very large organisations where the ‘software is like a bridge’ mentality still thrives

The SourceTree 1.2 launch sale is now over, and I thought I’d post some indicative results. I went for a fairly large discount of 40% over a full week, and some people I know commented to me along the lines of ‘what about all that money you’ll be losing on each sale?’.

I decided on a large discount because SourceTree 1.2 was a major update that I was actually quite proud of, so I wanted to get it in front of as many people as I could. I was also aware that there might be people who tried SourceTree before, but who decided it wasn’t for them, and I wanted to encourage these people to try it again, since I’d made pretty big strides in this version on the overall appearance of the app and the smoothness of the workflow, in addition to all the normal new features. The way to do this of course is to make it worth their while to do so, by offering a discount that really grabs their attention. A 20% discount probably wasn’t going to do that effectively, but 40%? That’s almost half price! It’s this sort of gut reaction I was looking to promote.

The other thing I was acutely aware of is that you have to be careful not to have too many sales. If you go on sale too often, people are going to start assuming that there’s a sale coming almost any time of year, so will avoid buying unless there’s a sale on. In my opinion, sales need to be infrequent, but big and attention-grabbing when they do happen.

So actually my goal for the sale wasn’t necessarily to make more money than usual, but to get more eyeballs on the new version, and more active users, which I hoped would then translate to more awareness and more sales further down the line, because satisfied customers are the best marketing resources you can ever have. Solid reasoning, but as it turned out, things went much better than I could have hoped, so in the end I actually achieved both at once.

So for those people who were wondering whether having a sale is worth it, my results are on the right, in fashionable infographic form

As I said above, what I was really looking for was to reach more people, and I certainly did that – with a 793% increase in units sold in the sale week, that’s about 2 months’ worth of new users in one week. And as you can see, in value terms it also ended up a considerable net positive even with the 40% discount – now of course I’m expecting sales to be more sluggish immediately following since the sale will have caused people to bring forward their purchase, but I’m pretty confident it’ll remain positive even with that compensating effect.

So why am I writing about this? Am I doing it to strut around flashing my ‘wad’ at people? No, and if I’d included the actual $ values you wouldn’t think that anyway – they’re fantastic news to me but they’re in the ‘I can keep doing this sort of thing for a living!’ range rather than the ‘I can buy a Ferrari tomorrow!’ range I’m writing it to hopefully provide a data point to other developers who, like me, are still learning about selling their wares online, and are wondering about what kind of affect a sale might have. I don’t know whether it will be exactly the same for you, and there are no doubt a number of variables involved, but this was my experience, and I’ve been very happy with it. Maybe it will help someone else pondering a similar decision…

Since I’m trying to spread this news as far and wide as I can, I might as well say it here too

Since the approval light just went green on the Mac App Store, I’m happy to announce the launch of SourceTree 1.2! In celebration, I’m having a crazy-bonkers 40% off sale just for one week, so get it while it’s hot!

There’s loads of things that are new or improved in this release, but here are the headlines:

• Support for GitHub, Bitbucket and Kiln APIs, so you can see your hosted projects inside SourceTree, clone from them, link them as remotes, and even create new projects if you want.
• Streamlined and polished user interface – I specifically dedicated a lot of extra time in this release on making SourceTree easier on the eyes, and to streamline the layout and workflows better.
• Performance - I thought SourceTree was already pretty fast, but I managed to find quite a few more places to trim the fat, and also parallelised more activities to make things feel more responsive. Everything feels snappier, and complex repositories benefit especially.
• New Sidebar - I had previously resisted the need to emulate iTunes here, but once I had implemented it, I had to admit that I was wrong, and in fact this worked great. Provides lots of shortcuts to navigating and operating on branches, tags and remotes.
• Stashing and Shelving - oft requested, now delivered
• Customise Git and Mercurial – you can now use your system Git / Mercurial instead of SourceTree’s standard versions (which have been updated), and enable additional Mercurial extensions (at your own risk).
• French and Japanese translations – local versions for our friends in far away (and not so far away) places, likely to be more to come in future. Big thanks to tuan_kuranes and mzch for their help with these two!
• And the rest – just lots of little refinements too numerous to list. Examples: copying text from the diff panel, ‘git commit –amend’ support, close branches in Mercurial, switch tracking branches in Git

It’s quite a big update – one user remarked to me that they’d normally expect developers to charge an upgrade fee for something like this, but like all other SourceTree updates this is free to existing customers. I have no plans for any paid upgrades for some time yet, I just want to keep making SourceTree better, and hope that more people come onboard. Maybe it’s my open source background, but I like to keep iterating and continually improving things, based on what I want to do (I’m a daily SourceTree user myself), and on what people tell me they’d like to see. SourceTree 1.2 certainly won’t be the last update by far

When I look back 6 months at SourceTree 1.0, it’s incredible how much better it is as a product now, both visually and functionally. I’ve learned a ton of things while I’ve been developing it, and I continue to learn more all the time, and I can’t think of anything I’d rather be doing right now. Also, my wife Marie re-designed many of the icons for 1.2 (and I think you’ll agree they’re a lot nicer) – that was fun to do as a joint project, even if I am a picky ‘customer’

I hope you enjoy the new release!