More on The Myth of SLOC

Wow, this has been a LONG time coming, but between finishing up my MS in CS and work I've been a bit busy.

SLOC and other metrics, like coupling and complexity metrics are just proxies for the only "metric" that really matters. The best name that I've got for this metric is "clarity of intent". It's nothing Earth-shattering or particularly easy to measure, but it's what really matters. It all boils down to how clearly does the code that you've written express what you want the code to do?

Clarity of intent is why we name our variables things like "numOrders" instead of "doggie". A lot of languages fall short in this regard, in different ways. Java, for example, makes you repeat yourself a lot like in the declaration for an ArrayList; ArrayList al = new ArrayList()

Other languages (in particular, dynamically and "loosely" typed languages) tend to fail in the other direction, leaving you with declarations like

something = doSomething(someThingy);

In my opinion, this is one of the biggest failings of a lot of the dynamic languages like Javascript and (at least the last time I checked) Ruby. Functions and procedures take one or more "thingies" and there's no easy way to say, in code, "This thingy must have bark() and playDead() methods". Sure, you can say in comments, "Hey, if this thing can't bark and playDead, I don't want it", but there's no way to have the compiler check that for you.

A lot of languages, like Java, go too far in the other direction, though, and say "This thingy must extend/implement Doggie" when what you really want to say is "This thingy needs to have behavor similar to a Doggie, but if you happen to have a Rubber Duckie that behaves like a Doggie, that's cool too".

A good language will let you say very clearly what the prerequisites are for a method and makes it clear what you intend to do (with features like list comprehensions or map/filters instead of dealing with iterators for everything).

Two approaches to products

There are, or at least seem to be, two distinct approaches to developing products. The first is to develop products that people need, whether they know it or not. These products may not be pretty or particularly fun, but they are the things that you absolutely need, whether you know it or not. People almost never love the products produced by companies who follow this path, but they'd be lost without them. This is what Google does, and it's why some of their products change everything and others flop completely.

The other approach is to build beautiful products. The kind of things that people love and feel they absolutely HAVE to have. These products may be "game changers", but they rarely make any really major impact on the world (not counting the obvious commercial impact). Apple falls firmly into this category. They can produce a product that's laughably inferior, but it's so blasted pretty that people will rush and line up to spend massive amounts of money to buy it. It's as rare for products in this category to not be huge commercial successes as it is for the products to meaningfully change the world or anyone's life.