fiat lux

Two quick thoughts:

There is a certain kind of boast, or personality thereof, that emphasizes “how good I have (or the thing has) become because of my choice of tools“. Like, “the photo is great because of the camera I bought“, “the code has become faster, the lines fewer, the scalability better, because of the language that I mastered“. The fact is there is no good tool or bad tool, only tool that fits the situation and tool that doesn’t. Masterpiece can be taken with a point-and-shoot camera (think of Nobuyushi Araki), and talking about how many megapixels there are is platitude.

There is a certain kind of travelogue that I stopped reading since long ago. I seem to have lost interest in what is happening in a city now and am only interested in the history of a city over a certain period of time. Any travelogue that tries too hard to fit in too may now-happenings loses my readership for good. My criteria for good travel literature now: curiosity, slowness, acceptance of fateful encounters (or the lack thereof), and the most important quality, silence.

lukhnos :: Sep.16.2007 :: bon-vivant :: Comments Off

Some Cangjie (倉頡, long mistransliterated as Changjei, an important Chinese input method) users reported that Vista screwed up this 30+ year old method by now requiring users to enter the whole phrase instead of sending out each character when it’s done. This adds an extra ENTER key to finish a phrase, much to the user’s annoyance.

Microsoft is just among many multinationals that screw up CJK input methods from time to time. Many decisions are made from engineering’s point of view, not usability. They are made out of technical superiority, not respect of established usage and history. This fits once again one of the theses of this blog, that a system is a historical construct, and we must respect that history. Usability fiasco is the direct result of engineer haughtiness.

In terms of the C of the CJK trio (of the CJKV what… quatro?), there are many more such cases and it’s not just Traditional Chinese that is affected. An interesting antidote (or anticlimax) to the notion that “The whole world is learning Chinese” (actually, that’s Mandarin) and “Chinese is becoming the language of the 21st century”.

lukhnos :: Sep.08.2007 :: tekhnologia :: 2 Comments »

Another short entry. The short answer: because now you both have to observe the old behavior and respect the history.

Many system designers ignore the fact that a system is a historical construct. No, we are not talking about some 1970s French phisolophy-cum-literary criticism stuff. But truly, a system is not just designed. It’s formed over time. Many systems, when they finally reach to the stage where they become inadequate and even burdensome, were at first designed with clear mission and structure. But many small changes have creeped in. Many last-minute changes, or small tweaks (so as to make the system work), would become a norm.

Any redesign must honor the old system’s total functionality, and such totalness is very detailed and hard to figure out.

Of course another way of redesign is to refine the mission, the problematics and the solution/functionality of the system. But that usually involves more timely rethinking. Any rethinking done with haste or haughtiness is often doomed to be a design even more inferior to the old one.

As a programmer, I’d say it’s the debug, and the quick fixes and tweaks that comes along with the debugging process, that lubricate a software system. Those lubricants are added over time. And that’s why I said a system is a historical construct. Many fixes and tweaks do not belong to the initial thinking (the design stage). They are not to be accommodated in an abstract model and often pop up only in the running stage. It’s tremendously challenging for a rethinking (rearchitecture, refactor, reform) to accommodate them.

The implication here is: be wary of the tweaks and quick fixes that will be part of a system’s life. A system that absorbs and digests those tweaks better will usually have a longer life (ironically, that also makes it harder to regenerate [ie. for the system to start anew], but that’s a topic for another day).

lukhnos :: Sep.05.2007 :: tekhnologia :: 3 Comments »

This is going to be a short entry: So lately I’ve found a pattern from a number of places I’d previously worked at. I call it the tendency to “use more tools to solve problems created by tools”. It went like this: Needed a group ware, but no body really used them, so needed to arrange training sessions. But hard to solve schedule collision, so needed another group calendar (in some cases, plug-in for the previously mentioned group ware). Installation and usage were hard, so wiki to memorize them. Too many systems, so added up another homepage / blog / resource management system whatever to manage them all.

See the problem here? One of my ex-bosses, a professor that I really admire, she said: “We only use one ‘groupware’ tool: a giant blackboard, with lots of large white poster paper.” And guess which is the more efficient?

Another female friend of mine commented this kind of “tool worship” a problem of men. I don’t know about other cultures, but in Taiwan it’s quite true. Reductionism is not en vogue here.

lukhnos :: Sep.05.2007 :: tekhnologia :: 2 Comments »

Lately I have been troubled by the attitude that “I do it for free, so take it or leave it”. True that no one should burden the contributor who does it for free. But as such, the contributor should claim no more than having made the contribution. Some “savior” type likes to claim they’re doing an important job, serving many, saving poor souls from X platform, and enjoying the fame. A slightest request, however, results in “I have done so much, platform X sucks, and nothing is for free: write the damn code yourself if you want that feature!” As if the world owes him or her a sorry (enough paean has been sung).

Interestingly how such arrogance can reflect in the code. I’ve seen a few cases where the correlation is high. Legacy features are treated as, well, “legacy”, and are taken away without first understanding why they are there. Variables and functions are named carelessly. No boundary check in place. No real coding style is enforced–both an aesthetic and managing disaster. Dangerous memory copying and pointer arithmatic done in a way that make people who really do K&R frown–and remember? there is no boundary check. All for the sake of the really non-existent problem of “needs to be efficient”. But for those who know better, it’s really just some bricolage in a sorry state.

That’s plain wrong. That I do it for free does not mean I can do it as I wish. Especially if you both claim to be a serious software developer and to have the intention to help others.

It’s like NGOs and charities. That you have good intentions doesn’t relieve you from the responsibility of doing things the right way. That is what professionalism means. Even amateurs know what that means. There are even hobbyist activities that actually require high skill, attention to detail, and utter seriousness.

Some software can be more serious than others. System software is one example. They are not just expected to be reliable. They must be. And tons of application code and logic depend on those foundations. They must be solid as rock. And they need to be very well organized, clear in what they do, and have sound logical flows. And that’s why open source system software projects are run in a serious manner, however disperse and loose their organization is. Coding style is enforced, review and criticism needed, even welcome. Interestingly–individuality still plays important role. Personality clashes can happen. But whatever the argument, reckless coding can be like reckless driving in coding system software.

Serving many can be a tricky business. Or as the saying goes… “With great power comes great responsibility”. Please, please don’t be a savior if you are actually a reckless developer.

lukhnos :: Sep.02.2007 :: tekhnologia :: Comments Off

• Common sense and good reasoning are both rare.
• Quality is built-in. It’s never something you can hire a consultant or designer to have.
• Worse, face-lifts hide future implosions.
• In the end, the work emanates from one’s belief or philosophy of building things. To ask “why a system behaves like that” or “why a system sucks like that” (ie. to trace the expression of a system’s working), we must go back to how the system is designed, thought and built.
• Sadly, asking such “why” can offend.
• Many system designers (many of them an incidental designer–they didn’t know they were laying the foundation) get angry if you ask them a commonsensical why.
• If a person tells you “I’ve lately read this and this, and I fully agree with the methodology X, and we should do it”, be wary. A person who is easily converted is easy to switch again.
• On the other hand, there’s no talking with someone who is entrenched with a given belief, especially if the reality is in conflict with it.
• To say that a system is an expression of its founding thought seems to be a kind of idealism (ie. it’s the idea that counts). Of course a system is always designed within its constraints (ie. “the material basis”), but within the given boundary, it’s really the thought that counts.
• Be very vigilant of the initial thought you put into the design of a system.

lukhnos :: Sep.01.2007 :: tekhnologia :: Comments Off