No Duplication for a Good Code and Good Life

More things in life does not always leads to a good quality life. If the things is duplicated, its function is already done by something else, it's existence is a clutter and use up unnecessary energy. The duplication is bad in code too, it is a nightmare to maintain the same logic that scattered on several places. One changes on one place need to be repeated on the other ones that use similar logic, otherwise you'll break the code.

Having enough things is not just about living a minimalistic lifestyle, it also a way to stay sane, to not use things unnecessarily. If we can simplify things internally, we can achieve more complex meaningful things with much ease.

Children and Human's Low Level API

One of the privilege you got from having children (I have two myself) is you got the chance to see layers of human behavior API. It is exposed incrementally so you got the chance to differentiate which one is inherent to every human, what is character. If you have more than one you have even greater chance to compare things and search for invariants.

I see for myself how certain characteristic are already within a person without us do anything special to develop it. Being very attentive or very extrovert is shown in babies even when we don't condition them to be (I always thought this was very conditioned). Of course, later you can teach them and manage some of their trait to be more effective but inherently they are already have certain tendencies.

The most interesting thing for me is to see how we learn. It's really incredible to see how children learn and reflect on how we ourselves learn. You will see how those principles in AI books come from. I think you could actually subtitle any AI text-book as "how babies learn" :).

In physical level it is quite the same too. You see how those hair, teeth grow and how the faces change and shape up. Watching them learn how to walk is fun and refereshing and you see how those muscle strengthen.

It's probably a little inhuman to call it API, you could say it instead : if you'd like to learn and know more about yourself inner-workings, have a children.

Incremental Adoption of Software : From Generic App to Specialized One

Most of our software need is actually can be fulfilled by many already existing general Application. Take Text Editor and Spreadsheet for example, they are very general but highly useful piece of software. You could use them to store any kind of list or database if you can still accept the very generic feel of them and awkwardness when things get bigger. You can even utilize folder structure, file naming convention, markup convention, built-in search and replace capability to "emulate" an app.

I think we usually underestimate on how far we can go with the already-existing software and too quick to grab specialized software. But in this age of so many existing option, with many even free, who can blame us?. However, we need to also realize that adoption has it's own hidden-cost/restriction/negatives that sometime more generic application has better performance e.g: IDE vs. Emacs cases.

So, to take the best of both worlds, I guess the heuristic would be :

