Anti-patterns: improper inheritance.

While examining some other code I’ve encountered a bunch of stuff which makes me wonder what they’re teaching people nowadays in school. Rather than silently complain about the problem to my co-workers, of course I decided instead to use this forum to rant.

Today’s anti-pattern: improper inheritance.

The problem: A class ‘ClassA’ is defined which contains two features–call them ‘feature 1’ and ‘feature 2’. A class ‘ClassB’ needs to adopt ‘feature 1’ in ‘ClassA’, but also add new features which are somewhat orthogonal to the functionality in ‘ClassA’, ignoring ‘feature 2.’

When a software maintainer comes around to change ‘feature 2’ in ClassA, he finds that ClassB breaks–ClassB was written in such a way as to hide or never initialize ‘feature 2’ within ClassA in the first place.

Why this happened: The software developer writing ClassB saw some of the code he wanted to reuse, but rather than deal with the problem of properly abstracting ‘feature 1’ out of ClassA, he instead took advantage of subclass-level visibility of the internal fields in order to bypass ‘feature 2’.

What the developer should have done: Take ‘feature 1’ out of ClassA and create an abstract super-class ‘ClassC’, then rewrote ‘ClassA’ and created ‘ClassB’ to inherit from ‘ClassC.’ Thus it’s clear that the functionality in ‘feature 2’ isn’t used in ClassB, and ClassB doesn’t have to rely upon supernatural knowledge of ‘ClassA’ which could be broken in an upgrade or bug fix.

What this illustrates: A class in object oriented design should be a self-contained unit of functionality. If a class is well designed, it should have well-designed extension points and a well-designed feature set which acts as a single unit.

When well designed, other classes do not have to rely upon super-natural knowledge of the implementation of a class in order to operate correctly; the implementation knowledge–while relatively transparent so that users can know how the black box should operate–should be implemented as if it were a black box.

When a subclass has to rely upon supernatural knowledge or relies upon knowing which calls touch certain internal states related to a feature that the subclass doesn’t want to enable or use, then this clearly shows the need to refactor the superclass.

Buzzword Compliance Library

So I’m looking at someone else’s code, and they make extensive use of a particular jar file. Time to poke around and figure out what that jar file is.

To paraphrase the info page, which should tell me what the library provides:

FooLib is an enterprise-class open source library to help deploy and integrate services in a service-oriented architecture. FooLib can help you decrease development complexity while improving end-user experience by coordinating business processes with unparalleled flexibility and reduce overall total cost of ownership.

In other words, FooLib is a module which helps my code maintain buzz-word compliance with most IT pointy-haired managers.

*sigh*

Overheard in a meeting yesterday.

“Why would you want to work on user interface? I mean, it doesn’t take a rocket scientist to build a user interface.”

Which is why most user interfaces suck: because while in fact it doesn’t take a rocket scientist to build a user interface, it does take one to build a good user interface.

Meanwhile, out in the real world, the iPhone continues to sell extremely well despite having fewer features than all those “better” phones.

A realization about web companies.

Web sites are like iceburgs: what you see only represents 10% of the actual work. And the majority of the work looks more like internal business application development in an IT department for a non-computer software related company–which it is: the 90% includes things like fulfillment, customer service, complaint tracking and auditing.

Which is why working at a place like Yahoo!, aside from the whole ‘college dorm’ feel of the place, is really no different than working for Wells Fargo or General Electric or Disney’s IT group. The work is essentially the same.

And it’s why so many developers are excited about AJAX: it represents the ability to do desktop development within the context of a web site. That is, it represents the ability to do something more meaningful with a web site than the sort of development you’d see in an IT shop like Wells Fargo–even though by and large, most web sites do not need to be “AJAXified.”

Things that irritate me.

So I’m looking through some source code and I come across an unsatisfied reference to a library. The import package name starts with ‘org.lwes’. Custom and convention says that when you name a package in Java, you use your domain name to your company or organization, but reverse it: thus, stuff I write for chaosinmotion.com goes into the top level package com.chaosinmotion. If I’m extra tricky (but I’m not) I would create a section on my web page for each component: thus, com.chaosinmotion.UITools would be documented at http://UITools.chaosinmotion.com.

