The Power of Small

In the time I have been a software developer, about 11 years (oh crap I am getting hold), business software is usually written as huge monolithic systems that do everything a company has ever dreamed of or so they think. They are generally written in a single language that compromises a little bit of everything so that it can do an adequate job at everything. They usually offer little interpretability within there own massive architectures and almost no interpretability with other systems. I don’t know why so much software is written this way but I suspect it is largely motivated by fear. Companies don’t want to interoperate with competing systems because they are afraid that customers might leave and software development managers don’t want to develop outside of the chosen architecture or language largely because a fear of what they don’t know. But …

No language is good at everything. I would not want to write web applications in C but I would not want to write system drivers in PHP either (or just about anything BUT a web application).  It appears that a disturbingly high number of developers are very hesitant to go out side their comfort zone. They know Java or PHP. That that is all they ever want or think they need to know.

Not everything is like this. One of the core ideas behind UNIX was small simple applications that work together with each other over a standard form of communication. Applications could communication with each other over a “service” (hot word now a days) in plain text. This was and still it great for text processing but does not excel at complex hierarchical data. Developers need a quick, simple, standard, and language neutral way to communicate complex data in a stateful manner across languages and the network.

Service oriented architecture with SOAP at its helm is supposed to solve all this. But … well … SOAP is not ideal. The protocol is unnecessary verbose, it uses HTTP as its transport mechanism (why?), XML as its format, does not handle state well, and no two language implementations are compatible out of the box. To me it just seams like more of the same. Developers familiar with technologies applying them in non-optimal fashions (SOAP uses HTTP!!!).

Thrift is interesting. Thrift is protocol natural they supply a few transmission protocols in the distribution. Thrift supports a whole heap of languages, versioning, and a API definition language that is meant to be read and written by actual human beings. It’s not perfect. It does some things I don’t like like code generation and it does not support stateful communication between client and server but these are details.

Systems should be built small and interpretable. Languages should be chosen on a task level not a project one. System should be built so small that if they need to be entirely ditched and written again this can be done with out it being a huge financial burden. If someone make the mistake of writing a subsystem that needs to be fast in Ruby, than that developer can learn from his mistake and it can be rewritten in something more suitable.