Planet SCM

In July I will be giving a keynote address at GUADEC, the annual GNOME conference, being held this year in Istanbul.

In September I will be speaking again at the Business of Software conference, being held this year in Boston.

And finally, for something completely different, don't miss the Jam Session at Tech-Ed on June 3^rd.  Several of us minions from SourceGear are planning to take the stage and give our rendition of Pinball Wizard.  It'll be me on acoustic guitar, our development manager Jeremy Sheeley on bass, and our product manager Paul Roub playing the Evil Mastermind Schecter PT that will be given away later that week.

And BTW, none of us will be dressed as The Evil Mastermind.  This should be obvious, as The Evil Mastermind would never do something actually cool like a song by The Who.  Rather, he would do something like a Kelly Clarkson song and mistakenly believe it was cool.  :-)

It's Friday afternoon, so I hope my readers will indulge me a bit of gloating over three recent moments of personal triumph:

1. Playing the 12^th hole at my regular course, I made a shot from about 80 yards out.  Unfortunately, it was for par.  :-(
   
   
2. This past Saturday I walked the Indianapolis half marathon in a personal record time of 14:57 per mile.
   
   
3. After setting up my new subwoofer, I put in the Return of the King DVD and zoomed ahead to the Minas Tirith battle scenes.  Seconds later, my younger daughter ran upstairs and cried, "Daddy, your movie is shaking the whole house!"

All three of these were moments of great personal satisfaction.  The third one was the only one to result in maniacal laughter.

On June 30, Microsoft will discontinue Windows XP in an effort to force all PC users onto Windows Vista.  As this date gets closer and closer, they have stubbornly insisted that they will not change their plans.

Last week, Microsoft CEO Steve Ballmer blinked, but in a rather confusing way:

• The sensible part:  Ballmer claimed that they might reconsider their decision if that's what customers wanted.
  
  
• The confusing part:  Ballmer appeared to be completely ignorant of the multitudes of people publicly begging for XP to get a stay of execution.

Just want kind of customer feedback would Ballmer be able to hear?

It's really not that hard to find overwhelming evidence of large numbers of people who want to continue using XP.  A simple Google search for the string "save windows XP" results in over 200 thousand hits.

Oh yeah, I forgot -- Steve probably doesn't use Google.  Maybe the problem is that he just can't find any XP fans on the Internets?  :-)

Or maybe Ballmer is following the now fashionable trend of counting an Internet person as only 3/5 of a real person?

• Sure, Ron Paul has lots of fanatical supporters, but they're mostly just people on the Internet, and they don't really count.
  
  
• Sure, Barack Obama has raised truckloads of money, but he mostly gets it from people on the Internet, and they don't really count.
  
  
• Sure, over 170 thousand people have signed the Save Windows XP petition, but those people are on the Internet, so they don't really count.

Or maybe this is simply the most arrogant corporate decision in history?  Maybe Steve can hear all of these desperate cries but he simply doesn't care.

Power corrupts.  Every monstrously large organization eventually turns into, well, a monster.  The next step is for all these organizations to start borrowing each other's tactics.  Hey Steve, why not start waterboarding everybody who won't switch to Windows Vista?  Apparently it's legal.  :-)

The whole situation is most annoying to those of us who are running small software companies.  Unlike Microsoft, we actually have to listen to our customers.  When they tell us to jump, we ask how high.

Microsoft is telling millions of its customers to jump.  Out of principle, I am doing my best not to comply:

• I'm typing this blog entry on Windows XP.
  
  
• That instance of Windows XP is actually a VMware image running on my Mac.  I started using a MacBook Pro with Leopard a couple months ago.  And I love it.
  
  
• I just donated fifty bucks to the ReactOS project.  I'm figuring that in the long run, I've got a better chance of getting Windows XP from ReactOS than from Redmond.

Some of my readers are horrified at this blog entry.  "But Eric, aren't you a .NET developer?"

Yes, I am.  My overall posture toward Microsoft is still friendly.  I still use Windows every day.  I still love Visual Studio.  C# is still my favorite language ever.  Heck, I'm even a big WPF fan, so I'd actually prefer to see the world switch to Vista.  I've used Vista, and while I didn't find it to be a compelling "must-have" upgrade, I rather liked it.

But none of this means that I'm going to give my blanket agreement to every decision Microsoft makes.  In this case, I object to Microsoft's plan, not because Vista is so awful, but rather, because ignoring customers is so wrong.

What is ALM?

If you are a software developer, there are a whole bunch of companies (including mine) who want to sell you stuff.

If you read any magazines, go to any conferences, or visit any websites, there is a good chance you've seen their (our) marketing efforts.

More and more often, the term you see in those marketing materials is "ALM".  Ever wondered what that term means?

It means "Application Lifecycle Management".

Don't you feel better now that I've cleared all that up?  :-)

Digression:  Dead-End Acronyms

So ALM is what I call a dead-end acronym.  Like all acronyms, nobody knows what it means until you see its expanded form.  But with dead-end acronyms, people can stare all they want at the expanded form and they still don't know what it means.  There's nowhere to go.  It's a dead-end.

We software developers have a tendency to create dead-end acronyms.  For example, SOA means "Service Oriented Architecture", but I still don't know what that means.

My personal theory is that dead-end acronyms get created when somebody forces the issue.  They create an acronym which didn't want to be created.  Indigo didn't really want to be WCF -- it just wanted to stay Indigo.

Dead-end acronyms.  Our special gift to the world.

No, really.  What is ALM?

Back to the point.  What is ALM?  Let's look a bit deeper.  The expanded form actually does hold a few clues:

• From the word "Application" (and from the overall context) we know that this is about "Software Development". 
• The word "Management" is fairly intuitive all by itself.
• The word "Lifecycle" tells us that we're talking about the whole software development process.  All of it.

So, we can translate "ALM" to "Managing The Whole Software Development Process".

I suppose it's obvious that "MTWSDP" doesn't exactly roll off the tongue like "ALM" does.

Worse, I'd have to say we still haven't made much progress here.  Isn't there some way out of this dead-end? 

What is ALM?

Two roads diverged in a wood, and I...

Starting from this point, attempts to define ALM usually go in one of two distinct directions.

1. The Trees (focus on the details)
1. List all of the activities in the whole software development process (idea, market research, requirements, design, architecture, implementation, testing, release, wild drunk release party, user support, postmortem, assignment of blame, sackings, regret over impulsive terminations, rehiring as contractors at twice the cost, lather, rinse, repeat).
2. For each activity, list one or more tools that support that activity (requirements management, modeling, compilers, automated testing, issue tracking, project management, dart board, help desk, time tracking, etc).
2. The Forest (look at the big-picture)
1. Talk about the benefits that software managers can get from looking at the whole lifecycle.
2. Talk about the integration between the various tools in the whole software development process.

I believe the essence of ALM lies in the big picture view, in the real benefits that software managers get from using a truly integrated suite of tools that give them the ability to deal with the whole software development lifecycle.  My definition of ALM proceeds from The Forest perspective, the big picture view.

Getting more specific

So far this piece is over 500 words long and it still doesn't say anything.  It's time to get a bit more specific.

Before I go any further, let me say that this particular article does not attempt to offer a complete definition of ALM.  For now I am going to focus on just one issue:  Traceability.

Let's look at an example.

