Bring It On

The headline of this post is a quote. I last read it in a most-excellent book that I wrote about before called “Founders at work”. In short, the book is about success of the many startups that did something great (some subsequently crumbled) in the last fifteen years or so.

For some reason, this quote really resonated with me. Despite all the information I’ve gathered before I even thought about going at it on my own, I’ve still made many small mistakes that could have been easily avoided. More often than not, I see this pattern repeat itself with other entrepreneurs too. We either get too enchanted by the technology, we misjudge the size of the market or we continue “brushing the diamond” (trying to produce the perfect piece of technology instead of selling something that works).

It’s easy to blame the circumstances. If only one of the partners did or didn’t do something, if only market wasn’t in a slump, if only the exchange rate of your primary currency wasn’t so bad at the moment etc. But more often then not, we are the enemy, we’re the ones who shot ourselves.

Considering how much functionality is in the .NET Framework and how .NET PE files’ metadata is highly compressed, one would expect most .NET applications to be very small.

You can empirically observe this by trying to create a simple “Hello World” in C#: the resulting executable is just 3.5KB (or even smaller with versions prior to 2.0). The size does not increase by much as you continue adding code and reasonably sized (in functionality) .NET applications are just a couple of hundred KB or even less.

Just the other day I checked to see how big the core part of my P2P BitTorrent app was – 160KB. Hm, this doesn’t look right; I keep this library lean in general, it should be smaller.

So I fired up ILDASM (IL DisAsseMbler) and checked the overall statistics (View->Statistics). Here’s the important part:

 File size            : 163840
 PE header size       : 4096 (496 used)   ( 2.50%)
 PE additional info   : 1219              ( 0.74%)
 Num.of PE sections   : 3
 CLR header size      : 72                ( 0.04%)
 CLR meta-data size   : 81268             (49.60%)
 CLR additional info  : 0                 ( 0.00%)
 CLR method headers   : 11081             ( 6.76%)
 Managed code         : 54814             (33.46%)
 Data                 : 8192              ( 5.00%)
 Unaccounted          : 3098              ( 1.89%)

Well, well, well… 50% of the image is actually metadata! Despite heavy metadata “compression” (this is a custom kind of compression) in the .NET Framework, metadata occupies half of the total space, while code takes only 34%. Interesting…

I guess if I obfuscate the image using an IL round-tripping obfuscator that I could get quite a smaller image.

I don’t know who started it first, but now every top blogger is thinking (some are acting already) about providing a job board. I first noticed it when Joel Spolsky did it. In his case, it was only natural – highly focused “blog” like his is read by thousands of developers who pride themselves of being, well, better than the average. Presumably, on a job board where his readers would apply, there will be much higher percentage of good candidates than elsewhere. To balance things, Joel imposed some rules on the job providers too, effectively cutting out the middle man (hiring agencies), trying to make the whole experience good for both sides.

It appears that he, at least financially, succeeded. Based on the numbers for just the first week, the job board earned $40K (the numbers are smaller as the novelty wore off and amount to less than $10K now). That’s a lot of money for something that an intern hacked up with Joel over a few weeks, part time. Naturally, it’s not the site’s technical merits that attract job seekers and providers to Joel’s site but his reputation (and by extension “reputation” of his readership), something he has built up over the years.

Before Joel, I knew of one other company that did this, but in their case it made even more sense – 37signals, the authors of the Ruby On Rails framework, have a job board for RoR jobs – even more targeted than Joel.

The last one I encountered just a few days ago is Guy Kawasaki’s job board. Guy is a cool guy but not a developer – you could say that he is a marketer. His blog is a lot younger, but he worked fiercely to capture as much readership as possible  and appears to have succeeded. His logic is the same - come to my site, my readers demographics are here, my readers are entrepreneurial… He does charge a lot less than Joel though and won’t make a lot of money IMHO. But it may end up paying rent, or something like that, which is not bad at all.

For me these are one of the few completely legitimate business moves enabled by the Web. There’s no hype here and the boards provide a real value, the business model is sound and clean.

If only I had tens of thousands of readers…

Everybody wants to be different. The same is familiar, the same is boring. So we change clothes, put on makeup, cut the hair – whatever is necessary to be different.

In a way, the principle applies to software too – it’s safe but boring to be the same, yet another me-too product. Thus we try to be different, if only a bit, in order to be “special”.

But it’s nevertheless a risk – if your app is too special, it will take a lot of time adjusting too. Some might not even figure out what it is about. We have to be the similar, yet different.

