Just making stuff work

I consider myself still a rather mediocre developer. While I am developing since almost 20 years now (starting on the C-64 with Basic, moving to Pascal and Delphi during the 90's up to PHP and C# in the past years), I never had much formal education or worked in a big development team with many senior developers to really teach some lessons. This has both advantages and disadvantages.

I switched over to C# a bit more than a year ago, and this was the first time I started working on really "big" projects, at least compared to what I've done before. Also, I started reading more and more about software development practices, especially in the agile world. Of course, if you read a lot of blogs and forums, everyone seems always to be talking about best practices, how stuff SHOULD be done, how to make it shiny, how to make it dance and sing. This is certainly good stuff, because after all, we all want to learn how to improve our work, do we?

Unfortunately, it sometimes leads to too much desire for perfectionism, up to the point where the project simply does not ship. This is also the side effect of the "not being able to let my baby go" behavior, where developers simply do not feel comfortable letting their program free because they feel it's still unpolished and "just not ready yet". I am in that camp at the moment as well. I have read so much about architecture, I would just love to start bringing in Continuous Integration with dedicated build servers, unit tests, mocking frameworks, automatic documentation generation and deployment into my process, all at the same time while building the best Web 2.0 AJAXy interface ever. Just: That's not going to work. Rome was not built in a day, but the first versions from Rome were not perfect either.

I am currently trying to move a bit in the opposite direction, in the "Just damn ship it already!!!" direction. Now, Alex Papadimoulis certainly had a few excellent points in his "What Could Possibly Be Worse Than Failure?" Article, but it leaves out one point: A system can be partially rewritten after it is released. Now, rewriting sounds like a terrible idea and people love to point out the Netscape failure as a prime example not to do it. But that's only half of the story. Netscape did tabula rasa and started from scratch again. This is something I would not recommend. But there is in my opinion nothing really wrong with taking one part/module of the system and rewriting it, based on the feedback you received.

Jeff Atwood is on Episode #134 of Hanselminutes, and some of his remarks seemed quite shocking for Scott. For example, Jeff has SQL Server installed on the Web Server, and also has the current development version of the website on the same server. My first thought was "WTF???", but after thinking a bit more about it, I now think: "Why not?". Of course, the proper way would be using at least 3 servers, a big firewall around the SQL Server and a separate Development Server. Well, nice idea, but we are now talking about 3 servers that will have to be paid every month, that require regular maintenance (updated and stuff) and that open up new challenges (i.e. If SQL Server is on a separate box, you are now transferring the data over a network, which may have worse performance than having the SQL on the Web Server and have everything simply go through the RAM). Is StackOverflow.com a good example of "great architecture"? Probably not. But is it an example of a Website that just seems to work despite not-perfect architecture? Probably yes.

Reddit was completely rewritten already, EVE Online just completely rewrote their network stack, and Mozilla had to split their product into separate ones (Firefox and Thunderbird) because it was just a big unmaintainable behemoth before.

So yes, it is easy to criticize people who are using the "wrong" architecture or not following all the best practices. It is easy to write a spec that requires 11 servers connected with 10 Gigabit low-latency infiniband network to describe a program that will revolutionize the Internet. But actually implementing it is what matters, and usually, you have to sacrifice some shiny things in order to just get the product finished. You will have to release an "unfinished" product, but in the end, that will not matter. Two things matter: a) having an idea and b) actually implementing it. It's step b that is the important one.

I am not good at that yet, but now that I've spent 2 years of focusing on "best practices", I will now try to also focus on "making stuff work, fast". Or, to quote Linus Torvalds, "Release early. Release often. And listen to your customers.".

Disclaimer: This may not apply to shrink-wrapped software. Actually, I am pretty sure it does not. Also note that there are some things that should definitely be spot-on directly, for example security around user data.