The Mystery of the PersonCompanyAssoc Table, Part 1

Joe is a technical support representative for CrummySoft, an ISV that sells a CRM solution.  He is working with a customer who says they just upgraded from version 6.0 to 7.0 and suddenly everything became really slow.  In an effort to track down the problem, he goes to visit Sally, a program manager.

Joe:  One of my customers says version 7.0 is a lot slower than 6.0.

Sally:  How much is "a lot"?

Joe:  Loading their dashboard page went from 1 second to around 30 seconds.

Sally:  That's a lot.  How many other customers are complaining about this?

Joe:  I've heard of a few.  Maybe a dozen.  So far.

The detective work begins.  Sally opens her IDE and digs into the problem.  Looking into the DB schema, she sees something odd.

Sally:  Here's something odd.

Joe:  What?

Sally:  Somebody changed the SQL table schema during the 7.0 dev cycle.  In 6.0 and prior, each person could be associated with exactly one company.  In fact, the People table had a column which was a foreign key into the Companies table.  Sometime during 7.0, this changed.  Now we have a new table called PersonCompanyAssoc, which allows a Person to be connected with more than one company.

Joe:  OK.  So what's the problem?

Sally:  The problem is that there were lots of places in the code which assumed a Person would only be associated with one Company.  Somebody went through and tried to fix them all with a bunch of changes to indexes, triggers and constraints.  Not all of those fixes were done in a very scalable way.  Most customers will be unaffected, but I could imagine some situations where we end up with a major slowdown.

Joe:  What kinds of situations?

Sally:  Well, for example, I'm guessing things would get bad if the Locations table has lots of different entries for the same Company.

Joe:  Bingo.  My customer deals mostly with virtual companies.  Their database has one company which is scattered across thirty different states and five countries in Europe.

Sally:  That would do it.

Joe:  So doesn't this change seem kind of stupid anyway?  Why would somebody need the ability to associate one person with multiple organizations?

Sally:  I don't know, but there's probably a reason.  Let's look for more clues.

Sally brings up the version control history log to find out who made these code changes and why.

Sally:  Apparently the PersonCompanyAssoc table was added by a developer named Tony.  The checkin comment explains what he was doing, but there's no rationale for why and no mention of the spec for this feature.

Joe:  So hey, as long as we're here in the code, can you just put it back the way it was?  If this change doesn't make any sense and it's causing performance problems, why not just undo it?

Sally:  It would probably be better to understand the whole story before we just change it back.  Let's go find Tony and ask for more info.

Isn't version control enough?

Version control does give you some traceability, and that's a good thing.  But in many cases, it is not enough.

Version control will tell you about code changes.  It can answer questions like Who, What and When.  But the hardest question in traceability is Why, and version control often lacks enough information to give a good answer.  Even if the developer is supposed to give a checkin comment which explains why a change was made, the detective work tends to get stuck because the clues dry up.

• Why is this piece of code there?
• Oh, it was to fix a bug.
• Which bug?
• Oh, that one.
• But why was this a bug?
• Oh, the spec says it should work this way.
• But why?
• Oh, here's the rationale for that requirement.  It came from marketing research.

Very few developers write checkin comments which are good enough to solve the really tough mysteries in software development, and they shouldn't have to.  We don't need better checkin comments.  We need all the artifacts from the whole software development process to be linked together.

The Mystery, Part 2

Sally and Joe walk across the CrummySoft campus to building 71 where they find themselves in a seemingly endless room filled with cubicles.  The manager sitting next to the entrance at a mahogany desk with a nameplate identifying him as Biff.

Biff:  Can I help you?

Sally:  We're looking for a developer named Tony.  Is he here?

Biff:  Why do you want to see him?

Sally:  He made a code change and we need to ask him for more information about it.

Biff:  OK, let's see.  Tony.  Ah yes, he's in cubicle 19-346-B.

Joe:  19-346-B.  Where's that?

Biff:  I gather that you've never been here before?  Very well.  Cubicle 19-346-B.  Go to aisle 19.  Walk down to the 346^th cubicle.  Tony should be in the one on your left.

Joe and Sally eventually reach Tony's cubicle where they find him playing World of Warcraft.

Tony:  You need somethin'?

Joe:  Why did you add a PersonCompanyAssoc table during the 7.0 dev cycle?

Tony:  How should I know?  That was like nine months ago.  I've probably made at least two other code changes since then.  I can't be expected to remember details like that.

Sally:  Do you know anyone who might know?

Tony:  Ask Phil in QA.  Maybe there's some info in that bug tracking database I've seen him using.

Joe:  So where do we find Phil?

Tony:  Geez, have you guys never been here before or what?  Phil is in cubicle 61-842-A.  That means you go down to aisle 61, turn left, and walk down ---

Joe:  Yeah, yeah, we got it.  Thanks.

Sally and Joe meander their way across the cubicle field to find Phil.  Along the way, Joe pauses at the intersection of an aisle and a row.  The walls in all four directions are too far away to see.  Continuing on, they eventually reach their destination.

Sally:  Phil, any idea why Tony added a PersonCompanyAssoc table about six months ago?

Phil:  Yeah, I think we did that to fix a bug. 

Joe:  Which bug?

Phil:  How should I know?

Sally:  Well could you look it up?

Phil:  Fine, let's see.  Oh yeah, it's bug 8675309.

Sally:  Does that bug have any information about why the change was made?

Phil:  Not really, but there's a comment here by somebody on the sales team.  Did you talk to them yet?

Joe:  Aha!  Let's go ask the sales team!

Team Size

ALM tools are often associated with very large projects and enterprise development.  This is just intuitive.  The more people involved, the more complexity to be managed.

Imagine trying to solve a mystery and you get stuck.  You need more clues, so you start canvassing the neighborhood looking for people who might have seen something suspicious.  Now suppose that "the neighborhood" is a software development division with 5,000 people in it.  Those interviews are going to take a while.

But chaos usually takes over long before a team gets that large.  Traceability may not be as important for a team of 50 as it is for a team of 5,000, but it can still be pretty important.  People forget why things happen, and that forgetfulness is not a function of the size of the team they are on.

You may be thinking, "My team is small.  We shouldn't have these kinds of problems, but this mystery still sounds familiar.  Why does this kind of detective work happen when we've only got 10 people?"

Are you sure you are counting everyone?  :-)

How about your customers?  They are part of your story.  When a customer asks for something, very often it triggers a sequence of steps.  And somebody will probably want to trace that sequence back to that customer.

SourceGear is a pretty small company.  We've got less than 50 people on our staff.

But our flagship product, Vault, is used by about 50 thousand people.  Sometimes we have a mystery to solve.  And very often the detective work leads us to one of those customers.  Our customers add to the complexity of our software lifecycle, and increase our need for traceability.

The Mystery, Part 3

When the plane arrives in Grand Cayman, Sally and Joe are greeted by a dozen beautiful people with perfect tans who escort them to the main company sales office, where, as always, a party is in progress.

Joe:  Who should we talk to?

Sally:  Let's find Bill.  He came to the company headquarters once for a meeting.  I think he'll remember us.

Weaving through the crowd, they eventually find Bill, martini in one hand, cell phone in the other.

Bill:  Do I know you?  Oh, wait.  Don't you work at the HQ back in Minneapolis?  I think we met last summer when I came up for that golf outing, er, I mean, sales training.  So what brings you all the way here to visit the sales team?

