Most software tools grow over time, only a small number stays the same. These are not increase in functionality, because they have already all what is needed; they are perfect. What is the receipt to achieve that?
In my own work I see the following pattern which leads to bloat: underestimating complexity and building something too simple. The pattern, once recognized, may lead to improved designs, such that software bloat can be avoided. Here two examples:
I tried to build a tool to automate the construction of graphical user interfaces from ontology and I included facilities for conversion between the screen representation and the representation in the application program. Different applications had different requirements for this conversion and the functionality grew ...
What was wrong? the complexity of the conversion requires a full programming language and I was, step by step and functionality by functionality inventing my own. Bad move!
What can be done? have the part which converts between GUI and application written in an ordinary programming language (in my case, Haskell) and remove all functionality which can be provided in the conversion functions written in the general programming language. - Progress: the tool becomes smaller and simpler!
I found the same approach in couchDB: parts, where complexity of the application comes in, are programmed in a programming language (e.g. views - compare with the complexity of special languages for report generation of old). CouchDB just manages the code (in javascript - a nice functional programming language!).
Bloat occurs slowly if we try to build something that is too simple, and then realize that a bit of functionality here and a bit of functionality there must be added and before we see it, we have BLOAT. It is a sign of not factoring out complexity in parts where it can be handled with the ordinary programming language and can be avoided in many cases.
No comments:
Post a Comment