Madrid Record Stores

I'll be taking a short business trip to Madrid at the end of this month. Last time I was there, 3 or 4 years ago, I used the occassion to visit some fine rock'n'roll record stores (of which there are many). Madrid is perhaps Europe's capital of rock'n'roll, having so many clubs and shops. In a close second position probably comes--Barcelona!

Anyway, I tried my hardest to remember the shops that I went to during my last stay in Madrid; with a little help of Google I made a nice little battle plan. I can leave my colleagues having a drink someplace around Plaza Del Sol and take a 30 or 4 minute stroll around the two record stores that carry what I need. I hope this post will come useful to anyone googling for "Madrid record stores".


The one that I'm definitely heading first is Escridiscos (www.escridiscos.net). The base of Jose Escribano's stock consists of power pop, however there is also a large selection of 60's, beat, garage, mod, blues, punk and so on. Last time I was there, I listened mainly to power pop, so I was very impressed to see a shop whose stock was practically made for my taste. It's all new items, both on CD and vinyl. And the thing that I remember the best: definitely the Flamin' Groovies knock-off plastic bags coming with each purchase!

Escridiscos existed for more than 30 years in the small and sweet Calle de San Martin in the very center of Madrid. At some point in the last couple of years, the house that seated Escridiscos needed to be sold; but luckily I heard they moved to venue just around the corner, in Calle de Navas de Tolosa. Hopefully I'll have no problem finding it.

Then there is Discos Babel (www.discosbabel.com), which is based on garage/psych rock, but also carries an assortment of styles. Here one can find both used and new records and CD's. I missed this one the last time I was in Spain, so this time I'll be smarter than that. There seems to be a very nice selection of 60's reissues, and furthermore, the prices are very affordable! If I understand correctly, Babel is very close to Escridiscos, also in the old center of the city (Costanilla de los Angeles, near the Opera).

The last time I payed a visit to Madrid Rock, which was a strange place: an awfully large space in a great old building on the main street. This was almost a department store, but amazingly carried a fair amount of good 60's garage and garage revival CD's. I was surprised to read that it is closed now. Apparently, the owner filed for bankrupcy and closed the store, firing a couple dozen people; he flooded the media with laments about Internet downloads, CD-R's and piracy killing his business. Later it was found out that he got an offer to buy out the building which made him a millionaire, so it wasn't piracy after all. Why not mention again Mr. Escribano here, who as a real enthusiast managed to find a new place for his store just a few steps away, and carried on... Now that's the way to do it!

Here is a map containing all the mentioned places (from left to right, there you have Discos Babel, Escridiscos, old Escridiscos place, the main square and the late Madrid Rock):


View Larger Map

P.S. At the end, my girlfriend did the buying, resulting in the following plethora of discs:

Bombay Photoblog: Finally

This post was long overdue, since I've been to Mumbai in mid-February. Better late than never...



Being a 60's fan, I was happy to catch a few shots of what could be real 60's sights. Thumbs up for Premier Padmini and Hindustan Ambassador, true 60's cars.




Bamboo juice is popular with the masses, but most European folks won't like it!

Quantifying Stability: Belady-Lehman's Curve

We've seen our software projects go up and go down; some have seen them go down in flames or up in smokes. We've experienced periods when all the work and effort invested in a piece of software lead to a result in the product quality, stability and competitive features. But we've also lived to see the times when all the work lead to more problems--the more we did, the worse things got! It is embedded in a developer's subconscience that, once complexity reaches a certain limit, we lose the control of the whole system and its maintenance becomes a nightmare. However, we rarely try to quantify this intuitive idea, although these issues were addressed as early as the 70's. One of the pioneers of scientific approach to software project management were IBM's Belady and Lehman (*). In their 1976 paper, "A Model of Large Program Development", they quantify what we all know intuitively.

This paper postulates two quite obvious "Laws of Program Evolution Dynamics": law of continuing change and law of increasing entropy. However, the third postulated law, that of statistically smooth growth, is much more interesting... Based on a statistical model that the authors built using data gathered for more than a decade, while developing OS/360, an operating system for IBM's mainframes (**), this law is easily stated in form of a curve. We may call it the Belady-Lehman curve.

The graph depicts the expected number of bugs in a software product throughout its lifecycle. As the BL-curve tells us, there is a period when the bug count decreases with the passing of time (and doing of work). However, as the result of constant change of the system (due to bug-fixing, further development, refactoring etc.) the structure of the whole system degenerates, and it becomes harder to maintain, harder to control. At one point, the scales tip, and further work increases the bug count--we introduce more bugs than we are able to fix.

The minimum point of the B-L curve is the moment when the software system is in its most stable version. Continuing the work on the project the same way we did before this B-L minimum point would result in poorer quality of the product. So what do we do? Daniel Berry throws us a couple ideas in "The Inevitable Pain of Software Development, Including of Extreme Programming, Caused by Requirements Volatility" (I found this through Scott Rosenberg's blog at www.wordyard.com):

1. We can rollback to the most stable version, declare all bugs to be features and stop making any changes to the software, which is what was done with classic Unix tools. This renders the software dead, which might work out fine if we have a special position at the market, or we're doing it just for kicks. In real life, the product at this point is never shippable, so the only place this path leads to is--unemployment line.

2. We try our best to change our wicked ways, and somehow move the B-L minimum point further to the right. As Berry points, most of the modern coding paradigms, methodologies and industry practices are invented merely to push that point a bit further. I'll try to throw a few random ones just to prove the point:

• Modularity and Information Hiding. If we reduce complexity by breaking the product into modules whose implementation is independent from each other, the B-L point of each module will be reached later. It is not a simple sum, given the complexity in integration and the behavior of the whole, but it is still safe to assume that the whole product's B-L point will be further to the right then.
• Unit Testing. If a bug is found and fixed immediately after its creation, then is it a bug at all? It shouldn't then be summed into the value plotted in the curve--thus unit testing tames the angle in which the B-L curve grows.
• Bug Tracking. Obviously, we use this to assess our position on the graph.
• Code Control. Again obviously, we use this to move freely left and right on the graph.
• Agile Methodology and Iterative Development. By reviewing our position more often, we are able to alter our actions earlier, and avoid reaching the steep growing part of the B-L curve.

And so on. However, Berry leaves us with not much optimism, stating that:

Consequently, the software tends to decay no matter what. The B-L upswing is inevitable.

Unsurprisingly however, real-life data never looks much like Belady's and Lehman's curve. Here's the recorded count of open bugs in my company, in a large, classic distributed system heavily customized for most corporate clients.


Real-life data is corrupted by one or more of the following facts:

• The number of reported bugs is not equal to the real number of existing bugs: duh;
• History "starts" at one point in time: in our example, Bugzilla was installed in 2003;
• Testing teams change through time: growth of the team means more found and reported bugs, altering our perspective on the matter;
• Pushing the development teams prior to deliveries results in local minimums of the B-L curve: in our chart, local minimums are suspiciously close to shipping dates.

If our graph doesn't even resemble the Belady-Lehman curve, how do we know where on the B-L curve does our current project stand? Why don't we all comment on it? I encourage readers to post their own charts; they are easily generated if you use Bugzilla, the free bug tracking system.


(*) For a recent idea that can be filed under "scientific approach", see Joel Spolsky's "Evidence-Based Scheduling".
(**) Development of OS/360 also gave us Fred Brooks' "The Mythical Man-Month".