Zawinski's Law of Software Envelopment

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

—Jamie Zawinski, Jargon file entry

My friend Robert and I were talking the other day about Twitter, and he related that he's been seeing people using it like they would use email. This is no surprise; every new "social technology" that comes along ends up being treated like email. Instant messaging did it, etc.

So I'm coining Young's Corrolary to Zawinski's law:

Every social networking software or web application eventually implements an email analogue, or its users will use some function of the network as email.

Of course, you could just use email, but that wouldn't be "Web 2.0".
Read more...

Specialization is for Insects

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

-Robert A. Heinlein

As a hiring manager, I've always looked for people that tend to generalize. I'm not just looking for someone that has narrowed down on one skill set, or even focused on development work to the exclusion of other pursuits.

The people that I find most effective have other interests; they tend to be "renaissance men". Maybe they paint, or cook, or work on cars. They might play volleyball, or soccer, or softball.

Almost universally, they play an instrument.

I've seen the other side of this, after working with mainframes for several years: aging COBOL programmers that are just waiting to be put out to pasture. That isn't a dig against COBOL or COBOL programmers-- but there is a certain crowd that never updated their skills, never did anything else, and now are trapped in an evolutionary dead-end. I suspect that there are many Visual Basic programmers sitting in IT departments right now that are gearing up for this fate (and no, I'm not talking about VB.Net).

Can you talk to customers? You're more valuable than someone who can't.

Can you give a demo? Think on your feet?

Do you know how to wear appropriate attire to meet with important people? I've met many programmers over the years that never learned to how to dress "business casual", and tend to look really uncomfortable when forced to. People that can effectively "dress for success" are worth more.

If I'm hiring a java programmer, I usually want to see that you've used a scripting language, and that you have some modicum of database development and optimization. I want to know that you've done network engineering, and can explain at a high level what load balancing looks like. I want you to be able to explain sockets (this is one of those things, like pointers, that you either get, or don't get, and those who "get it" are better suited for the job).
Read more...

Stem Cell Research to Heal Broken Bones

Another breakthrough in stem cell research, the adult variety. No surprise about that last bit.

The treatment uses stem cells from the bone marrow, and then they use magnets to guide them to the location of the bone break. They are expecting to be in clinical trials within 5 years.

Amazing times that we live in. Wake me up when I can inject some additional grey matter.
Read more...

Why I think the copyright system is broken, an anecdote

The EFF has an excellent article about President Obama's gift to Queen Elizabeth: an iPod filled with music and video.

Article here.

If the gift were physical copies of the items (e.g. if he wanted to give her DVDs that would not play in her DVD player, as he did with Gordon Brown), then there is no question that the first sale doctrine applies. However, in this post-Napster era, copyright owners seem to have gone completely insane with attempting to impose control over digital distribution. The man on the street can tell you that this is folly, but they persist nonetheless.

Just for reference, I think that content producers should get paid for their art. That does not generate any love for the RIAA, the record companies, or the other racketeers that make up the current copyright thugs.

Image above licensed under creative commons.
Read more...

Why can't we just have data types?

I'm not the biggest fan of object oriented programming. There, I said it.

Also, the world is round, and circles the sun. Regardless of obsoleted dogma.

I just wanted to cook up a hash, containing hashes as values (with a couple levels of nesting). So, what do I end up with, since I'm currently stuck with those, "I know, we'll make everything an object!" languages?

This:

((ArrayList)((HashMap)dicts.get(pattern.get("Dictionary"))).get("Elements")).add(pattern);

That really should have been simple, and it's a great argument for DATA TYPES. Not Objects, not Aspects, just data. Really.

Perl's been accused of being cryptic, but here's the equivalent:

push(@{ $dicts{Dictionary}->{Elements} }, $pattern);

Of course, you don't actually have to do it that way, since perl is actually quite flexible. It has a very limited range of actual data types, but then has many operators that can manipulate the data (in wondrous and fantastic ways!).
Read more...

Computer Science/Engineering, an analogy

Computer science is to programming as pigmentation science is to painting.

I have asked the same question of people that I have worked with for the last 10-15 years (a long time). Here it is:

