Blogging Ottinger (tim)

I found some good work from a fellow named Scott Johnson (no, not the one who knows me). Not only is it good advice for developers, he was kind enough to provide a link to my little naming paper.

What was I thinking? I completely forgot to mention the Taylor T5!!!! I love Taylor guitars. That’s another specialty I want to save up for. Nothing made today sounds like a Taylor and feels like a Taylor. Well, maybe an Olson. This new T5 looks like something really special, and I’ve seen some video with sound demonstrating it. It’s a very tasty sound. I’m going to have to find some place I can try it out.

I still want a triple-voiced Godin, though.

I tell my kids that no matter what you think you are doing, you are building your reputation. For better or worse, your life is being averaged by the people who observe it, and trends are being measured.

The self-promoter often sees credit and credibility as a zero-sum game: “more for you means less for me.” He makes deposits in his own credibility bank whenever possible, and cuts off the opportunities for his coworkers to profit (cred-wise) from their participation. Granted, anyone might be tempted to try to build their reputation by advertising their skills and contributions to their bosses and clients, and maybe to the programming world at large. However, it is best to let others praise you, and not your own mouth.

In some realms of business taking credit is not only tolerated, but praised and encouraged. Some bosses like to maintain a shark tank, and consider devaluation of coworkers to be the tactics of the smarter predator. Generally, only weasels and sharks really appreciate and applaud other weasels and sharks.

It’s unpleasant to work with the guy who is trying to convince the world that every good idea was his idea, and everything that turned out okay was part of his master plan. Even if he is a smart guy and a good contributor, his self-involved and boorish ways devalue his team members and break down morale.

Your work may be brilliant, or you may instead “take one for the team” by doing the grunt work, but either way you know that he’s going to take his opportunities at your expense. There’s no real motivation to work hard if you are going to be considered “assistant undersecretary to Mr. Takecredit.”

Software is a team sport. You have to be a team player. You write your code for the use of the team, you participate in the local coding standards, you freely donate your ideas. Whatever you do becomes part of the team’s story.

Team work is submission. You submit your ideas, your effort, and your ego to the work. You “lower yourself” (check your ego at the door) to become just another peer among equals. The team decides. The team implements. You’re just another guy who did his best. Your reputation is determined by whether people want to work with you or not.

Most of us find that most of our job offers come from people who want to work with us again. Our investment in our coworkers often is returned with interest. Would we have those job offers if we’d treated other people as our supporting cast (or worse, obstacles to our career path)? Every person you step on is one more person voting against your success.

The best reputation you can have is to be a solid contributor and a good team player, teaching other people to contribute their best work, and allowing them to feel valuable in return. If you do this, developers will love you and will recommend you. There is credit and blame enough to go around in the world. The recommended path is to try to do good work well, and to try to help your co-contributors to add their best work to the collaboration.

If you’re stuck in Takecredit’s project, just remember one thing: “time wounds all heels.”

—-
I found this while looking for “good citizenship” information: http://www-128.ibm.com/developerworks/websphere/techjournal/0508_col_johnson/0508_col_johnson.html

Squid.

I’m dreaming of a new Godin to play with. I tried one at Guitars N More in Castleton, and kinda fell in love. The triple-voice versatility is amazing. I liked it clean and distorted, finding it to be a pretty nice little jazz guitar or a rocker. The acoustic sound from the piezo was a very credible acoustic sound. That’s a lot of versatility in one box. I think that I’m saving that investment as a personal reward when I do something really good for my friends or family. Or when I make a major milestone like having a good grasp on music reading & theory.

In earlier days, the big versatility guitar was the Gibson ES-335, which in the hands of a true master may be the sweetest guitar on earth. It could play classic electric hollowbody sounds, or scream along on rock leads and rhythms. I’d still like one some day. That will be my midlife crisis guitar, my version of buying a porsche.

The new Ibanez ArtCore guitars are looking sweet. One of them could be my ‘road’ guitar. If I had the Godin or the ES-335, I’d be afraid to take them out of the vault. A lower-end hollowbody with good pickups I could play wherever I go.

Look at this guitar and tell me you don’t want one. Really, now.

Take OAOO (Once and Only Once), for instance. It seems obvious enough, but almost any code you find laying about is aswim in copied or retyped idioms. Is OAOO claptrap or good sense? Is it just XP craziness?