It’s all about the balance. There is no recipe on how to maintain this balance, regardless of countless examples where the balance was bad, just OK or simply perfect. It’s up to you.

Here’s an example where a game developer got things just right while tweaking unbelievably small aspect of the gameplay. I’m talking about the Xbox game Black.

Black is a first person shooter (FPS) and one of the last few to come out for the Xbox (not the 360, the old one). It behaves pretty much like most of the other FPSs out there – conventional weapons, conventional locations, story that does not matter, simple goal (destroy everything and everyone)… The graphics are great, but so were the graphics of many other FPSs out there.

Still, Black is a great game, one of the greatest shooters I’ve played on a PC or a console. What is it that makes it special, besides the fact that it’s made by Criterion Games, the company that has proved to know how to design fun games (they are behind the Burnout arcade racing series)?

If I had to pick one term, it would be – particle effects. The only other exceptional thing is, for the lack of better term, destructability of the environment. So, while you’re fighting hundreds of enemies per level, usually you’ll be firing thousands of bullets that would break wooden planks into shards, shatter glass windows and other glass surfaces, smash wooden palettes, you’ll even be able to destroy weaker walls. The sparks will fly into air when you hit a metallic surface of any kind, the trucks, cars and other flammable objects will burst into flames, destroying everything in their radius.

This game is pure mayhem. There’s nothing else, though – just gunfight after gunfight. But boy is it fun. This is the only game that I’ve been playing for the second time on a harder difficulty level (it does “help” that the game is quite short).

There are other advantages like completely transparent level loading: you’ll never find yourself staring for seconds at “game loading” even though some of the levels are huge. Just as well there are disadvantages like automatic save – the game saves progress, but only at a few hand-picked checkpoints inside a particular level. If you have to abort the game for whatever reason while the level is in progress, next time you’ll start from the beginning of the level (argh!).

But in the end, it’s the particle effects plus destruction of the environment that makes this game special. It’s amazing how this changes the atmosphere and immersion effect so much that it defines the game.

In the previous post I tried to describe as good as I can all the things that make ASP.NET 2.0 great platform, but also all those that make it very irritating and tiresome.

I ended up choosing Ruby on Rails (RoR), but the decision was not nearly as simple. I like Ruby as a language just like many people do – there’s something magic about it that seduces you from the moment you write your first non-trivial script. But the hype surrounding Rails was so strong that I was put off by it. Finally, when I realized that building my site with ASP.NET will most likely become an exercise in frustration I decided to give Ruby on Rails a chance.

Note that unlike ASP.NET, I did not yet build anything serious with RoR. However, looking back at the project I did build with ASP.NET it is quite clear that it would have been almost trivial to build in RoR. To understand “almost” you’ll need to check out the list of what’s good and what’s bad about RoR. First the good stuff:

• RoR is an application framework and not a class framework; this means that there is a certain way you build your apps and especially if you are inexperienced this will help to guide you
• RoR’s MVC (model-view-controller) implementation is very good, especially its ORM (object-relational mapping); ORM is not the most flexible one, but for most of the purposes it works really well – as long as you follow the conventions; ORM supports multiple database backends: MySQL, PostgreSQL, DB2 but also Microsoft SQL Server
• RoR has a concept of conventions over configuration – by following the naming of database columns, classes, modules and methods you can achieve a lot; for those that like flexibility and don’t like rules this is irritating, but for practical folks (this is my opinion) this is great because all your “configuration” information stays embedded in your source code files
• RoR insists on good testing practices; the skeletons for your unit tests are generated along the rest of the generated files and the community around RoR seems to pay just right dose of attention to tests, both unit and functional
• RoR is very practical by supporting three different kinds of development environment, each with its own database – development, production and testing
• RoR has feature parity for most of the features a modern Web framework should have (just like ASP.NET) – things like ASP.NET master pages (they are not called like that but any page that consists of other components is effectively a master page), good caching, session support, AJAX…
• If you do know HTML, writing the pages will be very easy; RoR embeds Ruby in HTML, not unlike ASP (not ASP.NET!) did years ago, but there’s a difference – because RoR is an application framework, you do not end up mixing business logic and presentation code, you just mix code and markup; after thinking about this a lot, especially after my struggle with some of ASP.NET controls while trying to tweak their behavior I think this way is better
• RoR has a strong emphasis on DRY (don’t repeat yourself); if you are experienced, this won’t matter because you’ve already learned the lesson the hard way, but if you are a beginner, this is a very nice habit to adopt
• RoR is constantly developed and if you are inclined to do so, you can “live on the edge” and always run the latest and the greatest code; the release cycle is also faster than for ASP.NET because there are no other products to tie the launch with
• There are several IDEs to choose from, including extensions for the two giants of modern IDEs – Eclipse (RadRails) and Visual Studio 2005 (Ruby in Steel)
• Ruby is a great language that fits the needs of a Web developer very well; speed is not as important here as much as flexibility and expressiveness
• RoR is free, runs on variety of free Web servers (like Apache, lighttpd and Mongrel) and free Operating Systems (practically all popular versions of Linux); it generally a lot cheaper to find a Web hosting deal on Linux with MySQL or PostgreSQL than it is for Windows with IIS and Microsoft SQL Server

