Since creating TweetSharp, I’ve had the opportunity to speak with a lot of folks who are using it to build their Twitter projects, which is great to hear. Most developers feel that a) the current state of the union for Twitter clients like Seesmic Desktop and Twhirl, TweetDeck and hootsuite, blu and Witty, just doesn’t do “all of the things I’d want a Twitter client to do”. And this is fair criticism, since client developers can’t possibly anticipate every use for Twitter, and new uses are emerging all the time.

The most common use for TweetSharp has been to accelerate the development of Twitter clients, which makes sense considering that is exactly why it was written in the first place. It is the API running the show behind the scenes of our own client. After working hard over the last while on our next-generation Twitter client, and watching the community conversations about taking things to the next level, we’ve realized: Twitter clients don’t matter, applications do. Here’s why:

• Too many choices. I have a pet prediction that there will be around thirty choices of Twitter client around the summer of 2009. I know of several development teams working under a veil on their version of client revolution, myself and @jdiller included, that plan to launch this summer. This is great for users, the more options the better, but usually when faced with overwhelming alternatives, people stick with the default. That means more TweetDeck users, and more developers with superior offerings left scratching their heads.

• Lack of diversity. The next evolution of Twitter clients will ultimately need to make journeys into extensibility; it just makes sense. Features like groups that persist across devices, interchanging multi-column and condensed views, slick UX, offline support, are not innovations when every developer who builds a client knows those features are necessary and are part and parcel of good software: this is the minimum bar. That means having a client that can load plugins to extend features, and possibly opening up that plugin model for others to build on top of your client, are going to be part of just about every competitive Twitter client going. TweetDeck will bring these features in if they aren’t working on them already. That means more TweetDeck users, and more developers with superior offerings left scratching their heads.
• The sunset of “features-as-applications” . Once the vast host of Twitter clients converge on the same basic set of features and offer a decent extensibility model, the game will change to swallowing up all of the applications that have managed to attract a following simply because they fulfill one missing feature of Twitter’s default offering. Want to know who’s stopped following you? That’s Qwitter. Want to broadcast tweets at certain times to pre-defined groups? That’s TweetLater. And the list goes on, but all of these applications are not true applications, they’re just features. Features are not a good reason to build a business. The Twitter client army will devour these features as either native functions of the client itself, or bring them in piecemeal as plugins.

What’s left are applications in the true sense of the word: unique software that solves a particular need, whether broad or niche. This category is as wide open as innovation itself. You’ve always had the option of doing something remarkable.

Want to know how to get users to switch from TweetDeck to your client? Build an application worth switching clients for, then offer it exclusively from within yours. All things being equal–and they will be sooner than you think–nobody is loyal to their Twitter client.

Whatever is unique about this video-sharing application compared to all the others, then, is the element we can design and layer on top of the framework. That is the element that we find interesting, that teammates are passionate about, and that the Internet population will find exciting (we hope). The more we are able to focus on this element, the more enjoyable the process will be. It is also a matter of necessity: any application that does nothing more than re-iterate the acceptable interactions in a social domain adds nothing to the conversation, and is ultimately forgettable. Thinking that you can “just add blogs and tags” is not going to take you very far.

The crux of a social application is interaction. If social software had a paradigm to follow it might be called Interaction Driven Design. In “Designing for the Social Web“, Joshua Porter calls this the AOF pattern, or Activities, Objects, and Features. We’re designing for the need for your application to arrange itself so that it is evident what a user does, and what benefit they get from doing so.

The application you build is merely the implementation details of taking a description of a problem domain, and how it is allowed to interact with itself and other domains, and coupling it with a description of how its users may interact with each other. The more we can describe about those interactions up front, the less code we need to write. It is fortunate, then, that we already know much about the social domain, and it enjoys a healthy amount of overlap between the typical objects that we might find in a social application: people + messages + media. Are there any social objects that don’t fit one of these categories, and are the contracts between these categories not well-defined?

This blog was formed to explore and define the social domain, that which you can separate from your “secret sauce” and is the most likely candidate for abstraction. The principle we want to follow is that choosing to build social software in .NET should mean that we get to move from a great software idea to an implementation that already possesses the social domain, so that the harder work of creating your own interactions, the ones that make your application unique, is both more apparent and has common ground to relate with.

Whether we like it or not, all great software is built slowly. If it’s also true that a software project is completed quickly, that’s a bonus. Nothing in your project that was built fast works well. If it does, it’s because it was built on the foundations of something slow. Trace back through the underpinnings of any successful software venture and you will see evidence of slowness.