OAOO has received treatment under other names like DRY and SPOT (Single Point of Truth). It even gets a solid mention under Third Normal Form.

One could argue that it is a purely aesthetic issue, that it seems to suit some person’s sense of “good” or “right”, rather than actually serving a team’s use of the code. You hear the same argument about OO and Structured Programming (in particular, single entry/single exit programming). Indeed, every software discipline is attacked as “preference”. In the sense that it is possible to write code without using any discipline at all, I suppose one could say that writing clean, working code is a preference.

On the other hand, single-entry/single-exit helps with debugging and tracing, since you know that a debugging message or breakpoint set just before the return will be hit on the way out. It also helps with cleanup of resources (though try/finally is better and RAII works in C++). It has been a useful discipline for many years, partly for these reasons and partly for more mathematically-driven reasons (See Dahl, Dijkstra, & Hoare).

Likewise, there are perfectly good reasons to follow OAOO/SPOT/DRY in code. Most important is the principle that you want a single point of maintenance. This is why it is better to have a single implementation of Stack (in templates or generics) than to have a dozen implementations, hand-written for each type that might appear in a stack (int, double, string, structs, classes). The more similar code is repeated, the more maintenance points one has per function point. This is far more than a matter of preference or aesthetic. It is a matter of making code that can survive continued change gracefully or making code to which every modification becomes a tedious search and replace operation. It’s a matter of finding points of usage with grep or searching with human eyes for every repetition of an idiom.

Let us ignore the evidence for a second. If it were merely a matter of aesthetics, would you rather write code that the industry finds appealing, or that the industry finds revolting? Shouldn’t code be something you can enter into easily (well, as easily as possible)? Shouldn’t your peers find it simple and clean? Should the people who pay for the code be pleased with they code they receive? If the aesthetic is generally agreed-upon, perhaps the default stance should be to follow it until you have evidence that you have a more excellent way, rather than rejecting it out-of-hand.

There are enough in the Christian who understand the free content thing. It is a way to get the word out, whether the word is the Word or just that you have a band that’s worth listening to. Here are a few recommended podcasts.

I recommend Thru the bible by J.Vernon McGee as a standard. I like the old fellow, and appreciate his thoughtful treatment of scripture. He’s been gone a while, but his work lives on in syndication and podcasts.

I also recommend A Word from the Word as a bite-sized examination of a word in its original biblical context.

I’ve also listened to Let My People Think by Ravi Zacharias for some time. Not enough to wear you out, but a good message well-delivered.

I’ve subscribed to others, but I don’t know how good they are yet. More later.

I’ve started subscribing to the podcast from Radio Memories.

This is a very nice service. When I look for files do download via gnutella or the web, I tend to look for series I already know and love. I have lots of The Saint, The Shadow, Fibber McGee, etc. What I don’t do on my own is find stuff that I don’t know but would like to hear.

I am pulling down a few OTR podcasts now, and loading them onto MP3 players. I would have barely been able to stand my air travel and layovers without them. I’ll probably be moving to an even bigger mp3 player when I move in order to make the most of my commute.

I’ll list my current OTR podcasts here, and the Christian ones in a separate post.

http://otr.libsyn.com/rss
http://www.botar.us/real.rss
http://radiomemories.libsyn.com/rss
http://www.godcast.org/categories/drFloyd/rss.xml
http://x.otr-tnt.com/otr-tnt_WeeklyPodcast.xml
http://home1.gte.net/bookies/OTR/rss.xml

The folks at The ZTechShop have put up a nice tour of linux site. Sort of the nickel tour of graphical linux apps.

It’s maybe worth a look if you are wondering whether you should be interested in a completely free, completely shareable (copy for your kids, neighbors, parents), operating system that really works. As opposed to that old and busted stuff that came with your computer.

I have always thought it would be cool to have some way to keep up on techie stuff and be entertained while driving to/from work. Now we have podcasting, and it’s hard to figure out what not to listen to.

I’ve gotten mildly hooked on Slashdot Review, a fun little podcast with news and featured music. It’s nice and short (a good thing for a podcast, IMHO), and the music is always tasty. Not like we don’t all read slashdot every day anyway.

Free software is not entirely trouble free, especially on the cutting edge. Policies of freedom and practices of projects don’t always align in convenient ways, and sometimes you just have to wait a little while.

