Dan Curtis Johnson (crisper) wrote,
Dan Curtis Johnson


It is with heavy heart that I submit this first report on our recent acquisition and subsequent corporate integration of SmallWare, the premier vendor of software into the halfling market. Having been here for one week as our liaison to engineering, it is already very apparent to me that assimilation of SmallWare - both its personnel and its product - will be difficult if not entirely impossible.

For one thing, it is clear that the legendary halfling racial tendency towards whimsy is entirely unrelated to the gravity of the situation. On my first day here, when I used the term "halfling", Mr. Bag-Donner effected great upset and informed me that, no matter what Mr. Dug-Fancy had told us during negotiations, that was a deeply offensive epithet and the preferred term for their people was "munchkin". When I tried to apologize for my misunderstanding, the entire executive team broke out in great mirthful laughter. "Munchkin", I was then told, would actually result in some sort of violence to my person if I used it in public. Then, they reaffirmed that this was nonetheless their preferred term for their people. I no longer know what to believe about this delicate topic, and this was just one of at least a dozen ethical or social quandaries that came up during the week and were treated (to my eye) entirely randomly.

More significantly, their entire approach to development and quality is directly at odds with all that we hold as our core engineering values at ElvenSoft.

We acquired SmallWare because the halfling market is demonstrably a) very large and b) prone to impulse buying, and yet it has proven entirely resistant to penetration by software vendors other than those operated by other halflings. A superficial observer might simply ascribe this to simple racism. Our own acquisitions research believed there to be more to the situation that that, fortunately. Unfortunately, they were unable to break through to what I believe is the key insight, a simple fact that is painfully clear to me now.

The reason the halfling market only buys software from halfling software companies is that only a halfling software company will put up with the halfling market.

Take, for example, one of SmallWare's oldest, least expensive products, one that has nonetheless become recognized as their flagship program, JotBot. At casual glance, it seems a simply enough utility: a small software simulacrum that listens to what you say and "writes" it down for you in a file. A note-taking app, basically, with a bit of anthropomorphized UI to encourage use.

However, with just a few minutes of casual use, I found JotBot mystifying, bewildering, and at times, upsetting to use. It did hundreds of seemingly random things - tied or not to my own actions I could not determine - but one thing I could not get it to reliably do was take notes from spoken dictation. It moved about, it shouted, it manipulated files… and frequently, frequently, it crashed.

I asked the technical lead about JotBot's maintenance engineering and was shocked to learn that it is still under active main-line development. It currently has eight thousand six hundred and forty-four official features, and their feature database is currently tracking eleven hundred more to be added in future releases. Any feature that they've ever gotten even a single customer request for is on the "planned" list, which isn't actually planned at all. The feature additions go in whenever any engineer sees it in the database and likes the idea enough to go spend some time on it. That's how they "plan".

When I asked about fixing the constant crashing, I was told that customers like it when JotBot crashes because then it means they can launch it again and see the cool startup screen, which involves almost two minutes of interactive animation.

Purity. Elegance. Simplicity. Focus. These values are inherently woven into every line of L-Vish code we have ever produced. That is not the halfling way. That is, in fact, the opposite of the halfling way, and their chaotic, muddled, overly complex and distracting way of doing everything is inherently woven into their own programming language, HalfLANG.

For example, let us consider a common flow control structure, the "WHAT IF" statement, which posits a possible event in the code and then exits along three possible paths: "EH", where the event isn't a big deal; "WHOA", where the event *is* a big deal; and "WELLLL", which leads to additional branching logic to determine whether it's EH or WHOA. Some of the logic for such decisions might include sub-routine comparison using OH MAYBE or HOW BOUT. The actual comparison operators are KINDA and SORTA (not the same thing, apparently) and ALMOST and NOT QUITE (again, subtly different in a way that I cannot determine).

Variables are based on whatever is on the engineer's mind at the time, of course. Usually their next meal. Leading to code that looks like it's considering what to have for dinner, but is actually running sprite collision detection:

WHAT IF [ @carrots KINDA $delicious:
	WHOA %eat @carrots:
	EH %drop @carrots:
		HOW BOUT $withcheese:
		HOW BOUT $withcream:
			NOT QUITE ... EH<-

Fortunately, they comment their code to explain what everything is. And also, to talk about whatever else is on their mind. Their source is about 90% comments, almost entirely devoted to random subject matter. Many of their engineers maintain their daily diaries in source comments.

They have no compiler, only an accretor that gloms additional code onto the existing binary. I use the word binary loosely; it is not uncommon for them to "improve" fundamentally flawed data structures by moving to a larger base notation - to trinary, then quadrary, etc. At this point, some of their products are in base 17.

They never go back to fix bugs where they occur. They write new code to workaround the earlier failure case. I asked why they don't go back and just fix the bug where it happens. I was told "We can't go back and change it. That code's already done!" Their solution for insuring that failing code will be able to get to its workaround is the GOTO statement. GOTO is sprinkled liberally around other code, pointing to functions and routines that do not exist yet. If, down the road, it is discovered that the old code has a bug, they find out which GOTOs exist in that code that do not point to anything yet, pick one, and write the workaround there.

I could go on, but I am being told that we need to celebrate the successful compilation (by which I mean accretion) of a particularly complex workaround for a bug that has been known about for two years.

If it is possible, sir, in the morning - that is, if I am still able - I hope to call you at the Home Office so we can talk directly in greater detail about what's to be done. They are very excited about bringing their range of products to the wider world of elven software distribution, but frankly, sir, the mere thought of turning these people loose on anyone but each other fills me with the deepest anxiety.

For consideration: may or may not have arisen from long-ago shop talk around morning coffee
Tags: 2010, computers, fantasy, software
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded