all bits considered data to information to knowledge


An excellent bit of advice from the trenches: Startup DNA

Yevgeniy Brikman, staff engineer at LinkedIN who had "front row seats at very successful start-ups" (LinkedIN, TripAdvisor) shares his observations and insights in a few (well, 106) slides here (

A very interesting insight into minimizing "trial and error" cycle with dynamic languages (#35 ) and development methodologies/framework (#37) :  shortening the feedback loop allows for earlier maturity. Or, as he puts it quoting Jeff Atwood (of StackOverflow fame), " Speed of iteration beats quality of iteration".  Of course, without discipline and support of well defined processes and frameworks the speed alone could be a runaway train-wreck 🙂

Second observation that struck a chord with me on slide #50: "If you cannot measure it, you cannot fix it" .  [NB: Of course, this has a long history (and even longer attribution list) of being said at different times in various contexts by Lord Kelvin, Bill Hewlett, Tom Peters and Peter Drucker ]. The advice "Measure Everything" should not be taken too far, though:

"Not everything that counts can be counted, and not everything that can be counted counts. "  Albert Einstein

but in the context of the presentation Evgeniy's advice ought to be taken to the heart: collect server metrics, database metrics, client side metrics, profile metrics, activity metrics, bug metrics, build metrics, test metrics etc!

And the last (but not least) observation on sharing is arguably the most important one (slides #93-102).

"The best way to learn is to teach" -

Frank Oppenheimer


Quality Attributes: either binary or quantifiable

Architectural document that reads like a promotional materials always makes me wonder... What exactly does the author mean by "easy to maintain"? Does adjusting mere 20+ configuration files on several machines in a cluster, and umpteen start up parameters for the dozens of processes qualify? How about going through several tabs with dozens of conflicting options on every instance? "An easy" is in the eye of the beholder, architects must do better than that.

In 1983, Tom  DeMarco in his seminal work - Controlling Software Projects: Management, Measurement and Estimation - famously remarked: "You can’t control what you can't measure"

This rhymes with a similar sentiment expressed by Lord Kelvin almost a hundred years earlier in somewhat more convoluted form characteristic of the times:

"...I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be."

-Baron William Thomson Kelvin
From 'Electrical Units of Measurement', a lecture delivered at the Institution of Civil Engineers, London (3 May 1883), Popular Lectures and Addresses (1889), Vol. 1, 73. Quoted in American Association for the Advancement of Science, Science (Jan-Jun 1892), 19, 127.

This correlates strongly with system quality attributes used to control system architecture development process. Any quality attribute to which the architecture must conform has either to be measurable (numbers!) or be binary - yes/no - in nature, relative terms just would not cut it (easier? more flexible? robust-ier?). If you state that the system is "adaptable" - it would mean that it is designed to accommodate some anticipated changes; it does not mean that it can swallow any change that comes after the system was designed; the value of such an attribute could only be relative as it provides no ways to quantify it. On the other hand, if "responsiveness" is the desired quality attribute then it has to be measurable (unless you are talking about Leibnitz’s monads, that's it ); milliseconds response time per user per concurrent users might be one example...

There unquantifiable adjectives and/or adverbs used in quality attributes must be kept to an absolute minimum, and be qualified (e.g. "adaptable within current technological paradigm")