Thoughts on building social software in .NET
Share
Social software is, before anything, just software. Presuming we have a goal of developing a social application in .NET, we can deliver that goal however we wish. That said, there remains a growing number of people who are actively searching for guidance on how to build social networking applications (and their better-dressed cousins, web 2.0 startups) in .NET. I offered some quick suggestions in the past, but they were a little bit-specific.
Choosing .NET
I believe that .NET is both an excellent choice for startups and a strong platform for social software. Where it seems to lack the most is adoption, which is an essential ingredient in attracting active communities that will help support others through tools and conventions, and developers who will create those conventions around which a community can form. Without a community, any tool we’re using to build an application is just code in our bucket; whether we learn to use it effectively and whether it’s even fit to do the job are unknowns that we must solve ourselves.
When someone forms the opinion
“I can’t build a social application in .NET, I should probably use Ruby on Rails“,
to me, this translates into:
“I googled it, and there doesn’t seem to be an active .NET community and no generally accepted practice, that, if I learn it well and follow it, I can build social applications that are higher in quality, readability and turnaround, and lower in defects, ambiguity, and friction”.
David Seruyange offers another interesting possibility, which is the idea that having to pay any amount to develop software (which is admittedly easy to do when you’re using a Microsoft stack) causes psychological pain which results in fewer startups choosing .NET. Of course, there are many alternatives in .NET that are free and open-source.
The power of convention
Ruby on Rails, on the other hand, has a well-marketed, active and passionate community practicing the ‘rails’ convention which on the outset appears like a clear winner. Rather than focus on the technical specifics, we need to consider the act of following a convention in and of itself. The benefits of following a good convention include:
- You get to the point of building what’s specific and unique about your application as quickly as possible
- You can lean on what you already have, so you end up describing more, and coding less (this is the difference between idiomatic and imperative programming)
- What is standard, is standardized
There is nothing stopping anyone from developing compelling social applications in .NET, but there may be hesitation stemming around a lack of options for a good convention to follow. While I have a stake in my own convention, it can be anything that works. With so many social applications emerging that seem to materialize out of thin air, it’s imperative that you can get from your exciting new take on things, to a working application, as quickly as possible. A convention means you don’t have to repeat yourself.
The problem domain
The problem domain, is, essentially, your application. It’s “you can compare your paintball wounds with your friends“, and it’s “allows you to record and store personal recommendations about job-seekers for prospective employers“, and it’s “buy funny hats“. This is the part you’re excited about, that you excel at, and that you’re trying to get in front of people.
The social domain
All social software, before considering how it is delivered (on the web, on a mobile device, on a desktop), already follows a convention, though it is not a technical convention, but rather a social one. An application is generally considered social:
- if it is organized around ‘interactions’ its users perform
- if it co-operates with other social applications, providing existing interactions or combining several to form new ones (often referred to as a mashup)
- if it provides a public API for other social applications to use its own interactions
The social domain is the ‘everything else’ of your application; the people, the messages, and the media, that make up the moving parts. It doesn’t matter if your application lets you tag photos or find the closest restaurant, everything in the social domain can exist in your application, and everyone else’s. It also has a very special relationship with your problem domain, and the easier it is to get the two to get along, the easier your development experience will be.
Getting domain-specific
The path from eliminating repeated tasks, to a social software convention, is through building reusability into the problem and social domains of your application. We can build everything inside the social domain once, and provide one or several domain-specific languages to describe our problem domain and how it relates to the social domain underneath.
This is where you’ll be happy you chose .NET. I’d argue that LINQ, and the C# 3.0 language features that implement it, provides a solid base from which to build domain-specific languages, or rather composable interfaces that let us express clearly what we want to do with our convention-defining code. We can also provide flexible domain-specific scripting capabilities with a .NET alternative language like Boo to make the process of describing “users can tag and rate paintball photos” an architecture-free task.
It is possible to build great social software in .NET, or any capable platform, if there are conventions, supported by communities, from which to drawn from. You can do it in isolation as well, as many successful .NET-based web startups have done (there are many out there, though they may not publicize the fact explicitly).The point is that there is no secret sauce other than good software design, and you don’t need to worry about choosing .NET in fear of some hidden FrameworkNotWorthyException crushing your dreams.
Socialized