Blogging Ottinger (tim)

This is about object-oriented software design, not getting money from relatives and admirers. If you didn’t get that, then you probably aren’t interested. Or you’re Kim.

In object-oriented design, inheritance is one of our doctrinal distinctives — the things that make us different from non-OO design. But there’s one thing that many designers don’t understand about inheritance… something that would revolutionize their whole approach to OOD and improve their work products by maybe 20 or 30 percent. This little secret is not so obvious, and many OO masters and OO dropouts realized it at the same time. Whether they learned to cope with it or not determined whether they would master OOD or fall off the map. I’ll give you this little tidbit for free:

Inheritance is evil

Well, not exactly, but it’s sort of true. It is to be avoided whenever possible.

Inheritance really has two forms: code reuse, and Liskov-style substitutability.

The latter is acceptable in statically-typed languages because it just has to be so. It’s sad. Programming in statically-typed languages is rather like eating pie in a ski mask. Oh, you can do it, but it’s messy and harder than it would otherwise be. If you have to use statically-typed languages, then you have to deal with that. It’s only in the C-like languages that inheritance creates polymorphism, and they’re the weaker for it.

In the former case, it’s sad. I think that the best way to share code between two modules is to put the code in a third module, and call it from the first two. Inheriting is the worst way. It must only EVER be used for extending (adding to) classes, and never for restricting. Inheriting should only be used when ‘has-a’ fails to satisfy and the only alternative is copy-n-paste (an even greater evil).

If you can change your design to work through composition instead of inheritance, you’ll find that many dark corners in your design will simply vanish. The code becomes more flexible (surprise, that!) and much more easily comprehended. The downside of composition is that whole demeter thing, but we can talk about that later. For now, be pleased to have suddenly learned one of the big design secrets of the century.

The other big secret is that class design is subordinate to object design, but we’ll cover that again later.

There is another (always another) interesting article at dying church about life in post-Christendom. I found it interesting and hopeful. It’s true that while we were looking the other way, the world changed. I have to take my hat off to these guys. It took guts to turn your back on ABCs and look after the original mission again. I have to see if I can find a church like that near me. I could see learning from such fellows.

I really was impressed by XBox Linux, and not just in an ironic sense. I think it’s probably a good idea to have such a low-priced machine for a desktop or entertainment center. It’s got pretty good specs, and it’s dead quiet. It’s hard not to be drawn in by the $250.00-ish price tag. Of course, you hope your unit doesn’t catch fire (I understand that they fixed the electrical hazard in the cord).

Well, now they have something like that going for XBox 360 Linux. A guy’s gotta wonder what kind of a Myth TV client it would make. And that’s cool if you can still play the occasional game on it.

I’m not crazy about having to buy additional hardware to enable DVD playback. I hope that the linux version is better for that. But I wonder if it wouldn’t be worth buying one as a TV-connected Linux terminal.

For the second time since we moved, dear friends drove over 4 hours to come and see us. This time two families came up and provided our Thanksgiving feast and a lot of laughs and company. Not satisfied with merely cheering us with food and company, they also settled ud into the house some more, and also gave us gifts that will come in handy in the next month. It was so nice to be surrounded by our friends. The house was happy — it’s really made for entertaining, and roomy enough for extended visits.

We’re really feeling at home now.

Olivia: have a braveheart.
Logan: practice makes perfect!
Daisy: good girl!

Friends: thank you sooo much. God love you and be with you.

I switched pod catchers today. I was using one cleverly named “podracer” before, and have switched to ipodder “lemon”. I have to get used to the idea that files aren’t stored in date-specific directories, but I think overall it will be a better choice. Funny enough both of these are Python programs. iPodder is one that uses the great cross-platform library wxPython. I played with this a while back, but never seriously did anything with it. Well, other than a little app we used to monitor a machine at ITW Micro-poise (rip).

Anyway, in case anyone cares, I thought I’d mention the program. It looks good, seems to work, has nice features. It doesn’t automagically fill up my mp3 player for me, but it does pretty much everything else. I tried to upload my opml file, but my blog host didn’t really want me to.