‘Not invented here’ is a good thing

Dwayne Spradlin wrote “Open Innovation: Your On-Ramp to Creating a Better Product” about the beneficial role outside help can bring to a company and its offerings. In it, Dwayne remarks:

…open innovation is helping companies to
succeed because it is reaching a larger audience
of people and allowing people with outside
perspectives to apply their expertise to solving
a problem.

You already embrace open innovation when you recognize that you need outside help to achieve your goals, and one obvious manifestation of that is the use of open source. Whether you admit it or not, plenty of folks with outside perspectives on how you end up building your software are engaged throughout the course of your product, whether you decide those folks are paid through a vendor licensing arrangement or unpaid as contributors to open source efforts. If you are using the latter, you might want to think about giving back to that community.

On oil barons

Thom Hartmann, in “Last Hours of Ancient Sunlight“, coined the term stored sunlight to refer to oil and the natural, concentrated energy within it. Just as Thom warned about the dangers of exploiting this readily available resource rather than sacrifice productivity in the name of renewable energy, an open source project is the stored energy of minds working on a problem indirectly but vitally important to the health of your product or service.

You can still create a good product quickly, but that speed is not a symptom of effort, of scope constraints or gross efficiency. Speed is the by-product of tapping the slowness of quality components, like sweet crude, underneath your project. It is the considered and deliberate pace of proprietary or open source projects that solve the problems that come up again and again when you engineer software.

Software development is hard, it’s going to be hard tomorrow.

What happens when we take energy from the earth without giving it back? We run out. That same principle has to be true for open source projects that we rely on daily to create value, and profit from it. Open source, and open innovation, can be renewable energy sources for your business, and at greater capacities than are possible today, but you need to plant the seed.

Start sharing

The amount of code duplication present within even one organization, especially one structured as a consulting practice, where contracts are typically forged as work-for-hire (when all intellectual property claims to the produced work transfer from the provider to the buyer, exclusively), is needless waste. You don’t need to start at square for one every project you undertake, and it only invites defect déjà vu and an inability to share knowledge across teams. If this is you, then this a good place to start before moving forward. If you do have a reasonable about of sharing across your delivery teams, then you can start thinking about how effective this has been for you, and how you can extend that circle of sharing into a bigger picture that guarantees you’re getting the best talent for the best price: open source. That’s right, financially supporting open source efforts means the best developers in the world are working on your software.

Where and what great developers want to work, and work on

Wherever they want, and whatever they want. That goes without saying, and it’s actually to your advantage. Discounting the obvious wins in energy consumption overhead, the fact that the best developers in the business are focused and dedicated to one or another specific challenge in software design means that they will find better answers, and faster, to the problems they champion. No matter how talented your development team is, they cannot afford to focus on these often subtle and difficult problems, and still deliver your project on time. It’s not in the budget. Open source developers with funding are happy developers. They get to create the massive value that they see in their mind and turn into functional software. You get to use it.

The reality of innovation

There is very little in the way of real innovation in software development at the product, services, and delivery level. Chances are, if you are a services company, you aren’t interested in building a fully-featured object-relational mapping solution within your company, but you are interested in using one, as it’s a staple in your own developers’ mission to build your next data-driven solution. So you’ll likely perform some due diligence and in the end, buy something off the shelf or use an existing open source project to get the job done. You aren’t making any progress here in terms of technical ability, you’re making an investment in someone else’s effort, using it as is, and hoping your team can bridge any gaps there might be in implementation.

Identify the open source projects that are important to your organization

Your developers can help this process immensely because they already know, and will tell you, “what hurts” in their current development process. If you can match that pain to projects that stand a good chance of removing that pain, then you’re on the right track.

You likely can’t afford the services of someone like Ayende on a regular basis, but you certainly need his talent and vision, if you’re not already making use of it, whether on purpose or by accident. If you’re willing to admit that what makes your brand successful is not the constant, painful reinvention of a hundred wheels, but in the quality, personality, and depth of the services you provide for your clients, then you can see the value that a vibrant, active, and well-funded open source effort is going to have on the details of realizing your vision.

The big idea

It’s actually a small idea. Companies will win the best talent in the world if they “hire” that talent as a collective. Imagine providing one developer’s salary worth of open source investments in projects that will directly benefit your teams so that they can do their jobs better, faster, and in big way. If only a few companies followed this lead, then the most promising efforts in data persistence, web services, search, and anything else important to your company, could come to light much faster, as the developers working on them would be able to dedicate their days to solving and growing those spaces in earnest.