• Being really comfortable with available generic application. To be concrete, master application like powerful Text Editor (I use JEdit, there are others who uses Emac's fanatically) and Spreadsheet. Use their advanced feature. You will encounter that when knowing them deeply you'll find many cases that they are just suffice.
  
• Browse around and keep an eye on less widely used but powerful generic application. For example, despite it looks to have a specialized use, I find Freemind really useful in a wide variety of situation.
• If it seems enough to use the generic one in certain case, try the generic one first rather then trying to find other more specialized app, you might find out that it is actually do enough.
  
• When things get rough and you really feel that you need a more specialized app, shop around and pick the one with the most generic functionality. For example, when you only need to edit picture and Paintbrush looks plain, something like Paint.Net would be more suitable than beating yourself up trying to be graphic designer by using Gimp.
  
• When you finally use the new app, push it to it's limits and see what else you could utilize from it. Later, you could mix and match your software based on what each can do. You will have less software to deal with but still get the job done.
  

I think it will be most fulfilling using software this way and in the case of commercial software, will be more economical.

From the perspective of developer, it is useful to see what existing software that already exist that already usable enough to solve the current problem you are trying to solve with developing this new software. Developing more specialized (or more robust) software will cost the user the utilities/familiarities that he/she has on the generic app so you'd better give something much better in return.

Script/Executable-Based Application

There is a certain model application that function as a wrapper to an already-established/existing script/executable. I already stumble upon many applications written this way, even wrote one myself sometime ago (a gui wrapper for certain cli app in-house). There are even application that is written from the start by writing scripts first then wrap them in application-style user interface e.g: kalva.

It's not a sin, of course, to write this kind of application. I think it's a good way to go given conditions :

• The executable/script is well-established
  
• There's no library that wrap the functionality in a modular way
• You have little time on your hand

However, visually, you'll have quite a monolithic application that looks like :


Which ideally can be made more modular and testable architecture like below :



If you have the resources and chance your 2-tier application can be made to evolve like the above. You start by extracting the executable into library step by step until all the necessary logic are on the lib and the script is merely a caller to it. Once you have library, you can link your application to it which make your app relatively cleaner and more cohesive.

Still, despite my preference for cleaner, more cohesive application, Script/Executable-Based Application is quite an interesting approach to rapidly develop something and/or reuse an established CommandLineInterface.

Java, C# and the Case of Inferior Look

Building application is a lot of work and dealing with low level issue of OS API makes it worse. Relatively high-level language like Java and C# (I haven't seen GUI-based on language like Ruby application widely used yet) could help to enhance productivity on this.

However, despite the already long evolution, those languages has not yet fully capable to give competitive result in terms of user interface. Java-based GUI is still looking inferior compare to natively written application. Even in Windows , where it seems to have the best integration, it still feel odd here and there. It's quite unfortunate since it's relatively good/easy language to build application on.

Then along the way come .Net (C#). This one is a little bit better, at least if what you are trying to do is developing things for Windows. It has the easiness of Java but quite native feeling of the interface. For quick application programming with fancy interfaces it provide what mostly needed to get the job done. It is still has some holes here and there, but fortunately for this one, the interoperability to native code is quite excellent with lots of third party component to fill in the gap.

All is not lost in Java side though since there's SWT to the rescue. I think people seriously looking to develop application in Java but still want to be competitive in the user interface department should put this into their toolbox. It still has some issues though, but it has good approach which lately Java has start to adopt in recent releases, i.e: more native widget rendering.

There's a tradeoff in doing abstraction and generalization as we see in the case of programming in VM-based language. It create some gap in areas outside the intersection and generalization that is being taken. But the recent effort has getting closer to close/bridge those gap.

There's another path someone could take to avoid having "inferior" look to his app but still a little more productive than having to access OS API directly. It's the bottom up way : C++ Wrappers. Instead starting with easiness/abstraction and move down to take care of nativeness details, you could start with having nativeness first and work on having easiness/abstraction. There are lots of various C++ wrappers out there that could help with this e.g: QT.

Take your pick then, it's the world full of options and you don't have to always use something suboptimal, given by the standard lib, for the look if you don't want to. That being said, I still enjoy JEdit, Freemind and JUDE despite their look feels out of place a little bit. So, I guess the substance is still the king although the look could really help too.

Books are Simplified Version of Reality

Reading books is reading filtered and structured knowledge. Compare to other sources like news, articles, forums, it has relatively the highest signal to noise ratio. That value comes with a cost, most notably generalization and omission of some details and context-related materials. Relative to other more "real-time" sources it is more "sterile".

This is why when we read books we feel we got so much information but sometime we are left hanging when trying to implement it in our situation. It's because the details in books are already smoothen out, some parts are simplified, so it is up to the reader to put them back on the reality ground. If I am going to write about some new techniques I would not have enough space to cover all possible cases but only take that I think would be enough to inspire and make a point to the reader.

There's nothing wrong with it, of course. It's just how the books are positioned and made. It's the forums, mailing lists, discussion group and our own experience role to fill in the blank. Besides, it's where the fun lies anyway.

"Toolbox"-based Tools and Concept

The greatest lesson of learning a lot of stuff, trying tools and concepts are not on how it actually solve our problem but, I guess, is on this : It teach us that people and problem are unique and there's no one single tool/solution that can cover all and it's better to have something that is modular, customizable and adaptive.

Even before we start to implement something new we'll probably already see how it has some edges and parts that does not really mirror with our situation. We then pick some part that is useful and left or modify the one that does not.

Learning from this picking and modification, I think a good tools and concept is the one that is more modular and flexible. People prefer to use something modular and flexible to something that requite "All or nothing" approach. It enable people to adapt it more to their situation.

However, for concept and methodology, this modular, toolbox-based approach is also necessary in learning and adapting new things. The tools and concept should enter into our toolbox and not hijack our mind. We should only let inside something that can be a good citizen in our mind i.e: helpful but not destroy our mind flexibility. Intrusive tools and concept should be avoided, or if it's not avoidable should be allowed with care.

This could explain why many people like the concept of plugins or interdependent little tools in UNIX-based system, it allows to play with it more and be creative instead of feeling being overwhelmed and somehow foruced by the tools. This also why some concept or methodologues can be fun to follow when they consist of several interdependent components where we can still see effect of each of them independently.

I prefer toolbox-based tools and concept then the "framework"-based one although it still useful in the cases where they are specifically made to solve.

Software Assimilation

Software is not just installed, it is assimilated. It is intrusive and define the way we work into certain way. Some software introduce some different ways of doing things or initiate a completely new one and it integrate with people's mind. Software "Installation" goes beyond installation on the computer but include the assimilation of it's workflow and the assumption on which the software is based into the user workflow . Some software goes even further into shaping the perspective of it's user in seeing the problem.

It's not strange then we see people react differently to a different program. The style, assumptions and behavior of the program could conflict with the user inner mental model and adapting mental model is not a convinient process for most people.

The trick is then to find the balance between making a software that still can get an "entry point" into the user mental model but at the same time offer significant and interesting new things for the user to experience. For the user, the homework is then to find software that fit with his level of knowledge, understanding and the future growth he would like to go to. Some feature could be felt as helpful for someone could be seen as annoying or even mockery to intellectuality for others.