From Dying Church comes an interesting bit on detoxing from the church.

I heard a Dave Winer interview via nerdtv, and then was prompted to find and post a link to the old Bill Gates v. The Internet article. And so I have.

I found an article about the recording industry. Of course, I found it via SlashDot. I think it has some interesting numbers about file sharing and the democratizing effect of file sharing — how it creates a more inclusive environment and only really harms the few heavily promoted bands at the top of the RIAA pyramid.

Interesting. Maybe Dave Winer is right when he says that the future is in those technologies where “users party with developers” — where developers and users are invited to participate and extend or improve the system. Here we have a system that allows more entry into the music industry.

I think that it’s necessary that the market be given an alternative to the RIAA-controlled artists, and the public is given an alternative to being controlled by RIAA. I would prefer to see this in the form of artists using alternative channels (including free file-sharing networks and sites like Epitonic and PureVolume) to reach their audience.

I look forward to more independent and even well-recognized artists embracing the P2P file sharing networks, file sharing sites, and independent promoters. I think that technology that connects artists and their public is a societal good, and a reasonable market adjustment.

I don’t encourage lawbreaking, but it would be wonderful if more artists find their public legitimately and legally without going through the RIAA bottleneck.

Reading about Windows Server Sales is pretty exciting, until you remember one thing: If all the world used free Linux and BSD, and only one shop on the planet bought a copy of Windows, then Microsoft would have 100% of the server software market in revenue.

I think that one thing we’re seeing is that people are realizing that there’s little need to pay for commercial offerings when debian and Ubuntu (a Debian-based product) and the various forms of BSD Unix are available without cost (and therefore without reporting). Of course, if someone uses a free Linux or Unix, then they won’t be reporting how many copies they use.

Another factor may be that you can’t buy computers without Windows. I own two laptops and four desktop computers. All of them run Linux, but most of them were sold with Windows preinstalled. By revenue and by copy, I am a Windows shop. This is despite that fact that I don’t own a single copy of Windows. I didn’t even keep the OEM copies. I think I threw them away.

I don’t know how much these factors come into play, and I agree that M$ having almost 40% of the market (by revenue) seems significant. Of course, I don’t know what that really means, and I don’t suppose anyone else does.

I found an interesting article at ZDNet (uk) about the FSF working in the Microsoft EU case. Wouldn’t it be funny if the “secret” is that the code is obvious and ill-conceived? Or that it was proven that the only reason they’ve been changing it was to shut out Samba?

For my buddy Steve, and all the testing professionals I know, I have this article called testing revolution. I thought it was a nice article that neatly addressed a lot of misconceptions in short order.

This is probably the most obvious news article ever.

The Digital Millenium Copyright Act and had the support of almost nobody other than a few monied interests, so we shouldn’t act shocked when we find that the DMCA is abused by corporations to compete, instead of being used to promote commerce and sharing of content.

I’m not surprised because I’m not stupid.

I guess that everybody else has blogged this, so I might as well do a me-too.

Microsoft got it wrong in a very public way, and are hopefully feeling embarrassed. If not, it may be that they are trying redefine TDD to their advantage. I hope that they’re just clueless, not being intentionally selfish.

I’ve gotten rather familiar with a few programs which help to make my absurdly-long daily commute time a little less unpleasant.

One of them I mentioned before is SlashDotReview (to whom I can say that objects are now a little further away than they once appeared). This is still a nice slashdot summation with tasty indy music every day.

Speaking of music, I’m moderatly addicted to The Portland Jazz Jams. I’m learning more about jazz and music through this program, and I’ve always loved jazz. It’s sweet stuff. Sometimes it’s interviews, sometimes it’s playing, and sometimes it’s the coveted guitar talk.

Third is a strange little podcast called the Linux Link Tech Show, where I enjoy all kinds of interesting banter about “unreliable bash scripts” (I agree, a dumb string of words) and various problems in the industry. I like that they don’t whitewash problems with browsers, macs, skype and even asterisk on the show. There is software that works for them, and software that does not. They don’t bother editing out the problems and mistakes.