It is cheaper in the long run to fund interesting projects that deliver bottom-line productivity to your team, whether that’s today or in the near future, than it is to swell your ranks with more developers to run up against the same challenges, project after project, day after day.

The debate

Open source was never truly free, as many companies cite support as the primary reason for hesitancy to adopt an open source effort despite what that software might do for them. So, rather than go open source, a company will buy a product where there is some commitment to support it (and if you’ve gone this route before, that support is never guaranteed to be of the expected quality). Yet investing in open source breathes life into a group of developers who want nothing more than to create that software for you; incidentally, Ayende is raising funds to build LINQ to NHibernate.

The only differences between where you place your investment in software is that funding open source means empowering the creation of the software you actually need, buying software is the act of getting close, and then hoping you can make enough noise to get your real needs addressed, and hiring developers is hoping you’ve rounded up enough intellectual capital to solve the problem in-house while still meeting deadlines. If a retail software product closes shop, you’re left with a frozen project; if an open source project loses steam, you can fork it, or bring it in-house.

And no, funding open source does not mean funding your competitors. You already know you do not differentiate yourself in the marketplace based on how well you persist business objects (and if you do, likely you’re not investing in that particular strain of open source). The point is to “outsource” the technical tasks that are not the intellectual property of your delivery to the best developers in the world (or at least the most passionate, if you’re splitting hairs) at those tasks, where the number of companies that take a similar approach drives the cost of that “outsourcing” down.

Getting it done

Web sites like fundable.org make these transactions transparent and goal-oriented; a project only gets funded if there is enough demand, and you may even be able to direct your funds to the specific features and enhancements you need most in your organization. Naturally, if enough companies decided to take this route, we’d end up with a custom web site designed to bring open source and its benefactors together in one place.

Just imagine if even one developer salary per company was invested in open source technology. Certainly that salary would contribute more to your company’s ability to produce great work across your whole organization than one more hand on deck.

While it might be obvious to most, we can start by making a distinction between three terms that more or less overlap in every conversation about building a modern web application where there is a entrepreneurial and social spirit behind the scenes.

Web 2.0

The concept of Web 2.0 (October 2004 – October 2008) from a technology viewpoint is the implementation of, and aesthetic, of a way of viewing the web. This means different things to different people, but during this time we witnessed the movement from taxonomy to folksonomy, syndication of content, wholesale adoption of services, user-generated content, and a softer and responsive user experience.

If there are any features that are decidedly Web 2.0, then they are blogs and feeds and tagging; while they are often described alongside social networking and often bundled within any number of startups, these features sit in their own category.

Social networking

The heart of social networking is the social graph, often simplified to a single, symmetric relationship known as “friend”. Through a web application’s ability to define relationships, it is able to implement features which are often referred to as interactions. By querying and predicting on the results of many interactions between users who are related in some way, the value of the social network rises to the surface. Social networking is one way to realize one of the promises of Web 2.0: that the more active the web application, the more valuable it is to its users. Contrast this to many disconnected applications on the desktop. These kinds of applications are meant to serve a different paradigm: they are useful the first time they are used. This is why most business models for web applications rely on “aggregating eyeballs“.

Web applications can be social without being social networking applications, in this case it is literally engaging the network that makes all the difference. Are blogs, feeds, and tagging social networking features? No. What about user account management, profiles, chat, and search? No. Social networking features are anything you devise that leverages the social graph. A social networking site that links coffee aficionados together to make recommendations about the best beans, and the best brewing techniques might use tagging to distinguish bean varieties, but the real feature in this case is the recommendation engine that looks at what people like to drink, and suggests what else they might love. The real feature is the coffee drinking reputation which organizes into a natural, hierarchical relationship between the experts, and the enthusiasts.

Startup

As mentioned previously, a startup is a new venture. In our world, it’s on the web, and because it is on the web it will seek to use features like those mentioned above, to create value and ultimately convert that value into income.

Social networking is a process, not a product

One important take-away from these distinctions is that on top of being a social networking application (if it is), your startup is ultimately just a web application, and that means you need to address all of the same issues that any application would, you just might experience the pain sooner and in larger amounts, because as social software, your application is public-facing, and designed to be used often.