Joe:  We're trying to solve a mystery.  Between 6.0 and 7.0, somebody changed the database schema to handle multiple company associations per person.  Any idea why?

Bill:  Can I offer you a martini?

Sally:  Seriously, Bill, this code change is causing a lot of problems.  We want to just rip it out, but we figure we should understand the background first.

Bill:  Yeah, yeah, whatever.  That wasn't my deal.  Ask Marty.

After a bit more searching and stopping briefly to slide under the limbo bar, Joe and Sally find Marty in the corner of the room speaking intensely into his cell phone.

Marty:  Don't worry, you can count on me this time!  I'll have the feature in version 8.0, I promise!

Sally:  Hey Marty.  We're trying to track down some information.  Somebody changed the DB schema during the 7.0 dev cycle to allow multiple companies to be associated with each person.  Were you the one who requested that feature?

Marty:  Yeah, that's me.  I needed that tweak to close a deal.  Is there a problem?

Joe:  Yes!  That was a lot more than a "tweak".  It may seem simple, but it involved hundreds of code changes, and all kinds of things got messed up!

Marty:  Can I offer you a martini?

Sally:  Seriously, can you tell us why this change was necessary?  Why would anybody need to keep track of multiple companies per individual?

Marty:  One of my accounts is using our CRM product in selling to a network of consultants.  Those consultants have loose company affiliations.  One day they might be representing company XYZ, and the next day they're working for company ABC.  The assumption of "one company per individual" just wasn't flexible enough.

Sally:  Was it a good deal?  I mean, was this worth the trouble?

Marty:  I think so.  The deal was quite lucrative, and it opened the door to half a dozen more like it, three of which I have already signed.  Look, I'm sorry somebody screwed up this code change, but the business case behind it was solid.

Sally:  Alright, fine.  Thanks for the info.

The Whole Team

The full story of every significant software development project includes many different people.  Most of them are not writing code.  Tracing an issue backward can mean more than finding the bug report that motivated a code change.  We may need to go back further, back to the spec.

We might need to go back even further, back to the market research or the sales engagement or the customer support ticket.

A truly comprehensive approach to traceability would archive, index and link everything:

• Requirements
• Version control
• Issue tracking
• Marketing research
• Wiki
• Email, discussions
• Tests
• Help desk tickets
• etc

The challenge of an ALM tool is to support traceability across all stages of the software lifecycle.

The Mystery, Part 4

Joe and Sally head back to the airport to catch a flight back to the Twin Cities.

Sally:  So I guess this code change needs to stay.  But now we've got another mystery.  This code change caused a bunch of problems.  Why weren't those problems found in testing?

Joe:  Let's go back to that QA guy and ask him.

Returning to the main company headquarters, they find their way back to cubicle 61-842-A.

Phil:  Whazzup?

Sally:  We talked to the sales team and got some rationale for that PersonCompanyAssoc table change.  Now we're trying to figure out why the resulting problems weren't found during testing.

Phil:  Hey, don't look at me.  I just do what I'm told.

Joe:  Whatever.  So the product supports multiple locations per company, right?

Phil:  Yeah, I guess so.

Joe:  Do you guys have any tests which verify behavior for that case?

Phil:  I don't know.

Sally:  You don't know?  Why not?

Phil:  I just don't.  The tests aren't really organized like that.

Joe:  Well how are they organized?

Phil:  By number.

Sally:  And what do the numbers mean?

Phil:  Well, nothing.

Sally:  So is there any way to find which tests are designed to verify which features?

Phil:  Uh, well, no.  You could always open an individual test and read it to find out what it does.

Sally:  Great.  So you've got a bunch of tests and no way of linking them to anything?

Phil:  Exactly!

Sally:  OK, I think we're done here.

Forward Traceability

Traceability can do more than just help you figure out forgotten details of the past.  Sometimes we want to trace something "forward" through the software lifecycle, to see where it goes.

In this case, what we want is the following artifacts to be linked together:

1. Requirement:  The system must support multiple locations per company.
2. Test (validity):  Verify that the system can support multiple locations per company.
3. Test (performance):  Verify that in a situation with multiple locations per company, the dashboard load time remains approximately constant.

This kind of traceability is most helpful in finding things that are simply missing.  If the performance test above does not exist, our ALM tool should be able to help us notice that.  If a Requirement is dangling, with no links to anything, it was probably never implemented, and our ALM tool should be fussing about that.

Traceability:  Connecting Everything Together

The ability to connect everything together is called traceability.  It allows us to look at the entire software development process, even though it involves

• lots of different people
• doing lots of different things
• at lots of different times
• in lots of different locations
• for lots of different reasons.

In a good ALM system, every item is linked to all of the other items related to it.  Code changes are linked to bug reports.  Bug reports are linked to help desk items.  Tests are linked to requirements.  When it comes time to do detective work, just follow the links.

You can't get good traceability merely by having one tool for each lifecycle stage.  You can assemble all of your favorite tools, but if those tools don't support outstanding integration with each other, you won't have traceability, so the result will not be ALM.

So is that all there is to ALM?  Just traceability? 

No, ALM is more than that, but traceability is a critical ingredient.  To have ALM, you've gotta have traceability.

Why to use a good ALM system

If CrummySoft had deployed an efficient ALM system with complete information, Sally and Joe could have solved this mystery in minutes, without the need to run all over the company and ask people questions.

Why not to use a good ALM system

If CrummySoft had deployed an efficient ALM system with complete information, Sally and Joe would not have gotten a free trip to Grand Cayman.  :-)

Yesterday my coworkers redecorated my office.  Pictures in this blog entry are photos of their work.  Strangely enough, I found myself quite appreciative of their act of vandalism.  :-)

Today is my 40^th birthday.  Like most other days, I started by walking the dog and making a To-Do list.  However, today's list has a special item:

• Decide whether to have a mid-life crisis or not.

:-)

I'll confess I am not entirely thrilled about being 40.  It doesn't seem that long ago that 40 seemed far away.  Now that it's here, I realize that it's not what I expected.  I thought my life at 40 would be different.

Many who know me would assert that I have nothing to complain about.  And they would be correct.  My life has been filled with blessings of all kinds, for which I am truly thankful.  I am a published author.  Most would consider me financially successful.  I am in a career where I enjoy my work.

But still...

As the old saying goes, nobody lies on their deathbed wishing they had spent more time at the office.

Like most everybody else, when I was 30 I looked ahead ten years and formed a picture in my mind.  My life today doesn't match that picture very well.  Examples:

• I thought by now I would be more solid in the quality of my relationships with my loved ones and in the practice of my faith.
  
  
• I thought by now I would be a better guitar player.
  
  
• There's a messy pile in my study that has been there for ten years.  (Yes, we moved six years ago.  The heap moved too.)  I thought it would be cleaned up by now.
  
  
• I always assumed that by 40 I would have learned to exercise regularly and stop eating junk food.

I go could on.  And on.  But you get the idea.

I am tempted to think about my regrets, the places where I took a wrong turn, the places where I would have made a smarter choice if I knew then what I know now.

But this whole line of thinking doesn't seem at all conducive to good mental health, so today I will choose to focus on two things which seem more constructive:

1.  Tapestry

