Some words on software development philosophy

If you were to take a look at nature, at complex systems, you would find that the complexity of the system is tied up in the connections and interactions of the components and not the components themselves. The Information, if you like, within a system is tied up in it's state, it's interconnections, and not the individual functions that something performs. Things always have a context. It is always an action performed on something rather than an abstract action. To give an example, think of the human body, or the body of any living thing for that matter. We are composed of billions of cells, each of which is a relatively simple entity, but when enough of them are put together in an ordered fashion we can construct something exceedingly complex. The complexity does not lie in the individual components but in how we connect them. The brain is another example. It is capable of performing exceedingly intractable and complex operations and yet at a microscopic level it is comparatively simple. Once again the intelligence, the information and the value in the brain is not tied up in individual neurones but how they all fit together as a whole.

As time progresses my philosophy on programming attempts to mimmic these observations more and more. With my object oriented design in hand the individual components that I need to build a system are of themselves rather simple, dull and boring, and yet, if put together in some complex way, they can create quite complex and impressive systems. When it comes down to it the most important factor in making this a reality is having classes or groups of classes that can stand up in there own right, that can exist in isolation and that are not bound to the initial goal which led to their development. More often than not I find myself coding these dull boring objects in isolation, one after the other, until I have all the pieces I need to construct a system (or subsystem). Only then when I have all the pieces I need can I even attempt to put the pieces together to create something interesting.

Herein lies a huge difference between object oriented programming and functional programming. If I were coding an application using the top down approach to functional programing, at almost any time during that development process I would have a runable application. In the case of object oriented coding a working prototype only comes together at the last instance, often after weeks of coding without a single test build. Then a sense of relief, and sometimes of exhilaration, sets in as all the bits fit together seamlessly and the subsystem runs for the first time. I almost find the process quite miraculous, though time and time again, complex systems come together after weeks of work and are up and running in a few hours, or sometimes even first time around.

That is why I use the object oriented paradigm. That is why I believe in it. If none of this rings true to you then perhaps you haven't discovered object oriented programming? Perhaps you might like to give it a go?

Paavo Jumppanen

Paavo Jumppanen
Owner of Taquis