My task was to get basic mono C# with NUnit running on my Debian “sid” laptop. It doesn’t sound so hard. I figured I wanted to have NUnit running right away, since I didn’t want to even go exploring without having some kind of unit tests. I figured on using some Object Mentor design exercises as fodder.

I decided to start with monodevelop IDE. I wanted it to help me not do stupid things, if only by omitting options for doing stupid things. I agonize over that for a little while. Maybe it would be easier to work from the command line. It probably would be simpler, and I’d know more about the command options. I give in to my baser instincts and allow monodevelop to help me. I hope it won’t hurt me.

I started a project, and added “using NUnit;” to the sample startup code. If it compiled and still printed “hello world”, I’m be on my way. Of course, it did not. Hence the wisdom of taking baby steps. NUnit isn’t found. Reasonable. I didn’t add it to the project. Minor UI difficulties ensued. I couldn’t see the project tab because the doc tab was open. When I closed the doc, I could see more stuff. I don’t know if I missed a clue or what. Maybe it told me the project was behind the doc, in a separate tab or something. I don’t know now.

Okay, I edit “References” (I’ve read enough web pages to know that’s what libraries/assemblies need) and don’t see NUnit. Thats odd.

[0]tottinge@inigo:~$ locate dll | grep -i unit
[1]tottinge@inigo:~$ locate nunit
/usr/lib/monodoc/sources/nunit-docs.source
/usr/lib/monodoc/sources/nunit-docs.tree
/usr/lib/monodoc/sources/nunit-docs.zip
/usr/share/doc/monodoc-nunit-manual
/usr/share/doc/monodoc-nunit-manual/changelog.Debian.gz
/usr/share/doc/monodoc-nunit-manual/changelog.gz
/usr/share/doc/monodoc-nunit-manual/copyright
/var/cache/apt/archives/monodoc-nunit-manual_1.0.6-3_all.deb
/var/lib/dpkg/info/monodoc-nunit-manual.list
/var/lib/dpkg/info/monodoc-nunit-manual.md5sums
/var/lib/dpkg/info/monodoc-nunit-manual.postinst
[0]tottinge@inigo:~$

What do you know? No NUnit.dll at all. I have docs galore, no nunit. How does that happen? Oh. Looks like it’s not all packaged.

I look up the maintainers’ email and send a note. Today I got back an email with this reference. I see. Okay, I don’t have a problem with the policy. However inconvenient and frustrating it is, I can see waiting for the NUnit project a little longer. I just hate learning a new language without unit tests.

If I were in the midst of a big project, and had a mandate to use C#, this would have been trouble enough that I’d have pulled down mono and built it from source. I guess that’s not a bad direction to go for now, and I’ll remove it later when the packaged NUnit is available.

These two free projects (mono and debian) don’t agree on how things should be done, and each has the freedom to go a different way. A user has the right to follow one, or the other, or to switch between them.

The lego sculpture of Amy’s churchis the most amazing thing ever. The Cathedral is pretty close, though.

One of my teams of students, curious about the value of the topic mapping, undertook it as a short analysis step for an exercise today. I was grateful that his team was willing to try it for me. The team completed the exercise at least as well as any other team. The time spent on the mapping was fairly minimal, so we can say that it was at least not an expensive extra step. At the end of the exercise, the team had one regrettable decision in structuring the otherwise good design. The team’s informal spokesman told me that the same issue had arisen, and had been resolved differently (more correctly) in the topic map that he’d drawn.

Not only did the topic map match reasonably with his actual design, it was superior in at least one way. This gives me more hope that there could be a more sane mapping from problem statements to designs, provided that you have good problem statements.

I am mindful that any analysis of the text of a problem statement cannot be superior in content to the problem statement itself. That was one of the problems with noun/verb analysis, which I believe has been widely/wisely discontinued. Analysis is ultimately the art of asking the right questions and raising the right objections.

Still, there seems to be something more to a concept map than meets the eye.

Every OOD class seems to have the same struggle. Everyone wants to rush to class design first, without working out objects and interactions. Time after time we see designs bursting at the seams with abstract classes which represent some truth of the problem space, but which are not used in the application at all.