So I go to http://lwes.org, thinking I’d encounter some package maintainer for some random Java tools package–only to be greeted with the message “Living Water International – El Salvador’s web page has moved.”

Given that the code appears to be an event system (I’d guess ‘lwes’ is “Light Weight Event System”), I wasn’t expecting to encounter the Living Waters-El Salvador web site. Grrrrrrr…

The failure of Silicon Valley.

Working for Yahoo! in Burbank, one of the first things that happened to me was the suggestion that I should be transfered to another team–and moved to Silicon Valley. There appears to be an overall theme here at Yahoo! which is not just a problem with Y!, but with other Silicon Valley-based software companies as well: and that is that as the Mecca of high-tech, all really good engineers should eventually move up to Silicon Valley to better serve their corporate masters.

I think this is a cultural assumption which is both incorrect and dangerous.

Sure, it would be very easy for me to land a job and advance very quickly within the hierarchy of any Silicon Valley company if I were not based in Los Angeles. I have no doubt as to my own programming abilities or architectural or (*shudder*) management abilities. And I know that there are so many opportunities up in San Jose which do not exist in Glendale.

Yet–I think this assumption is an extremely dangerous one for companies such as Yahoo! or Google to pursue.

First, a quick background about Yahoo!. Search marketing for Yahoo! was originally invented by a company called Overlook (formerly Goto.com), which was founded and built in Southern California prior to its acquisition by Yahoo! several years ago. Search marketing is essentially those little ads you see on Yahoo!’s search results page or Google’s search results page–and it is the primary cash cow for both companies. (A smaller cash cow is “Content Match”, the little box to the left or right of articles on places such as CNN which provide ads that appear related to the content of the article. But Search Marketing is the big cash cow, accounting for tens of billions of dollars overall.)

There is something deeply ironic to me that despite the huge brains in Silicon Valley, effective monitization of internet ads was done–in Los Angeles. (Google’s Ad Sense product was not built in-house but was also acquired.) Yet–and here’s the meat of my rant–even though the technology was invented down south, the prevailing attitude of the Silicon Valley crowd is that people in Silicon Valley are intrinsically more intelligent–perhaps around 30 IQ points–than their Lala land counterparts. And, of course, if you are bright, you clearly should move up to the City By The Bay where you can then help with the Internet Revolution.

This is a failure for several reasons.

First, one of the reasons why I personally dislike Silicon Valley is that it’s all tech, all the time. You go to some little cafe and the people in the next booth are talking about MySQL. The billboards and the office buildings all sport .COM names or tech company products. And while this is not in and of itself a problem, it does create a culture where distinctly “techy” and user-unfriendly products is considered normal, and where an average IQ in the 130’s is considered average.

Meaning products produced in such an in-bred setting are going to lean towards being overly “techy” and hard to use by your average non-tech-head consumer, unless you have someone like a Steve Jobs running rough-shod over the tech instincts of the developers there.

Second, by encouraging everyone to move to Silicon Valley, which has become one of the most expensive places in the world to live, you encourage people into a “must become millionare so I can buy a house” attitude which, while it may be a powerful incentive to create, becomes a destructive force at a company such as Yahoo! if, after working like crazy, rolls out a new product only to watch the stock price drop.

Silicon Valley has become its own black hole–sucking engineers into its environment, while creating an environment where it is assumed everyone is a tech-head, and where adding 20 extra buttons to a cell phone is seen as a way to create flexability and choice, rather than as a bewildering set of options that make the phone less valuable to its owners.

The Mystique of Google

No, I haven’t quite drunk the koolade yet here at Yahoo.

But I’m starting to get a better appreciation of the reality verses the mystique of Google and of Yahoo and of other search engines.

Basically it boils down to this: in the group I’m in, we sell advertising. Perhaps 25 years ago when I first got on the ‘net, the notion of advertising would be a bad thing. But today, when you get right down to it, we use the ‘net for shopping and searching for things to buy–which means that advertising is a natural extension of what we do. If I type in “dvd players” into a search engine, I may be looking for a dvd player to buy; perfect opportunity for Circuit City to remind me that they’re just down the street.