One of my favorite Star Trek episodes is called Tapestry.  It is the story of someone given a chance to re-live a pivotal moment in his youth so that he can avoid making the unwise choice he made the first time.  But it turns out that his reckless moment was a critical ingredient in his later successes.

Today I remind myself that there are no do-overs, and I'm not sure I would want one anyway.  For every mistake I have made, there were negative consequences and positive lessons.  I can't expect to avoid the former and keep the latter.  They come together as an inseparable package.

2.  Life Calculus.

Back in 2003 I wrote an article called Career Calculus.  In a nutshell, it says that at any given moment in your career, what you know is far less important than whether you are learning.

Today I remind myself that the same principle applies in life.  I am confident in my first derivative.  Whatever I am today, I think I will be a better person tomorrow.

So if I'm still blogging when I'm 50, I expect I will be able to report progress on some of the items mentioned above.

And just to be clear, if that heap of junk on the floor of my study is still there, it will be larger than it is now, and I plan to report that as progress.  :-)

SD West is next week and SourceGear has a whole bunch of stuff happening:

Fortress 1.1 and Vault 4.1

We like to use trade shows as a public debut of new products.  Last week we shipped "dot one" releases of Vault and Fortress.  SD West will be our first opportunity to talk with customers in person about these new versions. 

Interactions like these are a big part of what makes a trade show trip worthwhile for us.  The business of software can be so impersonal.  Software flows out our T1 line.  Money flows in.  I love trade shows because they're a place where customers are not just rows in a database.  People stop by and tell us they love our product.  We thank them.  People come and tell us we disappointed them.  We listen.

But mostly, people come and ask us what's new.  We show them.  And their reactions are some of the best product feedback we get.

Fortress 1.1 and Vault 4.1 have some cool new stuff.  Here's a shot of the new "tag cloud" feature in Fortress:

Come see us in booth 308 next week and we'll show you.

T-Shirts and Comic Books

Continuing our Evil Mastermind theme, we have arranged to have a comic book placed in the conference bag for every attendee.

We also have a new edition of the Evil Mastermind T-shirt.  We're bringing a thousand of them to give away in our booth.

Beat Jeremy at Guitar Hero

The other tenants in our office building don't have any idea what we do.  They refer to SourceGear as "that company with a pool table up on the top floor".

I wonder what those folks would have said about the company HORSE games we used to have at our previous location.  :-)

Anyway, I strongly believe that a little recreation is a critical part of the culture of any good software company.

These days, the popular place to be at SourceGear is the room with the video game consoles hooked up to the plasma TV.  It turns out that our development team lead is pretty darn good at Guitar Hero.  In fact, he will be taking on all challengers in our booth at SD West next week.  We'll give a 5-user Fortress license to anyone who can beat him.

Evil Mastermind guitar

And if we're going to play Guitar Hero, why not have the real thing as well?  On the last day of the show we will have a prize drawing for an Evil Mastermind electric guitar.  It's a Schecter PT, and the customization work was professionally done.  I saw this instrument yesterday, and it looks really sweet.  For more details, see Paul Roub's blog.

My panel session on Friday

Friday morning at the conference I will be moderating a panel discussion.  It's in the Business of Software track, and the topic is Private Company Exit Strategies.

The Jolt Awards

We are honored that SourceGear DiffMerge has been chosen as one of the Jolt Award finalists this year.  We'll be there at the announcement ceremony March 5^th.  The competition in our category looks really tough, but somebody's gonna win, so we're hoping it's us.  :-)

I know, I know.  Pessimism just isn't very attractive.  But sometimes an optimist can't find anything to say.

A couple of weeks ago, Trolltech announced that they are being acquired by Nokia.  I decided to simmer for a couple weeks before making any comment, but my perspective has not changed.  I just can't see this as good news.  Bluntly, I assume this will be the death of Trolltech.

And that would be a shame.  Trolltech is on my short list of software companies that I admire.  Their product, Qt, has an amazing reputation.  Technologically, it seems to be the top dog in a space which is crowded with lots of people trying to offer solutions to a very tough set of problems.  Trolltech plays well with both the open source world and the commercial world, and they make a heckuva lot of money doing it.  I'm impressed.

(But I still wish they would put the pricing back on their website.  Yep, the unnamed company in my Sales Guy Tantrum last month was Trolltech.)

I have no affiliation with Trolltech (or Nokia).  I am not even a customer (of either one).  As someone who is very interested in the business of software, I just hate seeing a good software company morph into a bad one.  Nokia is a great company and I'll be happy to see them prove me wrong, but in general, when a software company gets acquired by a non-software company, it immediately begins a steep and steady decline.

Managing a software company, especially one that sells to developers, is not like anything else.  It's just different, and that's that.

• If you're great at the business of software, there's an excellent chance you would be incompetent as a business manager in any other field.
• Similarly, anybody who is excellent in another field is almost certainly going to struggle if they take the reins of a software venture.

Nokia is a great cell phone company.  None of their skills are going to apply very well to the development, maintenance, marketing and sales of a C++ portability framework.

So maybe I'm jumping the gun a bit, but I like to beat the rush.  I'm ready now to mourn the loss of Trolltech, yet another great software company destroyed by a BigCo who assumed that managing a software business should be easy.

If I'm wrong, tell me why.

It's hard to decide how afraid to be of something that is really bad and really rare.

This problem is currently one of the most controversial issues in the United States.  Ever since September 11, 2001, we have been wrestling with the question: How afraid of terrorism should we be?

• We all agree that terrorism is really bad.  What happened on 9/11 was awful.
• But it's also really rare.  I personally have never met a Muslim who wanted to hurt me.

How afraid should we be? 

• Some people are very afraid.  They focus more on the "really bad" side of the issue.  Many of these folks are willing to give up their own civil liberties just to feel safer. 
• Others are not afraid at all.  They focus more on the "really rare" side of the issue.  They prefer to spend their resources and attention in other areas.

This blog entry is not the place for me to take a stance on any of these issues.  For now I will simply say that I understand both perspectives.  This whole situation is simply the most obvious example of my point, which was:

It's hard to decide how afraid to be of something that is really bad and really rare.

Issues like these are like an icy ski slope.  Some people stand at the top.  Some people stand at the bottom.  Very few people stand anywhere else.  It's too slippery.

It is perhaps interesting to note that these issues can be equally polarizing when the context is far less important, like the digital world.  Granted, the underlying topics are far less weighty.  When discussing things like terrorism or child abduction, the definition of "really bad" is quite different than it is when talking about music piracy or vandalized Wikipedia entries. 

Still, the polarizing effect looks exactly the same.  It's hard to decide how afraid to be of something that is really bad and really rare.  Some people stand at the top of the slope.  Others stand at the bottom.

Wikipedia

I don't know anybody who has lukewarm feelings about Wikipedia.  Folks either love it or they hate it.

My daughter's school teacher hates it.  Wikipedia can provide no claims of accuracy.  There is no good way to be sure that the information is correct.  When it's not correct, there is either no one to blame or no way to punish them.  All of these are crucial attributes of a traditional encyclopedia.

I understand this perspective, but on this particular issue, I'm standing at the top of the slope.  I love Wikipedia.  The principle is just very appealing:  The distinction between reader and writer is largely removed.  Anyone can add or change the content.  Since the good guys far outnumber the bad guys, the result is a body of content which is constantly growing and improving.