I have often wondered how to encourage people to work in a less abstract way, solving their problem first and then using class design principles as a way to clean up their software’s structure. I interrupted them and provided a simple object structure that solved the problem. They considered my model and returned to their work, many of them still drawn by the siren’s song of class diagrams.

I understand it. Class diagrams are mighty expressive. They show functions and data members, and you feel like you could write code directly to the class design. It’s compelling.

I realized that they were legitimately struggling with the time pressure of getting work done in class, and with the newness of the principles and patterns of OOD. I looked for a new way to make the point. After some consideration, I approached the big easel, and wrote “God save us from needless distractions.” After giving the class a few silent minutes to ponder (or laugh, since the writing of it seemed to be a needless distraction) I reached for the red marker and returned. I crossed out “dis” and wrote in “abs” above it, changing “distraction” to “abstraction. Now I had a point to speak about.

“God save us from needless abstractions” reminds us that software is first and foremost about algorithm and behavior, and that interfaces and
abstract classes are ways to manage the dependencies which would wreck a less-advantageously-structured system. It reminds us to use them
intentionally, and not incidentally or accidentally. Did I make the point understood? The next exercise seemed to indicate that I did.

And now I have one more entry for my “wall of platitudes”.

You can write code that works. You don’t need OOD to make your program run. You don’t have to use any newfangled inheritance-supporting language. You can make programs that work in old BASIC, or Fortran, or COBOL or even assembly language. OOP/OOD/OOA, none of that is necessary if you want to just make a program that runs. Bash scripts, or even Batch files may be sufficient.

OOD doesn’t make your code run faster. Or even necessarily sooner (though good libraries are not to be underrated). It doesn’t make your teeth brighter or your breath fresher. It won’t grow hair on a cue ball.

But making it work at all isn’t the question. What OOD does is allow your program to have an advantageous structure. It doesn’t extend your ability to write code that works, but it extends your ability to extend code that works. It guards your software against becoming increasingly hard to change over time. It’s about the shape of your code.

OOD absolutely does provide tools (patterns, language, etc) that allow you to manage the dependencies that would otherwise make the maintenance of your software an ugly proposition. I don’t know anything else that OO does, except make work more fun. Things stay “new” longer.

I will tell you that the convenience of an OOPL is addictive, and that once you really grok OOD you will not want to try anything inferior in expressive capability. This is doubly true for dynamic OOPLs. But any time an OO person claims that OO will do anything else, it is probably because they’re trying to sell you something.

Me, I’d like to sell you on using Python for your next project.

One liner: Not for me

Longer answer: This thing is absurd. It’s the best way to ensure that you won’t fit in parking spaces in most of the civilized world, or in America. The hood is forever long and wide. The bed is forever long and frankly unnecessary for a teaching gig. This is the craziest rental job ever.

Well, if I were comparing it to other trucks, I would probably recommend it. Extended cab, nice ride, good dash layout, good stereo, nicely appointed and plenty of legroom. But unfortunately I am commuting between a hotel and a job site, and it’s about 5x bigger than my needs. As a commuter vehicle, it’s a pain in the butt. It barely fits on the road.

Power: good. Lots of it. Tons.
Ride: good, smooth, unless you take a corner, in which case it feels like it’s gonna tip.
Handling: power steering takes some of the exercise out of it, but it’s like steering a yacht.
Parking: A real nightmare
Mileage: Not great.
Recommended use: Hauling big, heavy gear across the world.
Disrecommended: Worse commuter vehicle I can imagine.
Other: Nice cup holder.

I’m amazed how much RDBMS design is just design.

The old story (sorry I can’t attribute it) is that there are only three important numbers in database design. They are zero, one, and many. One of something means an attribute of some other entity, maybe a single foreign key column. If there are two, a normalized design will have a table for the two of them and linkage back to the original.

Likewise, in OOD you need to consider these three numbers as being the only three meaningful numbers.

If something occurs not at all, you don’t code it. Period. Don’t leave room for it, don’t mess with it, don’t clutter your mind with it. A non-occurring item needs no programming to support it. Not one class, not one method.

One matters. Something happens, something exists, something needs to be done. Oh, sure, you could treat ones as simple cases of many, but that leads to overly complicated code and design. You’ll end up creating interfaces and classes you don’t need, lists iterators you should never have included, wasted time looking for empty sets. Why bother? One is one. You don’t need much help to deal with it.