Now for the bad stuff. You’ll notice that just like with ASP.NET, both the good and the bad list are just as long. Programming is hard – deal with it . Here we go:

• RoR is hyped beyond belief; some of the screencast will make it seem almost like magic; people will take it for granted that RoR is the magic silver bullet they’ve been waiting for and be very disappointed when it does not fit their needs
• The concept of conventions over configuration works great as long as you can fit your app into the convention – if you can’t, tough luck; example is composite primary keys – can’t do it in RoR without a lot of trouble, RoR likes its keys as a single column named id of type integer and auto-incremented
• If you don’t know HTML, you’re in a tough spot; there is no concept of controls spitting out markup and the IDEs do not have nice designers – you’ll have to build all your markup manually
• RoR is not documented well and there is no alternative to MSDN library; the situation is improving, but for the meantime your best bet is to buy books (that are not free and cost money)
• When I said “my app was almost trivial to build in RoR”, the missing feature I was referring to was i18n (internationalization); this is actually a problem with Ruby itself, not RoR, but doesn’t matter – building properly localized Web apps with RoR is incomparably more complicated than with ASP.NET; this is the biggest problem with RoR at the moment
• RoR is not thread-safe, so if you want to serve several requests at the same time you have to set this up yourself (non-trivial, see next point)
• Setting up (or deploying) RoR application is complicated just because there’s so much choice (regardless of what Open Source zealots will tell you, my opinion is that too much choice hurts) – do I use Apache or lighttpd or maybe Mongrel, or maybe I should combine them with a load-balancing scheme; should I deploy to Windows or Linux and if Linux, which distribution and which version etc
• RoR is young and sometimes changes a lot; if you want to stay on top of it all, you have to run the latest code which in turn means that you’ll run into bugs and won’t know if it’s your bug or framework’s
• IDE support is not as nearly as sophisticated as it is for ASP.NET, including integration with databases
• Third parties do support RoR in the form of plugins, but there are so many and most are a one-off job from a single dev just playing with the technology so you have to be careful which ones to pick to base your code on
• Ruby is a great and flexible language but it is slow – if you need stuff done fast, you might have to resort to writing C based extensions which is hard if your background is pure Web development with scripting languages only
• Ruby as a language evolves very slowly; the i18n problem that I mentioned is supposed to be fixed Real Soon Now^TM yet it took more than a year to move from 1.8.2 to 1.8.4 (with a small fiasco with 1.8.3)

Looking at all of this, it’s obvious that RoR is not a clear winner over ASP.NET. In fact, the site I built with ASP.NET, despite all the frustration would probably be harder to build with RoR just because of bad i18n support.

In the end, having in mind my needs and the size of the site I am about to build, I decided to go with RoR. It just feels right. Everything makes sense. The framework is there to help you, not to fight you. If you can live with all the conventions and restrictions of course.

So choose wisely. Ignore the hype from all sides. Try building something and definitely read a few books and search the Internet. There’s a lot of information out there. Hopefully the last two posts will help you decide too.

I need a Web framework to build my site. I am proficient in C++ and C# and Microsoft SQL Server 2005. I work on Windows XP Professional 90% of the time and I like the .NET Framework very much.

Based on all this, I should have chosen ASP.NET (2.0) for my product’s Web site, yet I didn’t. Note that I have already built a (small) site with ASP.NET 2.0 so the experience is my own, not something that I have read on the Internet.

In this post, I’ll list the pros and the cons of ASP.NET 2.0. First, the good things about ASP.NET 2.0:

• The underlying framework (.NET Framework a.k.a. Framework Class Library or FCL) is great – it’s the same class library I use for the desktop product so I “know it” already (I put quotes because you can never really know a huge framework like that)
• The tools support is excellent, plus I use the same IDE as I use for my desktop product: Visual Studio 2005
• The debugging experience is flawless
• If you don’t know HTML, getting a decent site up fast is trivially easy
• Graphical preview of the site’s look while in the IDE is almost perfect
• There is Intellisense everywhere and the IDE can check compliance with various HTML/XHTML versions; the Intellisense even adapts to the schema chosen, so if you pick XHTML 1.0 Transitional you’ll get errors for each element or attribute that is not allowed
• There is a big community around it and many, many third party products to complement what Microsoft has offered us with the ASP.NET
• The internationalization support is way better than anything I’ve seen, on any platform
• There is a small Web server bundled with the IDE so you don’t need to have a “real” Web server on your development machine
• The documentation is good and the latest MSDN library is now free for anyone to download
• There is a free edition of Visual Studio 2005 (Web developer) and a free edition of SQL Server 2005 (Express) so technically it costs nothing to develop for this platform

Now for the list of what’s not so good:

• The deployment is confusing and the fiasco with the new project management is irritating; instead of using the same build engine (MsBuild) as for the other types of project, Microsoft decided to “innovate” and gave us Web Site “project”, only to subsequently give us Web Application project (as an add-on), plus the Web Deployment project (are you confused yet?); some of these add-ons simply do not work as advertised and generally things get really confusing with so much choice
• The SQL Server Express 2005 user instances feature is great, but the deployment has a tragic flaw – the idea is that you’ll simply put your database in the App_Data folder and xcopy it with the rest of your Web project (or deploy it using one of the several ways, see previous point), but this does not work; something needs to be registered somewhere, the easiest thing to do is to install Management Studio Express 2005 and attach the database at least once (!?!)
• While the general architecture of the ASP.NET pipeline is great, the UI generation is sub-optimal at best; if you do know HTML, you’ll end up fighting against the framework more than using it to get things done - just one example: instead of getting less markup in your “template” code than when using plain HTML, you end up having more markup; this applies mainly to the “customized” UI – if all you’ll do is to have labels on the columns of your data table (for example) identical to the names of the columns in the database and you’ll never customize any styles, then the generated markup is short and nice
• More on the UI generation – the Controls are a nice idea, but the markup they spit out is mostly hideous and not CSS friendly; Microsoft knows that and they’ve been working on Control adapters (I have even deployed one, the Tree control’s output was very ugly and bloated using tables), but this is a patch of something that should have been done properly in the first place and only complicates deployment even further; additionally, the control adapters project appears to be dead, with no updates since end up April so I can assume this to be just yet another CYA (cover your ass) side-project and not an honest effort
• The skins feature is nice but ends up putting all the styles inline, instead of in a CSS file where it can be shared (and cached by browser); additionally, the editor for skins which are nothing more than stripped down ASP pages does not support Intellisense unlike the rest of the IDE; fortunately, you can safely ignore skins and make a pure CSS site that is still skinable
• There is no object-relational mapping (ORM) layer per se, but there is a good support in the shape of ObjectDataSource that allows you to treat many things as data sources and then bind all of your UI to the ObjectDataSource; it almost works – try the most trivial, yet very frequent thing like inserting a row into a table which has an auto-incrementing id column (which may or may not be a primary key at the same time), then try to get back that id – it’s gonna get too complicated for such a simple thing
• The data adapters’ (the layer supporting the data sources) editor is very rude and will often overwrite the markup you’ve added or changed yourself (the underlying format is XML and is human readable)
• When things work, great; when they don’t, the documentation does not help – if you don’t do things the way the designers anticipated, prepare yourself for a lot of frustration, mainly because you’re trying to tweak something that should be trivial; I have previously posted two examples of this here and here
• While there’s a lot of code to assist you, there is no real framework to be used (a la MVC or something similar); in other words, the framework is mostly physical (lots of classes for a lots of uses) instead of logical, trying to guide you (and yes, even punish you when you do something stupid)

In general, looks like ASP.NET has been built mainly for Intranet applications and in-house developers or beginners. If you don’t care about the way the pages will end up internally (including the size), will work on IE and the rest be damned and just want to get the results quick, by all means choose ASP.NET. If you do care about standards, page size and using the framework instead of fighting it, you’ll have to look elsewhere. That may well be Ruby on Rails, but more on that in the next post.

It is miraculous how Joel Spolsky can turn a topic everyone knows about into a very interesting piece. His The Development Abstraction Layer lays out the situation most of us have been, are now, or will be in the (near) future. How many developers are really aware of the infrastructure needed to run a company?

Anyway, how does all this apply to µISVs? The whole point of µISV is not to have the (comfy) abstraction layer and to handle all that yourself. Is it possible and if yes, how? Let’s see…