These are just good drive-time company. There are perhaps more and less uplifting work out there, but these are quick becoming some of the staples of my week. Thanks for all the hard work, podcasters. Keep it up.

Well, I spent another week in windows (with a week-long gap between the two windows weeks) and I didn’t die or catch a disease or anything. I did relearn how much harder and less consistent it is to get things done (installing software, editing, etc). I think it’s easier to stand if the environment you use includes Resharper along with MSVS, so it’s not so bad. From the command line, we have cygwin (yay!). Messaging is done with trillian or gaim, and browsing and email use those wonderful mozilla products., and of course a copy of gvim. Let’s not forget version control through subversion (svn) and acceptance testing through Fitnesse.

Trillian, Resharper, Nunit, svn, cygwin, and Fitnesse are standard parts of our environment. We’ve also added TestDriven.NET, which is pretty convenient most of the time. Overall, it’s a pretty decent environment. I’ve only had to reboot a few times(!!) and have crashed Visual Studio twice. That I know of.

Well, I suppose that’s fair. I generally like Linux mostly because of all the good tools present there, not just because of the kernel (which I really don’t know much about). In fact, I tried to make a pretty major kernel upgrade and messed up my laptop. I am typing this via the Mepis Live CD while backing up the selfsame laptop onto a larger computer prior to fixing it. Since I’m running on a live CD, I’m not worried about using it while backing up and preparing. The big difference between Linux and Windows is that I had to do something risky as the root user to crash Linux. Windows dies in normal use.

Anyway, I made it. I am learning an optimization pyramid of sorts. The worse thing is to use the mouse. The second worse thing is unnecessary keystrokes. It seems that following these rules helps you to develop a bit more navigational speed and efficiency. Heh, who knew that Emacs and Vim were right all along?

Shortly after the move, our orange tabby (named “buzz” for Buzz Lightyear — my youngest named him) fell victim to his curiosity and that dreaded “sneaky gene” that makes cats do stupid things just to see if they can get away with it. He dashed out the door to freedom and was gone. We did our due diligence in searching the neighborhood, looking for a local humane society, etc. We thought he was a goner.

On the fourth day, he suddenly appears at the back door, no longer a casualty of the move. Oh, he’s been cold and hungry, but seems to be perfectly intact. I’m surprised he found his way back — he’s not the sharpest tool in the shed.

I’m again the owner of both a small dog and a decent-sized cat, and must again get used to closing the pantry door, quickly storing or discarding leftovers, and all of the other cat-management maneuvers common to cat owners. The youngest boy is happy, and the little dog is thrilled — both have resumed playing with the cat. Oh, and the cat seems happy with the warm place to sleep and consistent meals, not to mention affectionate attention.

What do you do when you’re in a new project, and you’re sitting with a requirement in your hand and an unfamiliar code base in front of you? Navigation is a tough game. One can spend a lot of time just trying to find the place in code where the work is to be done, and then finding the tests which are relevant to the change being made. Even with some help, it can take some time.

Sure, if all the code is yours, navigation is trivial. You know where to go without thinking about it — you’ve internalized the entire design and probably much of the code base. You know where it is done, how it is done, and the names of all the participants. The tests are obvious and the code is trivially easy to read. But to the outsider, naming seems somewhat arbitrary and structure is inobvious. It’s the non-internalized condition. It really doesn’t matter how good the code really is, it’s how it seems.

In Are Your Lights On?, G. Weinberg said that a problem is the difference between things as desired and things as perceived. Therefore we can either change your perception or your desires, or change the way things are (or some combination of the above).

Let’s take a poor example (for illustrative purposes only) and see if we can’t see a few different positive possibilities.

In our example, a homemaker puts forks and spons in seemingly random places in the house. They all make sense to him, but they are found in ones and twos in magazine racks and bookshelves, cabinets, refridgerators, television stands, etc. The homemaker knows exactly where every one is found, and can prepare and eat meals in comfort. An observation is that the implements are placed in a way that makes it hard for a visitor to find them. That is just a fact, neither an accusation of the homemaker nor a slur on the intelligence of the visitor. Just a fact. Lets start there.