Two or more are all “many”. If there are “many” (two plus) implementations of some thing, then your OOD should have an interface. If there are many implementations, you need an interface. If there are many items at once, then you should look at a Composite Pattern (GoF) or at least at a list. In the ObjectMentor payroll example, there are many ways to calculate a payroll and many ways to deliver a paycheck. Three is many because it’s more than one. Your design won’t change all that much if there are a dozen, or a hundred. Many defines your structure.

Many matters because often the two you see are just the two which you’ve seen so far… more are on their way. If something has evolved two versions, what makes you sure it won’t evolve a third? Or more? Why do you think you’ll only have two reports, or two ways to enter a number, or two of anything else? Two is not a significant number. The numbers are 0, 1, and MANY. Others don’t matter.

Now, in your code you may have to set cardinality limits. In your optimizations, knowing actual numbers will matter. But in structuring your code, it really is just the Big Three.

I’m not a fan of noun/verb analysis. Really. I think that it’s better than not doing anything, if only in the sense that it makes the time go faster. It gives something to work with, and you can try to do OOA from it, and you won’t always be totally messed up by doing so. It may not be the worse thing you can do.

But I tried drawing a kind of mind map from a problem statement today, and it strangely resembled the structure of the OOD that I use for the same problem. Not exactly, mind you, and there was plenty of interpretation to be done. It was also different (more literal) in one case but it was much closer than noun/verb would have been, and much better than most of the domain models I’ve seen for OOA.

I extended the basic mind map to go past a single central concept, and have facts about facts about facts, and to allow “choices” more explicitly. I’m afraid that I might be reinventing UML if I go any further.

It could be because I knew where I wanted to end up. Or maybe it modeled the problem initially. It didn’t know what would be an abstract class or a concrete class, and it didn’t pretend to. But it did show me some interesting aspects. Maybe an OOA model really is/should-be a kind of topic or concept map.

I’ll try this a little more. There may be something to it. I don’t know that I can recommend it professionally, but the idea is just interesting enough that it may matter at least a little.

MiG didn’t make it. He was the first one taken out last night. It’s a shame. I liked his Bowie-esque voice. Well, if someone doesn’t pick him up or side for him it would be crazy.

JD wins. Okay. He’s got pitch, he’s got some charisma. He’s got a nice, rich voice. He’s not as obnoxious as he was earlier on. He didn’t do so good on the studio or songwriting collaboration, but maybe he’ll take direction. Must be something that they really liked. He did sound good doing the InXS songs, so maybe it will work out.

It’s a shame when the music industry is so much more interestested in stupid and self-defeating control-of-customer policies than with the desires of the fans and the artists. I thought that the industry originally existed to provide a conduit between artists and fans, but it is human for things to become about income and control. It’s a shame.

At least I know that Switchfoot is in touch with the fans, even if their label is not.

A hint to sony: customers are not clamoring for you. We want access to your artists and their music. You are now an obstacle. Get ready, because the market always finds ways around its obstacles. You can get with us, or get ready to lose us.

I guess a dose of anarchy changes things.

Suzie McNeil got voted off the island, so to speak. So she’s not going to be the lead singer for InXS. Well, I kind knew that. I think it has to be JD or MiG, because they fit the InXS thing uniquely well. I never saw InXS as a band with a female singer. I don’t think that’s how the fans want to hear the back catalog.

That having been said, I think that Suzie is an incredible vocalist and very professional. She had excellent performances, real appeal and connection with her audience, and she nailed the studio work perfectly. I don’t think she should front InXS. I think she should front the Suzie McNeil band. She could be the new Janis Joplin or the new Bonnie Raitt (well, vocally). I think that she’s bigger than the InXS combo would allow.

It proves you don’t have to be a sex kitten. She’s a real rocker and her talent speaks for itself. She doesn’t need the baby oil and skimpy outfit and the suggestive dance moves. She can stand up and sing, baby. One really talented kid, one real musician.

Cooperation matters, and that’s why everyone needs to be able to get a copy of a standard (hopefully for free in some form) and implement it for free. When people lean on “proprietary standards” (an oxymoron), then cooperation is the first casualty. When those “standards” are licensed with onerous terms, cooperation is limited to a few monied interests. Free matters.

Well, Groklaw makes a better argument than I do. Check the link, above.