Thursday, December 27, 2012

Geo-replication: MDCC and RedBlue consistency

Below you can find a couple of good posts by Murat on geo-replication for recent academic work. In particular, the first link has good explanation on Paxos optimizations.

MDCC: Multi-Data Center Consistency

Making Geo-Replicated Systems Fast as Possible, Consistent when Necessary

And, if you want to watch the OSDI presentation on the RedBlue consistency (second link above), click on this video link.

Tuesday, December 25, 2012

Go Language at Google

I just read a good article on the Go Language and was pleased to see the efforts to improve build times and code dependencies. Just for the reason of learning what the problems with C/C++ include file have, it's worth reading the article.

The other reasons is to learn that Go is a language without exception, garbage-collected, without type hierarchy (but object-oriented and with interface), with a different concurrency model (it follows Communicating sequential process), among others. And, last but not least, it is an open source language.

Go at Google: Language Design in the Service of Software Engineering


From The Art of Doing Science and Engineering:
I am preaching the message that, with apparently only one life to live on this earth, you ought to try to make significant contributions to humanity rather than just get along through life comfortably - that the life of trying to achieve excellence in some area is in itself a worthy goal for your life. It has often been observed that the true gain is in the struggle and not in the achievement - that a life without a struggle on your part to make yourself excellent is hardly a life worth living. This, it must be observed, is an opinion and not a fact, but it is based on observing many people's lives and speculating on their total happiness rather than the moment to moment pleasures they enjoyed. Again, this opinion of their happiness must be my own interpretation as no one can know another's life. Many reports by people who have written about the "good life" agree with the above opinion. Notice that I leave it to you to pick your goals of excellence, but claim only that a life without such a goal is not really living but it is merely existing - in my opinion. In ancient Greece Socrates (469-399) said, "The unexamined life is not worth living"

Science vs. Engineering

From The Art of Doing Science and Engineering:
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.

Monday, December 24, 2012

"Lean Startup" lessons for big companies

Today I finished reading Lean Startup book and, like most of other readers, I can just rate it as excellent.

Here, though, I'll not talk about the quick iterations proposed by the book with the purpose of learning what works and what not, but rather the organizational aspects suggested by the author. Eric shows how big companies are already having difficulties in the new era if they don't adapt to the startup mindset.

One of the most important things is to have cross-functional small teams in order to have small pockets within the company that work like startups. One good example of company that implemented that is Intuit. Going in the direction of large functional organizations isn't the right thing to do, if the company wants to deliver in small batches. Big functional orgs work well for delivering in big batches, but that does not help with keeping up with the competition and innovation, as innovation requires a lot of experimentation and learning that is only feasible with small batches. For that, the company must be quick, must be willing to take risks, and must have the proper metrics (not vanity metrics, as Eric says) to help direct efforts. Unfortunately it seems that some companies are going in the direction of having fewer and fewer cross-functional orgs and that can be very concerning with regards to their future.

Another interesting aspect is that, different than most orgs, Eric recognizes how different employees have different skills and the ones good at innovating and starting projects are not necessarily the ones who are interested in or skilled for later stages of the project. So, rather than having a team owning a project, the "functional org" model proposed is one where projects move between teams. Each team in this model is specialized in a phase of the project. It's somewhat like a manager told me about his reports: some are starters, some are middlers, some are finishers.

Both of these points would improve the changes of big companies with challenges innovating nowadays. And not only that, it can make better use and be a better environment for employees. As it turns out, "Lean Startup" is not a book for those interested in startups, but also for senior management at big companies.

Sunday, December 23, 2012

Microsoft Surface: slow to render web pages?

I'm typing this post from a Microsoft Surface device. I've had for 10 days now and although I don't plan to do a full review here, one thing called my attention since I got it: it seems to take longer to render web pages than my desktop computer.

Today I did a non-scientific experiment. Both Surface and my Windows 8 desktop, connected to the same wifi network, loading the same pages (e.g., Google Plus,, Facebook), in same browser (IE 10 Metro on Surface, IE10 Desktop on Desktop computer).