(It's kind of the same principle as Career Calculus, except for an encyclopedia.  Focus on the first derivative.  Instead of worrying about how good the encyclopedia is now, worry about whether it is getting better and how that's happening.)

I admit that there are obvious risks.  Since anybody can edit a Wikipedia page, it is always possible for the content of a page to be incorrect or even vandalized.

But the tradeoff seems to work well in practice.  I probably use Wikipedia every day.  The information I find there has been consistently helpful.  I like Wikipedia better than a traditional encyclopedia.  Much better.

But maybe this is because the threat isn't very real to me.  Personally, I have never encountered a vandalized Wikipedia article.  Occasionally I find an entry which is lame, but I don't remember seeing one that was blatantly wrong or intentionally damaged.  Most of the time, the content in Wikipedia is excellent.

But the fact remains:  Every time I use Wikipedia, I am taking a risk.  Since I have never gotten burned by that risk, the peril doesn't seem very real.

The Peril is Real

Wikipedia currently has an entry about me.  This morning, my 10-year-old daughter told me that she tried to edit that entry.  Suddenly my entire perspective on Wikipedia changed.  This was the first time I had to confront the idea of a vandalized Wikipedia entry in any sort of real way.

As it turns out, she didn't succeed.  But she's a very bright young lady, so I'm sure she'll figure it out soon.

As a matter of principle, I refuse to edit my own Wikipedia page.  So, I have a favor to ask of my readers.

Sometime soon my Wikipedia entry is going to change.  Any content about SourceGear, AbiWord or Spyglass will be deleted.  The new version of the article will focus primarily on my atrocious failings as a father, evidenced by my ongoing refusal to allow my youngest daughter to get a hamster.

When this happens, could one of you folks fix it for me?  Thanks.

Last week I was considering the purchase of a piece of software.  I went to the vendor's website for pricing.  It wasn't there.  Annoyed, I filled out the form so that I could be contacted by one of their sales people.  The following day I got a response:

Thanks for considering (product name deleted).  Please write back to me with your phone # or call me at the # below -- we can discuss pricing as I learn about your application and how you plan to use (product name deleted) for development.

So I sent an email with the following response:

Hi (name deleted),

OK.  Please bear with me for just a moment while I vent.

#ifdef FRUSTRATED_RANT

First, I hate the fact that you guys don't put pricing on your website.  I looked up the old version of your site using archive.org, so I've got a ballpark idea of what the pricing was around six months ago.  Mostly I just want to know if anything has changed.

Second, it's absurd that when a customer asks for pricing, you won't give it to them.  Instead, you answer the question with a question.  I'm not even the slightest bit interested in telling you about our application and how we plan to use (product name deleted) for development.  I just want to know your pricing and your license terms.

And for the hat trick, it's incredibly frustrating that you want to do this by phone.  I hate phones with a passion, especially when they're completely unnecessary.

Bottom line:  I'm interested in buying your product.  The only obstacle in my way is YOU.  If your product didn't have such a great reputation, I would give up right now.

#endif

OK, sorry about that.  I figured if I get all this off my chest then I'll have a much better chance of getting through our phone call without saying anything rude.  Please call me at 217-XXX-YYYY.  I promise to be nice.  :-)

--

Eric

Fortunately, my "vent before the call" strategy worked out very well.  The sales person called me and we had a very pleasant and cordial conversation.

I'm going to the Rose Bowl.

I am a University of Illinois alum and an avid fan of college sports.  The Illini football team had a great season this year and will play USC in Pasadena on January 1st.  In fact, this is the just the second time in my lifetime that Illinois has made it to the Rose Bowl.  For those of us here in central Illinois, this is a really big deal.  Who knows when it will happen again?

So last week when the University started selling tickets, I placed my order.  A few days later I received confirmation that I was going to actually get the tickets I had requested.  That email said:

"tickets will be shipped to the address listed above via UPS Overnight Delivery"

I laughed out loud.  UPS Overnight?  I live right here in Champaign-Urbana.  The University of Illinois Athletic Ticket Office is less than two miles from my office.  Surely I could just go over during my lunch hour and pick them up?

No, I suppose not.  These folks are trying to process orders for over 25,000 tickets and they have very little time to do it.  They probably just want to have one standard method of handling them all.  Dealing with the special cases would slow everything down.

The next day I got email from UPS with a tracking number for my tickets:

Sure enough -- my tickets were being sent 1.8 miles by "Next Day Air".  At this point, I fully expected that this envelope would be traveling across town by way of O'Hare.

Much to my surprise, UPS actually figured out that it was already in its destination city:

So, let's review:  Both the University and UPS faced a situation which was somewhat of an exception to their normal workflow.  One of them treated the exception as a special case.  The other one did not. 

And in my opinion, both of these organizations did exactly the right thing.

I think one of the toughest parts of running a business is dealing with all the exceptions.  These things never get much attention at the genesis of a company.  We write our business plan and we try to figure out how we're going to handle everything from customer issues to staffing issues to bugs to parking.  But then life hands us a diversity of circumstances we never expected.

• One of your staff needs to have surgery but they've used up all their leave days.
  
  
• Your biggest customer wants you to add a special feature that won't be useful to anybody else.
  
  
• The policy says anybody who purchased on or after June 17^th will get the upgrade for free.  The guy who bought at 10:00pm on June 16^th is on the phone.

Sometimes the right thing to do is to handle the situation as a special case, even if doing so takes extra time.

And sometimes, it's best to just shove everything into the meat grinder and let sausage come out the other side.

But how do we know which approach to use for a given situation?  The issues in play can include fairness, cost, ethics, focus, and so on.

And when is the time to realize that a certain kind of exception is happening often enough that it's worth defining a way to handle it?

I don't have any silver bullet answers for these questions.  In entrepreneurship, there is no substitute for good judgment. 

Just keep in mind that exceptions are going to happen, and how we navigate them can be a major definer of our success in business.  Pay attention, and use common sense.

In the transition from C# 1.0 to C# 2.0, they added generics.  This was an enormous improvement.  Huge.

