Official Blog

Last Thursday and Friday Patrice and myself travelled to Munich. And if you travel, you have something to tell (Citation by Matthias Claudius, 1740 - 1815). 

We were invited to present Nektoon at the 5th Venture Day of Swiss Technology. Around 6pm we gathered on platform 14 at the Zurich main station. Soon Jean-Pierre Vuilleumier, the managing director of CTI Invest, joined us.

We got ourselves a place in the restaurant coach. It’s a long journey: four and a half hours for roughly 300 km. Luckily the line is about to receive an upgrade after years of neglect. Then again, this would cut short our amiable and enjoyable trip by an hour...

After aperitifs, Dominik Tarolli from Procedural joined us in St.Gallen. I knew his blog – swissstartups.com – before, yet never met him so far. Another plus of our in person get together, I finally got it what their city engine does – amazing stuff!

After some E-Mail back and forth Matthias Sala from Gbanga joined us, too. Gbanga’s wants to create interactive mobile games. They had a first test run this summer with the Zoo Zurich.

^{Picture by dselz}

Though an interesting crowd, hunger looming I couldn’t fully kick the habit and check my Twitter stream to discover Moritz Adler from Blogwerk tweeting that he sits in that same restaurant coach. Where? Meanwhile the coach became quite crowded with Oktoberfest goers.Ah, there he was.  

The six of us represent quite an interesting mix of Swiss ICT startups: Gaming, publishing, 3D rendering, fluid information and Mr. Startup Network. A few startup cock-and-bull stories later (To Dominik: Will do what you requested) we arrived in Munich where some still hit the remains of that Oktoberfest evening.

In the morning we met at the Literaturhaus in the center of Munich. How fitting: The opening speech was by Quillp, a digital book publishing site. Next to the afore mentioned there were a number of other startups from the biotech and life science (BLS) sector present.

To listen to the BLS startups was particularly fascinating. Two things struck me: We in the ICT industry are used to short development cycles. They operate in an environment where time to market is measured in years rather than in months. We may start our next venture on a shoestring; they need heavy investment over consecutive years in people and infrastructure. Obvious if you think about it, but easily forgotten if you labor day in, day out with just your notebook on our Ikea desk. 

To strive for perfection but fall two steps short, is all but human. I remember with mixed emotions the German classes back at school. Quite often we had to do essays on this or that topic. Quite often I got good marks for essay’s idea and its composition just to loose a couple of points for (surely involuntary) grammatical inadequacies.

Writing software is pretty similar: The most elegant lines of code will be undone by mundane errors.

Error recognized, error fixed, or so they say. Yet research shows that on average for every six errors fixed, one new error is introduced. Kind of never catch up game. Similar to the anecdote of Achilles, who is not able to catch up with the turtle.

A scalable website is a complex beast. Even in it’s simplest form it is a web of thousands of lines of code, several servers and services.

Humans perform mostly well in conditions of relative uncertainty. Computers not. Whereas we are able to adapt to situations, computers fail abysmally at tasks that are not clearly specified and where there is no error free code to execute. An unrecognized set of characters in a get request and the receiving web service goes havoc. A minor glitch in a sub-routine and the transaction fails.

Thus the importance of testing.

^{Picture by jackhynes}

Testing comes in a number of flavors. Every developer agrees that code should be tested. However, testing on an individual code level is not enough. Especially hard it gets if you have to take over legacy code with little test coverage. My colleague Patrice suggests two simple rules:

• No bugfix without a test
• Develop new features using the test-driven methodology

Here at Nektoon our goal is to cover as much code with tests as possible and sensible. We don't reach 100% coverage but accept one or two percent less. Going all the way to 100% will drive you crazy, as there is a lot of code, which hasn't been written with testability in mind. Testing such code while possible would be a lot more work.

A certain level of error is an acceptable outcome for a system like ours. A simple solution is some redundancy to be built in.

We consider testing integral to our work. Before automatically building the application (also referred to as continuous integration – see previous post on automation) any piece of code must be thoroughly tested.

The equation is simple: What will the additional time investment in testing yield in terms of benefits? The answer: A lot! Simpler code, more reliability, less onerous bug fixes, and less disappointed users because our service was down.

We believe in testing. Over on his personal blog, Patrice commenced a series specifically dedicated to testing. Over the next few weeks he will write about selection and setup of a testing framework, unit and functional testing, Javascript testing, continuous integration, test-driven development, testability and measuring coverage.

Next in the series how to build a scalable startup: Conclusion.

Quite unnoticed by the casual Internet user a silent revolution took place in the server centers around the globe.

I fondly remember that cold Christmas 2000 when our company delta consulting (later namics), a Web consultancy, moved to a new location. We had to move the server room, too. No easy undertaking. We had dedicated servers for a number of clients, our internal development and staging servers, filers, mail servers etc.

But we had a noble goal: finally some space again! Our old and crammed server room couldn’t hold more servers. Our new room seemed large and spacious. We continued to grow and soon we were once again mired in finding additional space.

^{Picture by stejan}

Recently I returned to visit my former workplace just to find three quarters of the room converted into a meeting room.

How come?

Virtualization.

How does Virtualization work? Companies like Parallels, VM Ware, Citrix and others provide software allowing to emulate or “virtualize” the hardware resources of a machine. The ubiquitous x86 type computer infrastructure was designed to run a single operating system and a single application. This leaves most machines vastly underutilized. Virtualization lets you run multiple virtual machines on a single physical machine, sharing the resources of that single computer across multiple environments. 

Sure you loose a bit of performance because the virtualization software mimics the actual physical hardware. With ever faster machines and ever more memory this is no roadblock to virtualization. There are however two big gains: Less space and less initial investment.

At Nektoon we have just a single server for the entire development platform. Roughly twenty or so virtual servers are running on top of it. Especially welcome for our startup: Instead of twenty servers we bought one. Albeit a bit more expensive, our initial investment was still a fraction of a normal setup. Nekton.com

Our live infrastructure is hosted on Amazon Web Services. This has one key advantage: We do not need to invest time and money in setting up a live infrastructure but instead pay-as-we-go at Amazon. With the automation in place (see previous post) we have contained the sheer volume of repetitive setup tasks. Plus we let others solve these tasks.

The distributed infrastructure also allows you to get closer to your customers. In case of physical servers we would have chosen close-by server centers for purely practical reasons (Physical reboot of a machine). Yet somebody from the US will have quite longer response times when accessing servers at some place in Switzerland instead of someplace in the US itself. The distributed infrastructure of Amazon provides a neat framework for this case: Distributed storage and processing power across the globe. So we will store the notes of our American customers in America and vice-versa with notes in Europe.

Next to the technical benefits the impact on the business plan is remarkable: We can run a startup on a shoestring for quite some time.

Next in the series how to build a scalable startup: Testing.