There’s no secret sauce for a social networking site, there is only the sound implementation of features, any features, that support and encourage interactions on a social graph. Building a social platform is exactly like developing any web platform, to the point where it doesn’t really deserve its own name, but you can call it social when you’ve thought about how to bring features together (such as an asynchronous, predictive fetch for ‘mashup’ data) in a way that makes it easier to build social sites.  You can call it social when you’ve thought about how it’s going to perform with a million people performing hundreds of actions a day.

Features, ultimately, are not overly complex, though they become challenging when they need to scale. They can be designed with sound principles, with a mind to reusability, and the end result with such a ’social platform’ should be a way to build many social applications with the same code base, and to make the process easy to repeat.

The only aspect that truly matters is how you define and create a valuable service for users by leveraging, through interactions, the social graph, without getting mired in the details of the features. Social software is a much larger animal than social networking.

One myth about startups is that they take a lot of people to create. The opposite is closer to the truth. You need a small number of talented people to keep the noise down, to avoid dilution, and to solve the hard problem of making something simple.

On the web you need someone with peerless graphic design sensitivities, one great developer, and possibly someone leading you and the idea. This can be three people, two people that can finish each other’s sentences, or one uncommon individual with great tools, to help make switching hats easy.

2. You must launch it with almost no money

We are living in the golden age of small startups. Investors still exist, and investors still have money, but it’s probably better for you in the long run, especially with a small team, to avoid them altogether. The startup that works without money, keeps the money they make. The startup without money, that makes no money, loses only time (and the less time the better).

3. The least important part of your startup must be the technology; organize accordingly

When asked to described your startup in one sentence, “it has dynamic drag and drop modules” is not an answer. A startup’s execution is everything, it’s true, but only on an idea, not on itself; executing on itself is just execution.

4. The technology you choose must be easy, or half of your job must be helping to get it there

You need to be able to go from idea to working application in almost no time. You’re in a hurry. You’re in a hurry because you need to kill your startup today, right now, if the idea behind it turns out to be uninteresting, not useful, not something you really believe in.

You’re in a hurry because you always have more ideas than time. The less time it takes the more ideas you can try out. What you can’t do is waste your time getting the technology to behave, then dance, and then sing. If you’re already great at a technology that dances, teach it how to sing so you’re that much faster on your next idea.

5. Stop being one

A startup is a company that its owner intends to sell; in the game it’s called a liquidity event, which is when your company disintegrates like gum that’s been chewed too long, and it repurposes itself into a company that is meant to grow fast, provide a return on investment, and receive leadership from a board of directors.

All this means is that if, at the end of you describing your project to a stranger you don’t end with “and then we get acquired”, then you’re probably not a startup. This isn’t a bad thing, it’s actually great news, because now you know that you aren’t a fit for investors, and they aren’t a fit for you. In other words, you aren’t building your startup for them, it’s for you, and it’s for your users. Go ahead and build your startup, solve a problem, and see what sticks.

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.

Everybody Googles. There, I said it.

There are too many frameworks, and too many technologies for it to be a responsible decision to attempt to memorize them all. We refer to the web constantly when learning new technologies or pushing through insipid bugs. I’d even go so far to say that this is a desirable characteristic of a developer: someone who knows where to get information when they don’t know the answer, or when the path to a solution is vague. Of course, you need filters to safely learn from the web, or you might pick up bad habits, erroneous code, or unknowingly breach licenses in your pursuit of knowledge (or laziness). Risks like these lead some to embrace technical books. Some say technical books are dead or dying.

What is a technical book?

A technical book is not:

1. a fundamental work of guidance, like Code Complete or Framework Design Guidelines
2. a patterns and practices collection like Head First Design Patterns that is fairly technology agnostic

A technical book is:

1. an API reference that is specific to a particular technology or framework, and even more so if it is versioned
2. a patterns and practices collection that is specific to one or many implementations

Don’t write a technical book

When I was negotiating a book contract with my favorite publisher earlier this year, many people told me not to write a book, so much so that I decided not to write it. There are quite a few blogs on the subject. Here’s a reading list:

1. Do Not Buy This Book (Coding Horror)
2. Programming Book Profits (John Resig)
3. Hard Work, No Pay: What’s the Point? (Charles Petzold)

I don’t believe that these posts about the perils of writing a technical book are meant to protect the status quo for a small elite of successful authors. I do believe that these are real warnings from impassioned people who wanted to contribute to the community in book form (and make money) and emerged battered, or at least wise, by the experience. It seems the story of writing a book is a sad affair.

Write a technical book