(At first I was actually kind of skeptical of generics.  They reminded me of C++ templates, the use of which I had opposed on several occasions.  But my 1993 reasons for advocacy against C++ templates really weren't relevant to the C# generics in 2005.)

So when I started my recent exploration of Java, one of my main questions was:  Are the generics in Java 1.5 similar to generics in C# 2.0?

The answer:  Sort of.  Not really.

To be fair, I'll admit right up front that Java generics are better than no generics.  I'm using them.  They work just fine in practice for most situations.

But they're fundamentally different from C# generics.  In C#, a generic is implemented at the CLR level.  When you instantiate a List<T>, at runtime it will generate an implementation of a List which is specifically for type T.

When TPTB added generics to Java, one of their goals was to avoid the need for any changes to the VM.  So Java's generics are implemented at the compiler level using a technique called "type erasure".  Basically, the Java compiler does all the necessary type checking, but then it throws the parameterized type information away and generates regular collection code.  This has a few consequences which are rather unfortunate:

• Since the parameterized type is no longer present in the bytecode, reflection doesn't show it.
  
  
• The compiler inserts all the casts that you would have had to write if you were using the non-generic collection class directly.
  
  
• In a generic collection of a primitive type, the parameterized type gets boxed.

So Java's generics are a nice convenience for the programmer, but they don't bring any of the performance benefits which we get from generics in C#.

Note that these tradeoffs were not accepted with no gain.  The primary motivation here was to get generics without sacrificing backward compatibility.  That's an important consideration, especially given the amount of Java code that already existed prior to 1.5.

But if you're coming from C# 2.0 to Java, it's good to understand how generics are different.

(For a more authoritative discussion of the topic, check out Bruce Eckel's interview with Anders Hejlsberg.)

People want to be understood.  That's why support groups are so popular.

• The alcoholic wants to connect with somebody else who showed up drunk at a wedding and embarrassed the bride.
  
  
• The compulsive overeater wants to know that he's not the only one who has stopped at the Dunkin Donuts drive-thru on the way home to eat a dozen before dinner.
  
  
• The out-of-control gambler wants to be in community with other people who have lost their car going "all in" with pocket sevens.

We all have problems, and we all want to know that we're not alone.

Wednesday evening I posted a comment on a friend's blog.  Or rather, I tried to post a comment.

True to my tendencies, it was really far too wordy to be called a comment.  I actually spent about half an hour wordsmithing a multiple-paragraph response.

But when I hit the submit button to post it, Wordpress gave me a generic error page.  Presumably something timed out while I was crafting my reply.

And when I hit the Back button, my comment was gone.  :-(

*&%$#@!

My mind raced.  What are my options here?

Maybe I should just re-type the whole thing?  It was only 300 words or so.

Nah.  The text I wrote was perfect.  I probably won't be able to remember it just the way it was.

And why should I have to?  Firefox and Wordpress screwed this up, not me!

Cautiously I hit the Forward button in my browser.  Firefox showed me this dialog:

Aha!  I clicked OK.  Wordpress coughed up the same hairball I got before.

But now I know that Firefox still has my comment in memory somewhere.  All I have to do is figure out how to get it.

Two hours later I finally got my comment posted, deliberately ignoring the fact that I could have retyped it ten times by then.

After several other attempts that brought me to dead ends, here is the technique that succeeded:

• I installed winpcap and a packet sniffer, which I configured to capture all packets on my network interface.
  
  
• Then I went back to my still-open instance of Firefox and hit Reload.  I clicked the OK button in the dialog box above and Wordpress barfed again.
  
  
• Then I went back to the packet sniffer and found the TCP connection containing my posted comment.
  
  
• Ack!  I had completely forgotten that the format would be application/x-www-form-urlencoded.  Luckily, I memorized all of the punctuation marks in the ASCII table back when I was in middle school.  %22 would be 34 in decimal, so that's a quotation mark.  After several search-and-replace operations, all the escaped characters were fixed.
  
  
• During all this, I noticed and fixed a couple of typos I had previously missed.
  
  
• Finally I went back to my friend's blog, pasted my comment into the textbox and hit submit.

Let me know that I'm not alone.  Tell me the story of something geeky that you did.

As a member of Microsoft's VSIP program, we have been creating source control plugins for the Visual Studio line of products for eight years.  As I started my recent foray into the Eclipse world, I was eager to explore the area of plugins over on this side of the fence.  So far, I'm impressed.

Source Control and Bug Tracking

The first plugin I installed was our own.  SourceGear Fortress includes an Eclipse plugin, but I had never even tried it.

My first reaction is that I really like the way Eclipse handles installation of plugins.  The whole process is managed from within Eclipse itself.  Under the Help menu is a submenu called Software Updates.  All I have to do is provide the URL of our Eclipse update site:

http://download.sourcegear.com/Fortress/latest/update

The rest of the job is very simple, essentially automatic.

Once installed, I have several additional views:

And some new stuff under the Team menu:

And some new items under Preferences:

All in all, I have found using source control under Eclipse to be very pleasant and straightforward.  If this seems like I am bragging about my own product, I suppose it is, except for two mitigating factors:

1. I personally had nothing to do with this plugin, so this is less of a boast and more of a compliment to the efforts of my coworkers.
   
   
2. In my experience, source control plugins are a lot like children.  To some extent, the behavior of a child (or plugin) reflects the quality of the structure and guidance provided by the parent (or IDE).  In saying that our source control plugin works very well, I am complimenting Eclipse.

Truth be told, I did find [what I think is] a bug in our Eclipse plugin.  Fortunately, because Fortress supports integrated bug-tracking, I was able to use the plugin to report the bug right from within Eclipse.  :-)

CheckStyle

In part 2 I complained about the way Java handles object comparison (== is for identity, .equals() is for state).  I received quite a few comments and emails for that one.  I don't mind the contrasting points of view, but I'll confess I deleted all the remarks from condescending nitwits who assumed I simply don't understand pointers.  :-)

Anyway, several people suggested I try an Eclipse plugin called CheckStyle.

Once again, installation was extremely simple.  After that, I immediately ran CheckStyle on my code, just to see what happens with no further configuration.

CheckStyle complained about the 301 places where I put the curly brace on the next line.  :-)

Overall, CheckStyle looks very cool.  I'll be experimenting with it more and configuring it to match my coding style.  I don't expect I'll make the == mistake again now that I remember how Java does things, but it's nice to know that if I do, CheckStyle can pester me about it.

The Ecosystem

The VSIP people are always talking about the Visual Studio "ecosystem", the collection of organizations creating every conceivable type of plugin for Visual Studio.

The corresponding ecosystem for Eclipse appears to be enormous.  When I Google for the words "eclipse plugin", the top two hits appear to be sites which are trying to help people find plugins.  One of those sites is www.eclipseplugincentral.com, which seems to be saying there are 991 plugins in its directory. 

I know for a fact that there are at least 992, because the SourceGear Fortress plugin isn't listed yet.  :-)

Browsing the directory reveals an incredible diversity of plugins.  Many of them are unsurprising, but the fringe cases suggest just how large the surface area of this ecosystem really is:

• There's a plugin for editing Wikipedia articles.
  
  
• There's a VNC plugin, so I can manage remote machines without leaving Eclipse.
  
  
• There's a plugin that allows me to play minesweeper within Eclipse.

In fact, as I looked through this list of plugins, I started to realize that Eclipse is basically a modern Emacs.  The true die-hard Emacs users want to do everything within Emacs.  One of my coworkers likes to edit /etc/passwd and set emacs to be his shell.  Eclipse seems to be heading in the same direction.

Bottom Line

I've tried 2 Eclipse plugins so far -- 990 to go.  This should be fun.

Until about 2002 I had a broad disdain for most IDEs.  I just felt they were too pushy.  They were always trying to take control over my build system or the layout of my source tree.  If I'm going to give those things up, I want something in return.  For a long time, the tradeoff never seemed fair.  THINK C on the Macintosh was one of the only IDE products I actually liked.

Visual Studio .NET 2002 was the first Windows IDE that won me over.  I still use vi or emacs almost every day, but I'll admit that I now use Visual Studio more.

Last year I switched to Visual Studio 2005, and I love it.  This is a product that is so perfect I worry about its next release.  Now that Visual Studio 2008 is out, I'll probably give it a try at some point soon.  But Visual Studio 2005 is sort of like "if it works, don't mess with it".  The last thing I want is for them to screw it up, and I can't really imagine how it could be better.

I guess when it comes to IDEs, I'm just not very imaginative.  :-)

I started using Eclipse a few weeks ago, and now I understand a bit more about where Visual Studio has room to improve.  I think Eclipse is amazing, and I've barely scratched the surface.

So anyway, here are a couple of my current favorite Eclipse features:

Constant Builds

When I first installed Eclipse, the very first thing I did was look for the menu item to start a build.  When I didn't find one, I assumed that the Eclipse menu system must be too cluttered and counterintuitive.  How could they make such a frequently-used command so hard to find?

Of course I now understand that Eclipse has no build command because it is automatically building all the time.  In fact, I've quickly become rather hooked on this feature.  I once got it confused, but mostly it Just Works.  I make code changes, save the file, and the Problems pane automatically shows all the current warnings and errors.  Sweet.

In fact, this morning I fired up Visual Studio 2005 to fix a bug.  After making the code change, I saved the file and just stared at the bottom of my screen, waiting for the compile.  A few seconds later I realized I had to press Ctrl-Shift-B.

Quick-Fix

I really like the Quick Fix feature of Eclipse.  Basically, whenever I have a compile error or warning, I put the insertion point into the offending text and press Ctrl-1.  This invokes the Quick Fix facility, which pops up a little window showing options to automatically fix the problem.  For example, if I am trying to call a method that doesn't exist, it offers to create the missing method.

Visual Studio has similar features (Generate Method Stub, for example), but Quick Fix seems more creative.  It almost always offers me several choices for how to resolve the situation, plus a preview of what the Quick Fix will look like.

This is particularly handy for dealing with exceptions.  I mostly dislike the way Java forces me to declare which exceptions a method might throw.  Ctrl-1 gives me a quick way to either add a throws declaration or a try/catch.

Bottom Line

I am obviously an Eclipse newbie, so my explanations of its features are probably wrong.  And like I said, I'm just getting started.  As I was writing this blog entry, I discovered "Generate Constructor Using Fields..."  I sure I wish I had found that one earlier.  :-)

Anyway, feel free to correct me or tell me what I missed or remind me that I'm clueless or tell me 7 reasons why I should be using IntelliJ.

But mostly I'm just saying that the experience of using Eclipse has given me a much bigger perspective on IDEs in general.  In comparing Visual Studio and Eclipse, I can't really say whether one is clearly better than the other.  Mostly I get the impression that these two competitors could learn a lot from each other.

As I mentioned in part 1, it has been almost ten years since I last wrote any real Java code.  That was apparently long enough for me to repress some of the more painful memories.  For example, I had completely forgotten about how the following code works:

String a = new String("foo");
String b = new String("foo");
if (a == b)
{
      // this will never happen
}

In C#, when you use the == operator on strings, you get what you expect.  In Java, == merely tells you if the two strings are the very same object, not whether the two strings are the same.

Tangent:  Operator Overloading

More broadly, going back to Java makes me realize just how much I appreciate operator overloading in C#. 

I'm not saying that I think operator overloading is really useful for my own classes.  Mostly I think it's a way of empowering programmers to create bad code.  I'll admit I use operator overloading just a little bit in Sawdust to support easy manipulation of 3D points and vectors, but I could live without it.

However, I really like the way operator overloading is used by the .NET Framework classes:

• Using == to compare strings is just very intuitive.
• It feels very natural to use < and > to compare DateTime objects.
• Indexing a Dictionary with [] just seems right.

None of these bits of syntax are available in Java, and I miss them all.

Especially for Strings.

But that's not the part that's upsetting.

You've Gotta be Kidding Me

What's really shocking is that I spent a week or so writing incorrect code and nothing in my development environment warned me.  I didn't realize that == cannot be used for string comparison until I noticed my app giving incorrect results and starting digging to find out why.  I would think that some sort of warning would have been appropriate.

And frankly, I'm just very surprised I didn't get one.  I mean really -- it seems to me like Eclipse does an amazing job in the area of errors and warnings.

• When I have a warning or an error, Eclipse shows it to me in several different ways, none of which interrupt my work.  The Problems tab gives me a complete list.  In the editor I get yellow or red squigglies.  In the margin I get icons on any line with an error.  In the Explorer view there are icon overlays to show which files have problems.
  
  
• When I'm typing the name of a new class, Eclipse checks the name on every keystroke.  It complains if my current entry is a name that is used somewhere else.  It gripes if the capitalization is inconsistent with typical Java practices.
  
  
• Yesterday afternoon I opened my office window.  Eclipse noticed, grabbed my IP address, used it to lookup my geographic location, checked the weather for Champaign, found rain in the forecast, and warned me to not forget to close my window before going home.  :-)