Certainly, one can blame the implement-finding difficulty on poor organization, but it may be perfectly reasonable. Perhaps the measuring implements are close to the supplies which need to be measured — in the pantry, in the cabinets, etc. Or some large measuring tools are kept with large storage and cooking dishes, whereas small measures are kept with food items used more sparingly (cinnamon, for instance). The items used primarily for eating ice cream are stored in the homemaker’s living room, where his ice cream is usually consumed (in front of a TV). So it is neatly arranged according to use. In this case, the visitor is only confused because the system is unfamiliar, and the visitor could learn the system behind it given sufficient time. This is rather like the expert-friendly editors (vim, emacs, etc) which are uncomfortable until one has paid his dues by memorizing enough of the commands and command structure to become proficient. Such a system can be quite comfortable to one who is proficient. Code can be arranged in a way that is convient for some and not for others.

One could blame the homemaker for making the system novice-hostile. It is an idiosyncratic arrangement, and out of the norm. Usually serving utensils are kept together, table utensils are kept together, and measuring utensils are kept together. Often these are three different places all in or near the kitchen and dining room. This is what one would expect to find. Having flatware all over the place makes it hard to find the parts you want, and hard to put them away after washing. A commonly-used arrangement is more pleasing to the novice, but may be less well-tailored to certain ways of doing things.

Now, the homemaker could put all of the flatware (serving, measuring, and table-ware) in the same drawer, and that would make it a mess, though it would be easy enough to learn the system. It would be easy to put them all away after washing, too. But it’s not the normal mechanism, though it’s simpler. It’s not optimal, though, because one has to dig out the measuring tools from among the rest when cooking. Then he must dig out the serving utensils to put the meal on the table. After that, he must dig out the table utensils from among the jumbled mess. It’s hard to tell if you have enough tableware to seat 4. Some simple ways are worse.

Probably the best thing for a novice is to keep patience and try to learn the system in use. It could be excellent, it could be horrible, but when you don’t know what it is you can hardly judge which it is. It could be very carefully planned and orchestrated for special use, or may be oversimplified. It’s hard to tell. It’s not the time to write off the code as poorly organized, nor yourself as a slow learner. It may just take time.

The least productive thing is to criticise the productive team already in place. After all the goal is to join them and learn from them. Joining late requires humility and patience from everyone. Being disrespectful or accusational simply doesn’t pay. Besides, the haughty man is the man who thinks he has nothing left to learn.

In dealing with unfamiliar code what is needed is just some basic backgrounding and some experience taking advantages of the navigational aids. And more self-control and maybe more rest. Impatient people spend a lot of time being frustrated, and being frustrated is exhausting. Just ask me, I know.

May we be granted equal parts courage, patience, and wisdom.

I’ve been working in unfamiliar code, and it has me thinking about navigational aids.

In Linux, I’d be using exuberant ctags and gvim and grep and perhaps a few other text tools. Ctags builds a nice index and vim can use them to jump from file to file and method to method (class to class). When you add window-splitting multiple buffers, and vim’s built-in directory navigation, it’s not a bad system. The Emacs guys had a whole IDE built into their editor.

Now I’m looking at VisualStudio and Resharper and those have some nice navigational aids as well. Some of the nicest are those provided by resharper. I can press ^N to popup an entry dialog, where I can enter a class name (with wildcards and intellisense) and it will take me to the class. This is a lot like the :tag commands in gvim. Another trick is the ^B to go to the item under the cursor (like ^] in vim). Of course, it’s handy sometimes to grep the tags files too, and I don’t know a good replacement for that. Of course, these are mostly good when you know what class or method you’re looking for.

When you don’t know, it’s a little harder. There are find/find-in-files options, and the search scope can be set for the whole solution. Not too bad if you know what to search for. One can use the navigation aids to also search to base classes, derived classes, or callers. This is nice stuff. Sometimes I yearn for some kind of tool that could derive diagrams, maybe showing inheritance trees, but more often it would be useful to showing instance arrangements (object diagrams) as drill-down points. Sometimes seeing the runtime arrangement of objects is the best starting point. But otherwise, these are pretty good navigational aids.

