Build or Buy: Software is still Business

Although for some of you this may seem like an obvious topic, apparently for a lot of people, developers and non-developers alike, this is not so obvious. Today we want to look at how the business of building software is impacted by the possibility of buying third party code to include in a product.

Software business basics
So how do software companies make a living in the first place? Of course there are all kinds of software companies, but we'll focus on the ones making products and selling them to customers, because there is a lot of misunderstanding as to how this all works.

Business wise a software product starts it's life with a first release, which adds value for it's users in some way, making them willing to pay some money to use it. The money payed by the users for the first release pays for the development costs of that release and hopefully makes a bit of money on top of that as a profit.

But the life of a software product doesn't end there. As people start using the software, bugs are discovered and new features are wanted. And as time goes by, technology changes. All this causes changes to the software, part maintenance, part newly build features. Obviously these changes also cost money. That's why most software companies either charge for updates or have some form of a subscription fee or maintenance fee.

Obviously there are other models for making money from software, but what I described above is the classic model, which compares to other businesses.

Why buy?
So why should you buy some of your code? Well, although software development has come a long way, we still have a lot of work that is not directly related to the software products we are building. Let's take an average Line Of Business (LOB) application for example. Changes are you'll need forms that take input and check if that input meets certain requirements. If the input doesn't meet the requirements you'll need to tell the user what's wrong. Sounds familiar, right? So why would you build it yourself? All that will do is cost you a lot of time and effectively a lot of money, while buying a set of controls for your platform is likely a much faster and cheaper option.

So why not choose open source?
That's actually a good question. Let's examine a common software company that uses the classic business model described earlier. A company like that most likely has a release schedule and a support desk. Now let's try and fit some open source control set into the mix. You've used it in some release and now you get some support calls. It turns out there is some problem with an open source control you've used. Now, all of a sudden, you need to dive into this code so you can get that bug fixed. There is usually no support or support is for a considerable fee. And there is no way to guarantee support times for these third party controls.

Downsides
So are there any downsides to this deal? Well, there are some, but they can be overcome. First there is the reduced amount of control on whatever code is bought. You don't do the maintenance, nor do you add any features yourself. However, you can steer this by making proper use of support channels and participating in feature requests.

And then there is something particularly hard for startups, cash. You do need immediate cash to pay for the license. But think about how much time it would take you to build this stuff yourself and how much money you'd need to live off of and how much time it would take away from you building your company. I think it's the best investment you can make in a startup.

So why do people refuse to buy?
Well, one of the most important reasons for developers to go against this is the all famous Not-Invented-Here syndrome. No developer in his or her right mind would actually admit it, but quite a few developers suffer from this syndrome. They'll come up with all kinds of lame excuses for not buying the code, including all kinds of 'What-If-In-The-Future' scenarios that, if you're honest, don't make any sense.
It doesn't usually come form bad intensions, though. One possible cause is that developers are proud of their work and their skills. They'd love to be able to say that they build that cool feature that comes with the source you intend to buy. Another possible cause is that they think they can actually build it better. Trust me, they can't. The simple reason is wide spread usage of the code you can buy. It's probably been used by considerably more developers than you have in your company, so it's been tested more rigorously then any code you could produce.

When not to buy
So why don't all sofware companies just buy everything and slap the code together? Well, first of all if all software companies did that, there would be no more code to buy. But seriously, every software company has a core business, something that makes their product unique and different from their competitors. Once code touches the core business you should always build the code yourself. This way you create focus in the company and you create a specialty in your core business, instead of an all round product that does only so-so on filling the needs of your customers.

Conclusion
So should you build or buy? If it does not directly touch your core business and if you can justify the costs, yes you should.

Adventures while building a Silverlight Enterprise application part #31

Today we want to look at an example I ran into where taking the time to think of good names for everything in your code can save the day.

First I'd like to explain my long absence. The last months of 2009 where obviously very busy for us, but besides that I've been moving to another house (sort of) and I've had a week off to finally have a bit of a rest. But on to more important things.

The story
For our new application I was working on some authorization logic in the service layer. We have a class that represents a user. I was implementing a method called IsUserAuthorized. When writing the virtual version of this in the base class, so all other business objects would be able to implement this behavior, I was thinking "I need to have the Guid identifying the user that should be authorized" and I named that parameter userId. Makes sense, right?

The problem
As I was implementing this method in the User class I simply used IntelliSense to generate the method stub for me and I started writing code. This is part of what I came up with at first:

var authorisations = from item in context.UserGroupAuthorisation
where context.UserGroupAuthorisation.Any(
i => i.Group.GroupId == item.Group.GroupId && i.Users.UserId == userId)
&& item.Users.UserId == this.UserId
select item;

It might seem a bit complex, but let me explain. What I'm doing here is, Because a user is a member of a group that user can also see other users in that group. So the determine if a user can see the user at hand I need to know what groups the user is a member of and see if any of these groups overlap with the groups of the user at hand. Basically, if the above query returns anything the user is allowed to request this user.

The solution
Now, from both the code and the explanation, you can see that it gets confusing, because we have two users in this story, who fill in different roles in this story. I was reading back my code to determine if I had done this the right way and I couldn't really grasp it. A simple tweak made a world of difference. Look at the revised code:

var authorisations = from item in context.UserGroupAuthorisation
where context.UserGroupAuthorisation.Any(
i => i.Group.GroupId == item.Group.GroupId && i.Users.UserId == requestingUserId)
&& item.Users.UserId == this.UserId
select item;

As you can see I renamed the parameter userId to requestingUserId. This has a more then expected impact on the readability of this code. Now you can see that our Lambda expression gets all the group authorizations for the requesting user and links them to the group authorizations in the query. Then all that is needed is to take only the authorizations for the user at hand, explicitly called by this.UserId so it's completely different from the parameter requestingUserId.

The conclusion
As you can see from the above example, having decent names, even for something small as a method parameter, can make all the difference when it comes to understanding code. May we all come up with better names!