Seriously, Eclipse is by far the chattiest development environment I have ever used, and that's not my complaint.  I find Eclipse to be extremely pleasant.  It warns me a lot, but its warnings are immediate, appropriate, and helpful.

And that's why I can't believe that no part of the Eclipse environment chose to warn me about the way I was comparing strings.  My expectations had been set very high.  Eclipse warns me so often that I find myself trying to sit with better posture just so I don't get fussed at.  But for some reason, it silently accepts the use of == comparisons on Strings, even though such usage is almost always incorrect.

Bottom Line

I think I'll just end this rant here. 

I regret that this entry is almost completely positive about C# and negative about Java.  For the sake of balance, in part 3 I will focus on several areas where Eclipse is better than Visual Studio.  Way better.  :-)

A couple weeks ago I started another one of my pet coding projects.  My regular readers know that use C# for basically everything.  However, for this project I decided to use Java and Eclipse.

I haven't written any Java code in several years.  The JDK version number back then was 1.1.7.  My coding environments were Symantec Café, Supercede, and emacs.  Refactoring was little more than the topic of Bill Opdyke's dissertation (PostScript file).  Eclipse was years away.

I figure it's time to refresh my perspective.

Curly Braces

My younger daughter sleepwalks.  Every so often she gets up in the middle of the night and starts wandering around.  I'll find her downstairs in the family room babbling about zoo animals.  I take her back up to bed.  In the morning she doesn't remember a thing.  Why does she do this?  I don't know, but I assume anybody would have trouble with their REM sleep after watching two hours of The Suite Life of Zach and Cody.

Or maybe it's hereditary.  Apparently last week I got up in the middle of the night, drove to O'Hare, flew to San Jose, took a cab to the Sun headquarters, spit on their front lawn, came home and got back in bed.  I don't remember any of it. 

What I do know is that the first thing I noticed about Java this time was that the curly braces are all on "the previous line", and my mental health started to deteriorate very quickly after that.

Everything got better when I opened the Eclipse preferences dialog and did this:

Oh, and this too:

These config changes made an amazing difference for me.  Apparently the default style in the Java world is to put the curly brace on the same line as whatever precedes it.  There's just no way I can get used to that.  I'm not saying my style is objectively better.  I'm just saying that I can't cope.

Luckily, the customization features of Eclipse are fantastic.  After making the changes above, I simply press "Ctrl-Shift-F" and all my Java code looks a lot better to me.

I wish it worked outside the IDE.  I've got Head First Java and Java in a Nutshell.  Both are excellent books, but I keep finding my left hand doing the "Ctrl-Shift-F" motion hoping the page will reformat itself.

This morning on the way to work I saw somebody trying to make a turn from the wrong lane.  My left hand did "Ctrl-Shift-F".

Key Bindings

The excellent customization features of Eclipse came to the rescue again for the issue of key bindings.  Between Visual Studio and Eclipse, everything is different.

For example, the three debugger commands I use most are Debug, Step Over, and Step Into. 