Is programming an art or a science?

Before I give you the answer, think about this: when you look at a beautiful building, there is a lot of science involved. But the thing that made it beautiful was not the science, it was the artistry that built on that science.

In case it's not immediately obvious, the near unanimous answer was: it is an art. Anecdotally, the better the person was at getting things done the more likely they were to answer "art", and quickly.

The sooner we get over the idea of programming as an "engineering discipline" or "science", the better.

Next time you hear someone going on about how we need "formal proofs" or "stronger engineering" for applications, ask them: "What have you actually built lately?"

(Image from user LukeGordon1 on Flickr, and is Creative Commons licensed)
Read more...

Covington Friday Night Car Shows Getting Ready to Start

It's almost time for the Friday night Covington Car shows to start!

The first Friday in May (May 1, 2009) through the last Friday in September, weather permitting, from 4PM - 8PM.

I have additional information (directions), and pictures, here.

The pictures should be convincing enough, but there are a lot of really nice cars there, the folks are friendly, and it's very family friendly. Take your kids. Read more...

The Hundredth Idiot (or, why not to read business books)

One hundred idiots make idiotic plans and carry them out. All but one justly fail. The hundredth idiot, whose plan succeeded through pure luck, is immediately convinced he's a genius.

--Iain M Banks, MATTER

Iain Banks makes one of the most astute observations I've ever read.

This is so applicable to:

1. The business model de jour: How To Use Social Networks To Facilitate Enterprise Application Development!
2. The development model de jour: Standing On Your Head To Increase Bloodflow and Facilitate New Development Methodologies!

Now, before you hie off on the "next big thing", remember that most of these "big things" are just hundredth idiots. Or, you can read a book like The Mythical Man Month by Fred Brooks and ask yourself: how is it that a book written 35 years ago, about a project completed 45 years ago is still 95% relevant?

Could it be that there's nothing new under the sun? Read more...

Frame-work (an oxymoron)

One of the most difficult things to learn about project management/development is the difference between adaptability and "does the work for you". People who have not worked with the latter might have a tendency to desire the latter (after all, who does not want less work?), but my experience has been that these types of systems always end up extracting their "pound of flesh". There Ain't No Such Thing As A Free Lunch.

The first time I used Struts, I was enamored of it for about a day. Then I realized what a pain it was to work with. It has been a while since I've used it, but my memory is primarily one of, "What magic incantation do I need to stuff in some random configuration file to actually make this page transition work?"

Another example, Ruby on Rails: I always thought this name apropos. You need to jump off and do some 4-wheeling? No dice, dude! You're on Rails!

How about this description of Cocoon:

Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development. Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. (emphasis mine)

Hint: anyone who suggests that you can program without programming is suffering from a logical fallacy. The Cocoon folks avoid this by offering that you can "hook together components into pipelines" without programming. How pipelines become applications, that I'm curious about.

I don't mean to pick on specific projects, but I'm just pointing out examples. There are certain advantages to having components, but the end goal should be adaptability and maintainability. Not the mess of an MBean talking to an EJB Session Bean that was looked up over JNDI that talks to a JMX Component that I have seen one too many times. ("See, we've got this framework, but it won't talk to this other framework, so now we're writing a Facade class (ooh! Design Patterns! It must be good!) to expose things to the other framework...")

For whatever reason, this appears to be largely a Java phenomenon. There are more Java frameworks than there are applications built on them!

...well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you -- if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers -- the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think.

Fred Brooks [paraphrased] as quoted from Allen Holub's http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html

The main thing that a framework needs to do is stay out of your way. It should not be an impediment to future progress. You should be able to say, "I want to change the sorting algorithm for this list," and be able to accomplish it quickly without the framework getting in the way.

I'm not suggesting that you should go through "Not Invented Here" syndrome, and re-implement wheels, airbags, windshields and turn signals, but that understanding the balance between adaptability and the enforced consistency of a framework. After all:

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

Ralph Waldo Emerson

Read more...

Now you have two problems

This is a classic quote from Jamie Zawinski:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

This has made me laugh many, many times over the years, as I've been trying to not weep over some dreadful regular expression. Read more...