On first load, the difference between my desktop and Surface is quite noticeable (sometimes Surface takes seconds for a page that is loaded much more quickly on the desktop). After cached, the difference is not so noticeable. As I was first blogging from my desktop, and then moved the Surface, I could notice and I'm afraid other users will notice as well.

Anyone else noticing this difference or is it just me?


This XKCD cartoon explains the recent Instagram issue.

Origin of Algorithm word

If you never read about the origin of the word, "The Art of Computer Programming" by Donald Knuth explains it:
The word "algorithm" itself is quite interesting [...] The word did not appear in Webester's New World Dictionary as late as 1957; we find only the older form "algorism" with its ancient meaning, the process of doing arithmetic using Arabic numerals. [...] historians of mathematics found the true origin of the word algorism: It comes from the name of a famous Persian textbook author, Abu 'Abd Allah Muhmmad ibn Musa al-Khwarizmi (c. 825) - literally, "Father of Abdullah, Mohammed, son of Moses, native of Khwarizm." [...] Al-Khwarizmi wrote the celebrated book Kitab al-jabr wa'l-muqabala ("Rules of restoring and equating"); another word, "algebra", stems from the title of his book, which was a systematic study of the solution of linear and quadratic equations).

Not only you learn about the origin of algorithm as well as of algebra.

On you will find a 1981 article from Lecture Notes in Computer Science recommended by Knuth, but it's closed to members. I'd be curious to read it, but did not gain access through MS corporate subscription to Springer.

Friday, December 21, 2012

Writing good code: be concise and do one thing

These are two good posts on guidelines about writing clean, good code:

What are some of your personal guidelines for writing good, clear code? (see Jason Barrett Prado's answer)

Rule of 30 – When is a method, class or subsystem too big?

Both posts touch a very interesting point: code length. One of the common indications of bad or confusing code is when you see lengthy methods, functions, classes. I remember seeing or hearing about methods that were 2 to 3 THOUSAND lines long, with these long indented if statements. What happened to them? Typically everybody avoided touching them if the original developer left. And if refactoring is not valued (and/or becomes more of a liability), nobody will ever try to improve its maintainability. That's why these tips above come in handy: forcing yourself to somehow limit the methods and classes goes a long way because it ends up making the developer think about abstraction and how to split the code.

The other important point in Jason's answer is single responsibility. This also goes a long way. It's a very simple concept, but many experienced developers still don't think along these lines. Have a method doing one thing, have a class doing one thing. When you read books like The Art of Readable Code or Clean Code and start adopting the mindset of having good names, then methods that do multiple things will start to become obvious. When that happens, flag and refactor them at some point. That will improve your code greatly as well.

Friday, December 14, 2012

Code Reviews: small and done by experts

I read a good article today on lessons on code reviews from open source software.

Contemporary Peer Review in Action: Lessons from Open Source Development

Unfortunately you need to be an IEEE member/subscriber to access, but if you do have access it, read these lessons.

The core idea is pretty much that: (1) reviews must be small; (2) reviews must be done by experts, otherwise they don't offer much value.

From my experience, most of the developers wanted feedback and took them well to improve the code. However, on the negative side, I've seen some techniques to work around the process in place to require code review - and that's where the purpose was defeated.

The main technique that I've seen is: avoid the developer that gives more feedback and send to an "auto-approver" developer. This is just the technique to bypass the process, as there is essentially zero interest in getting feedback and the code better.

Another technique is to send the review to newhires, with the excuse of ramping them up, but with the intent of not having the design or code questioned at all.

Of course, if a reviewer unexpectedly "annoys" the developer with valid concerns, just reply as "won't fix" and get that captured in a bug fix that will never get prioritized.

This issue becomes even more critical if technical leaders employ these techniques to "get things done".

How do we get developers not to use these techniques and do the right thing of sending reviews to the experts and wait for their feedback? I wonder if these developers are actually vested or just prioritize other things over the quality.

Technical Debt

Some great links about technical debt:

Are bugs part of technical debt?

Technical Debt - from metaphor to theory and practice (presentation)

Special IEEE Explore issue on Technical Debt (Nov 2012)

Must read if you're passionate about quality and has seen or heard some of the issues mentioned in these materials.