Software designA look from the field…

Ofer Egozi, CTO

Babylon Ltd.

Goals

Review some software design issues we came across at Babylon R&D

Demonstrate the importance of some principles you study here, in the “real world”

But also show the constraints that cause us not to follow them, and what happens then

Babylon – the company Established in 1997, single-click dictionary Internet global distribution, eyeballs model Added conversions, user-created glossaries Monetization attempts (2000) disappointing Major restructure in 2001, team halved Move to licensing model, retail + corporate Added PRC, Enterprise information (2003) Today growing, balanced, ~70 employees

Babylon-Pro Basics

Local Glossaries

Content-Manager

GUI Result-Manager

Client

OCR [ trap click , get context ]

Server Glossaries

Server

Babylon R&D – products

Babylon-Pro

Public Server

Babylon-Builder

Enterprise-Server

1997 1998 1999 2000 2001 2002 2003 2004 2005

2.0 3.0 4.0 5.0

2.1 3.0 4.0 5.0

1.0 2.0 2.2 3.0

2.0 3.0 5.0

A lesson in what not to do…

High cohesion, low coupling, locality, understandability…

Versions 2.0 – 4.0 were almost anything but the above… example

Why? time to market, prototypes that become products, never time to rewrite

Still we survived until a rewrite could be prioritized (v5.0), toward the Enterprise-Server

Inherent constraints Millions of active users (can’t babysit at

customer site, at least not retail…) Backward compatibility major issue (BDC),

hard to simulate in Technion assignments… Retail market much less customer-driven,

design may start earlier than full specs (U3) At some stages, time to market critical, at

others – not (and stability critical)

BES

Babylon-EnterpriseServer

BES-ext

Requestor

Content Manager

XML/httpXML/”COM”

General architecture (5.0)

Babylon Client

Public Server

Gloss

Content Server

Note: describes only BDC data sources!

Content Server - Deja-vu

Don’t duplicate code – trivial, isn’t it? Initially content serving was client code only

(v2.0). Then, marketing demand for a quick online implementation (v2.1).

Main challenge – wrapper, core sources shared With time, this on-demand porting was

somewhat neglected, and coordination drifted Only in 2004 (v5.0), code was restructured and

unified, first as sources, then as a portable DLL

Content Server – “classic” classes

What would you expect classes of a Glossaries’ Content Server be?

Surprisingly, we actually do use the real-life objects in these classes: CBDC, CBDCRecord, CBDCWordRecord, CBDCTranslationRecord, CBDCInfoRecord, CBDCTranslationsIndexTableReader

Observation 1: all these are internal, access is only through high level calls

Observation 2: additional, “physical” classes, e.g. BRandomAccessReader (low-level) or CBDCWordsTableReader (install/upgrade)

Request/Persist - Abstraction

Recall architecture… Request / Reply format (v4 example) Configuration / Persistency (registry / .ini) Natural unification solution: XML format Proprietary – integrity-check, compress, typing Markup interpreted to/from XML, interpreter is

a portable recursive class Designed to solve data integrity problem, then

generalized and used throughout products

JBanner - interpreter

J frequent prefix, but does not stand for Java… Element for proprietary advertising (2000), go

beyond animated gif (no Flash then!) Marketing requirements too unpredictable, wanted

to allow maximum flexibility Created a simple but powerful scripting language,

power ranged from simple banners to arcade Interpreter always adds a level of complexity,

bridging it to “user-level” is important In our case, it was not bridged…

BES-extensions - cake-baking

Recall architecture… Enterprise-Server requestor implemented at

first in public-server requestor Very quickly, differences grew to be significant,

and complicated code Hard work invested to detach the BES-

extensions module Module then put in a DLL (BES client only) with

a “narrow interface” to enforce

Testing

We know how to do that, don’t we?

I’d like to talk about:

“Post-Testing” Testing? “Post-Testing” Testing?

Post-Testing Testing - logs

QA is the process of finding bugs, not proving there aren’t any…

On release, load shifts from QA to support Empower support using readable and

detailed logging in Release (example) More difficult to add good logs after

development... Development/debug logs should be cleaned

and kept, with LogLevel support

Post-Testing Testing - crashes

On the Complexity of Debugging Crashes… Until v3.1 (2000), many client crashes were X-

files. Then, crash-reports were introduced. Crash rate shrunk by an order of magnitude,

crash visibility and investigate-ability rose Here’s what the user sees.... Infrastructure – simple macros, embedded in

main entry points and sensitive code With time, recovery added too (use sparingly!!)

The trivial rules of thumb

Avoid “NIH” syndrome if possible… (example: GUI)

Trade-off between abstraction and speed (example: glossary installation)

Entire module rewrite gets a low priority a-priori – cause for developer frustration

Rewrite is also dangerous - listen to Joel…

That’s all folks…

Questions?…

Main header (partial)

v3.1 , 2000

Sample request/reply – v4.0

217.66.199.240 - - [04/Sep/2004:00:02:11 -0400] "GET /cgi-bin/trans40.cgi?

00GFA2IAC3136FCJ0,645,385;748B;2AEF;1199;182A;87C;C01;11EE;638B;4EA;4E8;4F8;4E7;38E;4EB;38D;38C;38B;38A;4E4;389;9DA;388;4E5;387;386;390;38F;0:2:33:.AAcknowledgement HTTP/1.0" 200 6 "-" "Babylon"

Babylon-Pro Basics – server_reg

Local GlossariesPersistency

Content-ManagerPersistency

GUIConfigurationLocalization Result-Manager

Client

OCR [ trap click , get context ]

Server GlossariesPersistency

Server

Request

Reply

Request

Reply

DOM

context

JBanner (interpreter)

Email from marketing to R&D team leader…

Logging – example (client init)

Support process flow

Exception handling facilities

Code running at exception must be “thin”! Example for CSHost service

Shared client/server code (pre-v5.0)

Shared C/S code (v5.0 - CSHost)

When there is too much sugar…