There can be physical differences, of course, between books and blogs. The differences might provide ancillary advantages like portability or aesthetics, but those aren’t the advantages of books over blogs that are going to win anyone over. They’re built-in, and if they were real advantages, then nobody would be worried. But we have e-books. And audiobooks. And podcasts. And Kindle.

The value of a technical book, and the advantage it has over blogs, and the advantage it has that can help it continue to thrive despite the alternatives is, to me, identical to the value of any book on any shelf:

I buy a technical book for the story.

A story is complete (it has a beginning, a middle, and an end). A story treats the material like a complete whole, and it has context. While a blog offers schizophrenic, just-in-time information to help me tell my own story somewhere else, a book is, or should be, a story about me, using the technology, encountering challenges, overcoming them, and emerging the hero. That is, after all, the story I and every developer I know faces on a daily basis. Hero mileage may vary. [Update] I don’t mean to say that a technical book should contain an actual narrative, only that it provide context and that the source material paints a complete picture (for example, a reference application).

Bill Wagner’s Effective C# (and More Effective C# which is in early access), is the prototypical example of a great technical book. The story of this book is the one about how you decided to really dig in to your career as a developer and master C# by applying sound practices that are grounded in how the C# compiler actually generates the MSIL bytecode that becomes your application. I love this story, and turn to it often to remind myself that bytecode is the linchpin of quality programming. It never lies.

Ideas for improving technical books

1. Tell a story
   A good story is a reference application: some semi-real world application of the story that is believable. It looks and feels and like an application I could be asked to write tomorrow. Even better, involve me in the story by providing some reusable hooks into the design that let me actually use the source code in my application. Provide a Visual Studio template that sets up any practices or patterns you’re recommending in the book.
2. Make my technical book a subscription
   I know that technology and approaches change often, so why doesn’t my technical book? If the book is titled along the lines of "Building Flexible Service Layers with WCF", I know that the book is an API reference, but I don’t know what version of WCF, or whether today it is useful to use yesterday’s pattern. This is especially true for emerging platforms like Silverlight (anyone still own their Silverlight 1.0 books?) A subscription-based technical book is an on-going investment in the story of accomplishing the book title’s objective. If the story changes, blogs change overnight, but the only part that changes on a static book is the price tag.
3. Involve multiple authors on the same book
   A consequence of the improvement above is that an author will likely move on; just like projects, I don’t imagine anyone would want to write an objective-based subscription book for years. Less politely, as developers advance their careers they take leadership roles, become less involved in the intricacies of the current technology (this is often necessary), become more involved with their families (this is a good thing) and may broaden their perspective. This is not always the case, but a technical book, especially one living through multiple versions like the previous example, would benefit from fresh eyes, ears, and laser focus.
4. Version the book (code and pages)
   Technical books are usually about code, and code is versioned. Let me visit your web site (or my book subscription) today, and download an on-demand generated PDF, or order a fairly priced print-on-demand solution that lets me get today’s version today. If I want to "Build Flexible Service Layers with WCF", presuming that WCF lasts several versions, I would love to order up this objective in the version my project uses. If I have multiple projects that use different versions, I know my subscription covers PDF access to all of them. Errata is inevitable, but it is manageable if my subscription covers online code access to the book’s source code repository. You could even let me submit a patch.

Bloggers and technical book authors can live in harmony knowing they both fill a need. A lot of the times they are the same person, but they do not have to be. Writing a book requires a sense of style and rigor that you simply don’t need to write a successful technical blog (though it helps). Here is a good blog post on one author’s experience.

I’m on your technical blog because I am writing a story, the story of my work day, and I’ve got writer’s block. I need just-in-time information that’s relevant and current. I don’t want to skim through your archives, and it’s quite possible that I won’t be back (unless I keep landing on your blog during my research, in which case you get tossed into my feed reader).

Technical books aren’t dead, but good ones are harder to find. A few changes to how technical books are read and shared will make them more accessible and may even encourage more sales from developers hungry for good stories.

There seems to be a well-deserved observation that very few web startups are making use of ASP.NET, choosing instead to leverage more open platforms like LAMP, and ROR. As a web developer who has launched a startup in ASP.NET, I have to admit that there is some truth to the difficulties presented in the discussions that exist online (here are three examples), and as an ASP.NET startup developer, I’ll offer five recommendations for you if you plan on going this route, not based on simple personal preference (I disobeyed many of these to the detriment of my sanity, pocketbook, and project lifecycle) but out of my desire for you to succeed without needing to overcome the same obstacles that I did.

For a bit of context, my startup took ten months to complete from concept to completion, which, in this world of "Getting Real" and "Getting Things Done", is nothing short of a death march. A one man death march should be impossible, one of my colleagues pointed out to me (he also founded an ASP.NET web startup, but followed most of these pointers and is doing great). So, here are my recommendations for the would-be startup founder flying the blue monster flag:

1. Do use ASP.NET MVC (or at least learn the web like everybody else)

Don’t deal with ViewState, don’t deal with leaky abstractions of the web in a way that confounds you. You’ll thank yourself for writing cleaner code that you can test, and for mastering the deceptively simple art of web development. "It’s all just markup" is a mantra that will keep you on track when you feel overwhelmed with the new model, but it’s a new model you want to learn. If you don’t want to learn ASP.NET MVC, do yourself a favor and disable ViewState at the page level, and do what you can to avoid using it, whether that’s baking your own MVC-like "markup + business objects" design, or embracing the client-centric development model with JavaScript against ASP.NET controls that don’t require ViewState. Make friends with the Repeater.

2. Don’t use large third-party control libraries (they don’t buy you the time you think they do)

I decided to buy a very popular (and expensive) third party control library. My instinct was that, as a single developer working on a web startup by moonlight, I could leverage enterprise-class support and a robust API to make short work of some of the more complex UI tasks. I ended up spending more time trying to ramp up with the documentation and hunting down bugs or my own misuse of the framework than I would have writing my own controls. It may be tempting to believe the third party solution will solve all of your problems, but the key to a startup is to release early and get feedback as soon as possible. Stick with simple controls and markup that you can understand and stay clear of off-the-shelf products if your time is tight (and it is). Remember that many hands built that product, and attempting to master its nuances is no different, to me, than stealing code and trying to reverse-engineer it; both cut out your momentum and take you away from your own ideas. Nobody needs extra dependence. If you have to use a framework, stick with a free one like ExtJs, and use the money on graphic design instead.

3. Do use jQuery (it’s small and does it all)

You simply can’t afford to send 150kb to a user’s browser to buy you basic Javascript UI. This little monster costs you 15kb and it can do everything you can imagine. jQuery in combination with (optimized and combined) ASP.NET AJAX web service proxies is all you need to make calls over the wire and do amazing things on the browser. Any other solution is unwieldy, bloated, and takes too much time, period.

4. Don’t use the UpdatePanel (tough love, but you need it)

Speaking of unwieldy, don’t let this siren succor you into a false sense of ability. The UpdatePanel might be useful for the very isolated case of posting back a large form that needed to be submitted in the first place, but under no circumstances does sending most of a web page to the server and then updating small parts of it on the client constitute a practical or desirable approach to building AJAX sites that aren’t on a corporate intranet with a giant pipe underneath. If you’re a startup you’re likely building a public-facing application that’s intended to be SaaS. If you want that service to be performant, you need to make small client changes either entirely on the client itself, or submitting just what you intend to change through a web service call. Take the time and learn how to do "real" ASP.NET AJAX; that is, build static page methods, WCF services, or script methods, and call those on the client-side via JavaScript. ASP.NET AJAX will take care of the JSON serialization for you so you’re free to return custom objects in your service methods. Anything else is asking for trouble.

5. Do use a graphic designer (A startup has no excuse for poor design)

A "programmer’s aesthetic" is often cited as a suitable excuse for a shoddy design, and if you study the well-established startups that exist in the wild, many of them leave a lot to be desired in this department. Don’t confuse successful-and-ugly with a real decision made somewhere along the line to skimp on design. Those sites are successful for a variety of unrelated reasons, including timing, and if you are similar in any way to one of these existing ventures, you’re going to need to differentiate in more ways than features. Do yourself a favor and at least invest a little money on your logo.

6. Do use an automated entity persistence solution (because you have better things to do)

John S. pointed out that I had missed one of the fundamental pain points when building a web application: entity persistence, or "object-relational mapping". This is the concept of leaning on a reliable, automatic way of moving business objects (tags, people, groups, photos, forums, posts, et al.) to the database and back without having to think about, or write, reams of code to handle it. I ended up using LINQ to SQL for my startup because I had a simple data model (many social networking applications do) that didn’t need multiple table inheritance, or non-PK relationships; otherwise I would recommend an alternative. A lot of agile developers recommend SubSonic (and frankly it looks so darn cool), and you could try NHibernate as well, and there are many other options; the emphasis here is to use one you like, but do use one.