Now Google makes a ton of money. They make a ton of money because they have successfully driven a ton of traffic to their site. Google is comfortable with allowing their trademark to become a verb: we don’t ‘search’ the ‘net, we ‘google’ the net.

And they’ve made a ton of money by, well, by creating a mystique around how brilliant they are: Google has spent a lot of time talking about how brilliant their search is, how brilliant their developers are, and how brilliant their company is. And yes, at the time Google Maps was a brilliant early example of the power of AJAX.

But–I hate to say this, but search is a solved problem. Google didn’t invent search; why people flocked to Google was because it was a simple and easy and unobtrusive search engine. The ‘brilliant’ part came about later as Google spent a ton of time talking about search strategies–but every company uses different scoring techniques to score search results. Google happens to be much better at detecting certain technical terms: “web.xml” searches for the literal seven character string, while Yahoo breaks the term into “web” and “xml”, which gives completely different results. And Google happens to “hide” a bunch of goodies into their search interface–which is less about being “brilliant” and more about being “useable.”

In other words, Google has conflated “brilliant” and “useable.” And that creates the illusion that any portal is somehow “primitive.” Further, by leveraging this sort of “hidden” functionality, it causes people to learn how to use Google–and it creates a sort of psychological lock-in: if I need to add five numbers together, I can just pop up Google.

But this isn’t really all that “brilliant”, is it?

The people I’m meeting here at Yahoo are brilliant. Once you get past the fact that Yahoo’s home page is a portal–and I hate portals, I’ll readily admit–you find that Yahoo maps are pretty cool, Yahoo mail beats Google mail, aside from the fact that you are welcomed by a damned ad, and Yahoo Groups has a lot more functionality than Google Groups. (Google Groups suffers from being too simple: a good interface should be simple, but not too simple.)

I’m not saying that Yahoo is better than Google–what I’m saying is that the illusion of Google’s fundamental brilliance is just that: an illusion. Web technologies by Yahoo or Google or MSN or Ask.com are far more sophisticated than the typical small-shop web store tech done by someone with a basic shopping cart–and it is far more sophisticated than this web site’s Wiki and Blog.

But it isn’t a hell of a lot more sophisticated than desktop programming. In fact, I’d suggest that, while as sophsticated as our advertising network back-end (Panama) is, what makes it hard is keeping the components simple so we can quickly react to new frauds. There are certainly fewer moving parts in Panama than in Photoshop, for example.

This is an interesting business. But look to me putting a multi-threaded B-tree implementation in Java up on the Wiki in the next month or so–because while the business is interesting, it’s not all that technologically interesting.

Books I’d like to see.

I’d love to see someone write a book on the “trial and error” company. Because that’s what most web companies really are: once they get a web application up on the web and start attracting customers, they can quickly use the statistics they gather as to how users reach their site and how they use their site to make adjustments quickly to make the customers happy.

Of course in a sense all companies are trial-and-error companies. Unfortunately most non-web based companies use customer support as the primary source of feedback from their customers, but rather than consider customer support part of the development process or part of the feedback process, companies seem to treat customer support as a necessary evil, as a cost center to shut the customers up.

Dry Run, and Fun Gadgets

Today I tried a dry run, testing out my new bicycle to ride into Yahoo Burbank. I also equipped it with a Garmin eTrex Vista CX GPS on a bike handlebar mount, so I can figure out which side streets to take and know my altitutde and speed.

Six miles, and when I got to Yahoo, I was beat to hell–I know I’m out of shape, I’m not that out of shape… But the Garmin told the story: the first mile was a 350 foot drop in altitude, which I knew about. But the last four miles and change was a steady 400 foot climb–which means that while the ground seems somewhat flat, I was working for those four and a half miles. I wasn’t just coasting along supplying energy to beat wind resistance.

Lesson of the day: I’m going to have to take a change of clothes so I can shower when I get to Yahoo–at least until I get into good enough shape that bike riding six miles is a no-brainer.

(Yes, I know; there was no programming content. So to compensate, I give you the Yahoo Developer Center on JavaScript, along with the best book I’ve encountered so far on AJAX: Ajax Hacks from O’Reilly.)