• For Visual Studio, the default keys are F5, F10 and F11. 
• For Eclipse, the default keys are F11, F6, and F5.

Truth be told, I had to look up the Visual Studio key bindings so I could type them above.  I don't consciously know what they are.  I just have them buried somewhere in my unconscious mind.  They're automatic.  And when I first tried debugging in Eclipse, things didn't work out so well.

In fact, all the key bindings in Visual Studio and Eclipse are so different that I've been wondering if they're not intentionally constructed that way for malevolent reasons.  However, until I find a key that means "Go to Declaration" in one environment and "Reformat my Hard Disk" in the other, I'm going to set my suspicions aside and just assume that I'm being a little too paranoid.

Still, I wonder what "Ctrl-Shift-F" does in Visual Studio?

Bottom Line

I normally don't like to do much customization of my work environment.  I am, after all, a Windows user.  All my custom settings get lost every time I repave.  It's easier to just learn how to use things in their default mode.

But if I'm going to use both Visual Studio and Eclipse, I desperately need one of them to behave a bit more like the other.

Miscellaneous tidbits of recent news from SourceGear:

• DiffMerge 3.1 was released on October 10^th.  This release includes several improvements suggested in comments from readers here on my blog, including shell integration.
  
  
• Vault 4.0.5 and Fortress 1.0.5 were released on October 25^th.  These were bugfix releases containing lots of little (and a few not-so-little) improvements.
  
  
• Our comic ads have continued to move forward, with episodes 1 through 9 of the arc now available.  We just finalized and sent off episode 10, so it should be posted soon.
  
  
• SourceGear is exhibiting at DevConnections in Las Vegas this week.  This event is a bittersweet moment for me.  I believe it is the first time Vault is being promoted at a tradeshow without me being there.  I wanted to go, but it just didn't work out with my schedule.  Anyway, several other SourceGear staff members are there, so if you're in Vegas for the show, stop by our booth and say hello.
  
  
• For the last few months I have been working on a major upgrade for our online store.  Initially I approached this project with a sense of dread.  I love to write code, but the glue between a web browser and a SQL database is probably my least favorite type of programming.  Still, once I got into it, I gained a lot of enthusiasm for the effort.  It's almost done now and will be deployed soon.  I think this new store is going to enable us to do a much better job serving our customers.
  
  
• Finally, it is high time that I give mention here on my blog to the departure of Dan Schreiber from SourceGear.  Dan was the very first person I hired in 1997.  Corey Steffen was the second, just a few weeks later.  The three of us developed a fantastic working relationship, with a level of trust and communication that is truly rare in business.  In 2004, we formally restructured the company with Corey, Dan and I as three equal partners. 
  
  In the spring of 2006, Dan left SourceGear (with full support from Corey and myself) to take a sabbatical, uncertain about whether he would return.  He spent the next year or so considering a career change, and eventually decided that it was time for him to leave the software field and focus on other things.  So Corey and I accepted his resignation and purchased his share of the company. 
  
  On October 13^th we held a company party to give him the proper sendoff he deserved for his years of excellent work at SourceGear.  He remains one of my dearest friends.  All his former coworkers here wish him well.

Congrats to Neil Davidson for putting on an outstanding Business of Software conference in San Jose last week.  I enjoyed the event very much, especially the opportunity to meet and chat in person with people I had previously known only by email. 

Highlights from the presentations I attended:

• Guy Kawasaki is always a great speaker.
• Bill Buxton offered a very thought-provoking discussion of usability.
• Alberto Savoia's gave the most entertaining discussion of software metrics I have ever heard.

Slides from my presentation are available.  This PowerPoint file contains notes which roughly correspond to what I said at the event.

I walked into my office this morning to discover a large package sitting on my chair.  The box was from "Pinnacle Displays", which I vaguely remembered to be a company that sells some sort of trade show display stuff.  I get junk mail from companies like that on a regular basis, so I assumed this would be more of the same.  Still, this box was way too big and heavy to be regular junk mail.  Anyway, I was pre-coffee, so I set it on the floor of my office and decided to open it later.

By lunch I had tripped over this enormous box several times, each time remarking to myself that the sender had paid way too much for whatever swag was inside.

Late this afternoon I finally decided to open the box and see what the heck they had sent me. 

It was a bag of Evo dog food.

The accompanying letter from Pinnacle's Steve Peterson explained.  I'll spare you the details and just say this:  Steve wanted me to place a link to his website at the bottom of my article Going to a Trade Show.  The bag of food for Sophie was the attention-getter/bribe.

If you visit that article now, you will see that I have acceded to his request, but I struggled with the decision.  I've turned down lots of people asking to advertise on my blog.  How did Steve Peterson get the link he wanted by sending me a $30 bag of kibble?  I've refused cash offers worth hundreds of times more.

I guess I was just terribly impressed by how well Steve executed this stunt.  He perused my blog.  He saw my story about Absurd Customer Service, so he knew that I buy Evo.  Then he not only found a place to buy it (which probably wasn't easy), but he even got the right size bite for Sophie (a German Shepherd).

But that wasn't enough.  The whole gimmick would have backfired if his cover letter sounded smarmy, but the tone was perfect.  This kind of thing is just so very hard to do well, and Steve nailed it.

Bottom line:  I don't like it when people ask me for links or ad placements here, so I really wanted to be annoyed at this guy, but the feeling just wasn't there.  The simple truth is that he didn't tick me off.  Knowing how little patience I have for anybody trying to sell me something, I couldn't help but admire his accomplishment.

So, I offer a tip of my hat to Steve Peterson of Pinnacle Displays.

Note that Sophie had no concerns at all about this whole situation.  She doesn't care in the slightest about her credibility.  She'll do just about anything for food.  In fact, I know from experience that she will happily trade her dignity for half an ounce of store brand mozzarella.

So she was very quick to volunteer to wear the graphics of her new sponsor:

:-)

In C#, the following method will not compile:

public bool IsOrange1()
{
}

The compiler gripes and says:

'IsOrange1()': not all code paths return a value

Which makes perfect sense.  The computer arrives at the end of this method, realizes that it is required to return a value, but does not know what value to return.  We don't want the computer to just make something up, so we have the compiler detect this case and fuss about it.

However, the following method DOES compile without errors:

public bool IsOrange2()
{
    while (true)
    {
    }
}

Which seems wrong.

I'm not saying this version deserves the same error as the previous one.  It is clear that IsOrange2 has no code paths that return while failing to define the return value.  Of course, this is because IsOrange2 has no code paths that return!

I am also not saying the compiler should error on any method that never returns.  There are reasonable uses for that sort of thing:

public void SimpleWebServer()
{
    while (true)
    {
        ListenForOneRequestAndRespondToIt();
    }
}

I am also not saying the compiler should error on any method that does nothing.  If programmers want to write code that has no purpose, the compiler shouldn't care.  This code should compile:

public void DoNothing()
{
}

And so should this:

public void WorkReallyHardAndDoNothing()
{
    while (true)
    {
    }
}

My problem is that IsOrange2 claims that it returns a value but it never does.  That just seems wrong.  I guess I expected to see:

'IsOrange2()': there are no code paths that return a value

If IsOrange2 is never going to return anything, then it should be declared void, not bool.

Maybe this doesn't really deserve an error, but I think it should be at least a warning.