Hello world!

Hello World (& why OOP is not for me)! So what's this? Please see the about page for a formal introduction, but in a few words this blog is about new frontiers within software development. Best in Class is a danish company, but I've decided to blog in english as the content is relevant outside the borders of Denmark. I've decided that my very first blog post might as well have some punch to it. So let me start by telling you, what got me moving away from mainstream programming and why I thrive there. In my experience we make valuable progress in the times where we cast our critical eyes on our best tools and methods. In 1962 two gentlemen proposed a framework which was specifically crafted to support work on simulations. The concept was using objects as datastructures and some 30 years later Object Oriented Programming caught the mainstream. Despite being born of simulation, it has become the proverbial hammer used for a multitude of applications—often even when inappropriate. The problem we face with larger applications is primarily complexity, but thats more than a headline. Complexity makes our attempts at understanding our systems increasingly difficult. I think generally we have 2 tools for understanding:

1. Testing
2. Informal reasoning

(1) Is our attempt at probing our systems by external observations. (2) Is a review of the internal components of the system. The latter is often a greater investment, but the hope is that a better understanding will cause less problems down the road. So where does complexity come from? If you're doing a peer-to-peer client/server application which synchronizes information between multiple clients on multiple hubs, its reasonable to say that complexity is inherent to the problem itself. There are many things to keep track of and many I/O situations that need to be carefully implemented. In larger systems however, especially when built on OOP technology, its often the implementation itself that is complex. The Object Oriented approach can roughly be cooked down to this workflow:

• Making objects
• Settings states
• Mutating states

With mutable state comes problems, because we can have a fixed input but varying outputs. A simple example would be

ping www.google.com 64 bytes from wy-in-f99.google.com (209.85.227.99): icmp_seq=1 ttl=52 time=65.5 ms

The function is ping, the parameter (input) is www.google.com and the output is a reponsetime of 65.5 ms. Lets try again:

ping www.google.com Hostname is unreachable

Same function and parameter, new output. Where do we look for the problem? A creative mind will quickly come up with dozens of subjects for serious investigation. But more to the point: How does this affect the way we understand 'ping' by means of testing? It puts us in a dangerous position where guess-work is needed to complete our analysis. Rarely do you see a system where it is possible to test every possible state and trigger every bug up front. Its just not done. So we still have one big tool in the box: Informal reasoning. By methodically going through the code and examining dataflow we can try to gain some foothold in regards to understanding the workings of the system. As we read through a certain method's code we can mentally simulate how it will behave in a certain condition. We imagine mutating input and foreseeing new outputs. As the number of states and thereby the number of possible outcomes grows our approach loses credibility. I have personally witnessed a system which was internally tested, built on solid libraries and was maintained by a relatively small group of core developers. The dataflow was relatively simple and easily understood. When the system was deployed about 500 bugs were revealed in its first months of operation. The majority of these were simply: Unexpected states. I could spend many pages explaining more sides of complexity, but I'll leave it here for now. I expect that my next blog post will focus on the solution to the problems caused by state, the first of which being: Giving OOP back to the good people working on simulations :) /Lau