Still it’s not always enough — sometimes there is plenty of information you have to hold in your head. If you don’t really see the structure, it’s hard to know what to look for and where to look for it. But that’s a different story.

this is another post I made just to keep from losing it.. I should start using delicious instead.

What a mess. I was going to give details, but my friend Jeff has beat me to it. I’m just glad they’ve pulled the CDs. I love music. I listen quite a lot, and deeply enjoy the various flavors brought by different artists and genres. I would be a tremendous music consumer if the RIAA folks would just get back to the business of connecting the artists with the fans, instead of trying to capture and dominate both. At this point, I feel like buying new CDs is a lot like giving cash to a begger — I’m not sure it’s really helping anybody.

This is my second week on an intentionally, officially agile project, and I find that the planning game and various other practices are not too difficult to adjust to. The environment is not entirely familiar, but is not too bad a challenge (C#, .NET, SQL Server, Windows), though I still prefer Debian Linux for usability and maintenance reasons (and ease of software acquisition & install).

It is hard to express how much the personal productivity practices are based on verbal communication (a bit of a pain to visual learners) and on having an environment set up so that you get a “green bar” (all tests pass) as frequently as possible.

The worst part of adjusting is that there is a lot of navigation and context switching to do, more than I’m used to. I’m beginning to get it, but it’s bewildering sometimes. First you have a feature in mind, and then you have to start with an acceptance test. Not the whole test, but only enough to get a failure. To start the work that will pass the test, you have to start with a unit test, but only enough of a test to generate a failure (compile fail or execution failure). So you have feature:Test:UnitTest so far on the stack.

Now, to write the unit test, you probably will have to create some mock objects. Now it’s Feature:Test:UnitTest:Mock — then Feature:Test:UnitTest:Feature — but you only write enough of the feature to get the snippet of unit test to pass, and no more. Then you write the next unit test that brings you a little closer to passing the acceptance test along with more mock objects or more changes to the mock objects, and the code that passes the test. By this time you are running around in four or five files at the same time, and have to keep track of mock and real objects, unit tests, and acceptance tests. When you’re used to it, you can do it in your head (if my coworkers are good examples). When you’re not, it’s mighty inconvenient.

I spend so much effort in locating and navigating among files, I can forget where I am in my process — what test is at the top, where we are in the progression of unit tests, etc, what is left undone and what is yet to do.

Well, that’s not all that there is to it. After you get the unit test to pass, then it’s time to consider refactoring to eliminate duplication, so it’s Test:UnitTest(s):refactoring(s) — but of course all the refactored code has to be tested. So you may be writing tests to prove the refactoring which was written to manage duplication between two unit tests, of which at least one was a step on the path to passing an acceptance test.

When you don’t know the code base, this is triply bewildering. If you don’t understand the feature you’re implementing, it’s worse yet. If you don’t know the editor very well, it’s a bit hard to watch other people. Worse, if the development environment only lets you look at one file at a time — because you have to flip the screen between file tabs, examining the file names in the tabs to find the one you want to go to.

It gets better. It’s getting better. However, this is the one real difficult part in getting a real agile mindset, and you don’t get it without immersion. It’s asking a lot of a brain to take it all in at once.

The rest of the struggle is collateral damage, being in a lesser editor in a lesser operating system.

I really miss gvim, with multiple windows tiled horizontally and vertically, and editing without having to mouse around and use function keys. The visual studio editor is awful, but the resharper tool is sure nice. Bookmarks stink, and I’ve not learned to record and replay macros yet — something I live by in gvim. Someday I will be good at VS.Net, though I doubt that I will like it. One holds one’s nose and tries to get along.

It’s worse, of course, because the Windows system has a single desktop is not very pretty or productive. It is much more stable than it used to be, at least. Subversion is much slower than it is in Linux, too. That hurts when you use it all the time.

No wonder I’m so tired at night.

I am posting this so I don’t lose the reference, but I found a nice reference to Amdahl’s Law with exposition. If you’re geeky enough, and interested in CS, you might find it very interesting. Otherwise, don’t bother.