True µISV consists of a single developer/manager/boss and maybe one assistant, usually a spouse. The office is the bedroom, or the spare room, or the attic. We build our stuff on a computer, and it is very easy to buy one with a decent maintenance contract. Getting a fast Internet connection has never been easier and the uptime of one is generally very high for a very low cost. Since you work at your place, you can organize things like quiet office and adequate ambient temperature yourself.

What about graphic designers and testers? The former can be outsourced, while the latter unfortunately can’t (at least it’s harder to get the right person that’ll do the job well) – you’ll have to do the testing yourself. Marketing you don’t want to outsource as it’s a primary component of your business, but yes, there’s nobody to do it but yourself.

As long as you have a partner to do the tech support and misc administrative things, you should be just fine assuming you don’t hate marketing and testing. Selling is easy, once you’ve made yourself visible – there are zillion of payment processors out there and shipping software is trivial over the Internet.

That said, look what happened to the few µISVs that got absorbed by NewsGator (Bradbury Software for example) – they seem to agree that while µISV model was great for them, having someone else to take care of “the rest” and leaving them to do just the product development has been even better.

As long as you are aware that the abstraction layer exist and that you can’t ignore it you’ll be fine running a µISV. However, if you’re one of those that see the management, marketing, sales, tech support and administration as “overhead”, think again about establishing your own company. There’s more to product development than meets the eye of the average software developer, because the product is much more than just the source code/technology.

If you haven’t seen “Omega Man” or have read “I Am Legend” (from Richard Matheson), please do so. The book is great and the movie captures the spirit, even if it is a bit naive from today’s perspective (but it gave me the creeps when I saw it as a little kid). There’s even an announcement that there will be a remake in 2007, which if executed well would be great. Of course, there’s still a chance they’ll turn it into an action movie with Arnold Schwarzenegger

Anyway, the book and the movie are about the futuristic world where everyone contracts a deadly disease and only few “normal” humans remain. The basic premise is that, in a situation like that, it’s the majority that’s normal and not you.

Well, that’s exactly how I felt in a corporate environment. Politics, sucking up to your superiors, useless meetings… Everything but honest work and results counts. Even if that was not normal, if you don’t fit into that, it’s you who is not normal.

I am happy to report that I no longer work for “The Man” and that I am from the beginning of April officially going independent . As hinted on this blog before, I will create a small company and launch my own product, but in the meantime will take occasional contract work to keep the cashflow relatively steady.

It feels a bit strange to stay at home every day, but I can at least now dedicate all of my time to my product. It is essential not to change the working habits (like getting up at exactly the same time every day) but since I’ve been in the situation like this before, I know what to (and what not to) do.

A concrete advice regarding the use of your time, especially on the Internet - stop reading your RSS feeds daily. I have moved from the daily to the weekly model and the results are incredible - I spend about 3 times as much time when I read RSS feeds every day.

This if coupled with the spring cleanup of your feeds should increase your productivity by several hours (in my case, 5-6) per week. Not too bad, eh?

Bob Walsh, author of the (very good) book “Micro-ISV: From Vision to Reality” wrote about the same thing few days ago. He calls the behavior when you go online and then drift away from link to link “attention leak”. That's a great way to describe this phenomenon. Hopefully by reading RSS feeds less often you too will be able to plug this leak...

According to all the statistics it is much more likely for your first business to flop than to succeed. This should not prevent you from trying, though. Just like Neo falling the first time - everybody falls the first time (comparison is great and is not my idea - saw it on some blog the other day, unfortunately forgot where).

More along these lines can be found in No one starts with a masterpiece. I'd like to add a bit to the theme... not only that (quote from the post) No one actually knows what they’re doing but also no one throws away their first product, even when it fails.

I cannot emphasize this enough. The work you do for your first product will be reused later, even if sliced into pieces and re-assembled into something completely different. No one works in vacuum - if nothing else, business contacts, payment processor, work habbits, and most importantly your source code will give you a big head start in your second business (unless you succeed the first time but then all this is irrelevant anyway :)). The experience you get while trying is absolutely crucial - it's very unlikely you'll repeat any of the mistakes you might have made on your first try.

In other words, just do it and worry later. Here's a motivational example - did you know that the company behind FolderShare  (recently [November 2005] acquired by Microsoft) is the same one that used to do music sharing service Audiogalaxy? I remember downloading some of the music (illegaly!) over the Audiogalaxy during the early P2P days (when Napster still ruled). I think it is very reasonable to assume that P2P technology developed for Audiogalaxy wasn't just thrown away and that FolderShare is a direct descendant of that code.