Darren Stokes sides with Joel over Jeff on whether programmers should know C.

This whole debate reminds me of amateur radio operators bickering over whether newbies should be allowed to get a license without learning Morse code.

Morse Code

So Eric, tell us about your experience as an amateur "ham" radio operator?

My call sign is KA9KEF.  To get my General class license, I had to pass a written exam as well as a Morse code test at 13 words per minute.

Really, you know Morse code?  Nowadays, it's possible to get a ham radio license with no code at all. 

Yes, and I think that's outrageous!  It's just wrong.

Why do you think that?

If I had to learn Morse code, then everybody else should too.

So does anybody really need Morse code these days?

Well, I suppose not.  But don't pester me with facts that distract from my point.  Learning Morse code should be a rite of passage for all hams.  Anybody who got a license without code is not a "real ham".

But you -- you are a "real ham".

Yep.  I passed the Morse code test.  13 wpm.

So you're still actively involved in amateur radio?

Well, no.

Oh.  When was the last time you used your ham rig?

I suppose it's been a few years.

How many years are in "a few"?  Maybe five?

More like twenty.

Twenty years? 

Twenty-three, actually.

And you still have your amateur radio equipment?

Well, no.  I sold my station a long time ago.

OK, let's review.  You're a "real ham", even though everything you know about ham radio is two decades out of date.  But the guys who got a "no code" license and are actively practicing the hobby today, they're somehow not "real"?

That's right.  I know Morse code.  They don't.

So you think all ham radio operators should be required to learn a basically useless skill simply because you did?

Exactly!  And don't ask me to get down from my high horse.  I like it up here.

C

The argument about whether programmers need to know C is just so similar.

All of the people arguing that C is important are the people who have already learned it.  I'm pretty sure that a lot of their argument is resting on the same foundation as those crotchety old hams:  "If I had to learn C, then everybody else should too."

I am one of those people.  Yep, not only am I a Morse code bigot, I'm a C bigot as well.

I learned C, and I learned it good.  I've worked on multiple significant C projects.  I even wrote a C compiler.  In C.  I think all "real programmers" know C.

Yep, we C programmers are elitist and proud of it.  The view from up here on our high horse is pretty good.  We see lots of so-called programmers down there:

• They don't really know what a pointer is.
• They're not even using a real compiler!  That thing they're using doesn't even generate native code you know.  It's "byte code", so it's not real.
• Those people have never had to manage their own memory.
• In fact, they've never really had to do anything at all.  I mean really.  They're building on a class library that's got more features in it than Photoshop.

We are different.  We learned C.  We are "real programmers".

One big difference

What's the main difference between hams who know Morse code and programmers know C?

The C programmers actually have a point.

Seriously, strip away all the elitism and see what's left.  Morse code is nearly useless, but C is still darn important whether you're using it or not.

And a lot of people are still using it, by the way.  Don't think of C as merely "important historical and foundational background".  In fact, my current project is being written in C.  Software development today is a big field.  There are still many problems for which C is the best solution.

But even if you're coding in something higher level, the experience of using low-level programming techniques is invaluable.

I'm not going to take a black-and-white stance on this.  I won't go so far as to say that every developer must learn C.  I've met lots of developers without C experience who are successful and making positive contributions to important software projects.

Furthermore, I'll admit that knowing C is not a magic solution to poor skills.  A lousy developer who happens to know C is simply better equipped to hurt himself or somebody nearby.

However, I can say these two things:

1. All of the truly extraordinary developer s I know are people who really understand the kind of low-level details that C forces you to know.
2. Every programmer without C experience has a clear path of personal development:  Learn C.  Get some real experience using C to write a serious piece of software.  Even if you never use it again, you'll be a better programmer when you're done.

People often ask me for a list of my favorite books.  So here it is. 

I reserve the right to update this list from time to time.

I tend to read a lot of stuff.  The fact that I recommend a book here does not mean that I agree with everything in it.

Coding

I think it's out of print, but I really liked Writing Solid Code.  It's very oriented toward C/C++, so if you're mostly in C#/Java/Ruby/Python/Perl/VB, it may not be worth your time.  Still, it's an outstanding book.

And of course Code Complete is a classic.

Software Management

Dynamics of Software Development is one of my favorites.

Business

I'm a big fan of Built to Last and its sequel, Good to Great.  The sequel is easier to read and a bit more relevant to smaller companies.

The Silicon Valley Way is a great book, and it's a very visual book with nice short chapters.  Easy to just pick up and browse..

If you get the opportunity, go hear Guy Kawasaki speak.  He's much better in person than he is on paper.  But if that doesn't work out, Rules for Revolutionaries is a good read.

Marketing

If you read only one book on marketing, it should be Crossing the Chasm.

But actually you should read at least a dozen books on marketing. 

Here's your second one:  Differentiate or Die

Now go find ten more.

Sales

I think Selling the Wheel is an outstanding book.  At first you'll be tempted to stop because it's kind of cheesy.  Don't.  Finish it all the way to the end.

Useless but Enjoyable Fluff

I really like the "Prey" series of novels by John Sandford.  Start at the beginning with Rules of Prey

WPF

I have all of the following WPF books:

• The one by Chris Sells and Ian Griffiths
• The one by Adam Nathan
• The one by Charles Petzold
• The other one by Charles Petzold, focused on WPF 3D

These are all good, each in a different way.  If you're going to do anything serious with WPF, it seems to me that you should own them all.

Other Stuff

The Seven Habits of Highly Effective People is still worth reading.  None of Covey's other books are nearly as good.

Any serious pool player has a copy of Byrne's New Standard Book of Pool and Billiards.

My favorite literary novel is The Count of Monte Cristo.  The unabridged version is worth the extra trouble.

For dog lovers, Marley & Me is terrific.

The Comment

I've received a lot of feedback on yesterday's blog entry.  The two most common questions are:

• Eric, why did you think that working on your Scrabble project was wrong?  It doesn't seem all that bad.
• And since you thought it was so awful, can we assume that you would go ballistic if someone in your company was working on a pet project at the office?

I sort of figured that if I wrote an article about a software manager that I really admire, I didn't need to address the question of how I would react in a similar situation.  It should be fairly simple to connect the dots.

But folks are having trouble with the fact that I held such a strict attitude about my own transgression.  They assume that I would be similarly draconian with others.  A fair assumption I suppose, but an incorrect one.

When it comes to ethics, most people treat themselves loosely and other strictly.  Instead, try being strict with yourself and gracious toward others.  You'll get along a lot better with the world.

Do I really believe that working on a fun personal project at work is such a heinous crime?  Certainly not.  But surely you can agree that goofing off and trying to cover it up isn't exactly the way to win the employee of the month award?

The truth is that I just don't believe in making excuses.  I'm not going to defend myself unless I have solid possession of the moral high ground.

My kids read this blog.  I'm trying to teach them to take responsibility for all their choices, good and bad, big and small.  How can I do that if I'm not willing to set the example?

If I found somebody in my company working on a pet project at work, I imagine I would handle it pretty much like Tim did:  I would be more disappointed in the company than in the individual.  If people are working on hobby code, then they're bored.  In my opinion, the blame for a bored employee splits about 80/20 toward management.

The Correction

Tim's current car is a Lamborghini, not a Ferrari.

The Context:  Being a slacker

In the early months of 1994 I wrote a program to play Scrabble.

It was a magnificent piece of code, easily the fastest Scrabble program I had ever seen.  The implementation (in C) was based on the GADDAG data structure and algorithm explained in a paper by Steven Gordon.  The resulting program was so fast that computer moves were instantaneous.

Unfortunately I had to keep my software a secret.  The lawyers at Hasbro love to send nastygrams to anyone who implements a Scrabble program.  These guys are a lot like the lawyers at the RIAA who have become famous for their lawsuits against toddlers and family pets.  The Hasbro legal team is merely less prolific.

Actually there was one other reason why I kept my Scrabble program a secret:

I wrote the entire thing on company time using my employer's hardware.

At the time I was working for Spyglass.  We had recently finished shipping version 2.0 of our flagship product, Spyglass Transform.  Things were a bit slow, so I was discreetly hacking on my pet project.  I setup my office such that nobody could see my screen from the door.

Unfortunately, I gave myself away.  At times when I was working on my Scrabble code when my boss (Tim Krauskopf) walked in the door, I would flinch and quickly try to minimize the window.  About the third time it happened, Tim said, "All right, what game are you playing?"  Suddenly I wished I actually was playing something like Doom.  In that moment, working on non-company software seemed more shameful than wasting time in a first-person shooter.

I offered a full confession and an apology. 

I don't remember what he said. 

I do remember that he never mentioned it again.

The Inflection Point:  Day 1 of the browser wars

A few weeks later, on April 4^th, 1994, Tim once again stepped into my office.  He said he needed to talk with me somewhere offsite.  We left.

In that conversation, Tim told me that the Spyglass management team was making the decision to abandon our then current business (scientific data visualization tools) and get into the web browser business.  He asked me to immediately begin working and commit to giving a demo to an important potential customer a few weeks later.

I shifted into high gear.  I came in at 5:30 am every day for weeks.  I was writing code at a fantastic pace.  The demo was successful.  We showed them our browser.  It didn't have as many features as NCSA Mosaic, but it was a lot faster.  We didn't tell them that it was written from scratch in less than a month by a kid who had never written any networking code before.  We got the sale.

And that was just the beginning.  The project started out with me alone, but two years later it was a team of 50 with me in a leadership role.  We were the first Internet IPO.  We licensed our browser to Microsoft and it became Internet Explorer.

That conversation on April 4^th ended up being a defining moment for my career.  And it happened just a few weeks after Tim caught me skiving off on the job.

What the %#$@ was Tim thinking?

The Premise:  Tim made a wise choice

I'm going to surface a lesson from this story, but you should probably read no further if you disagree with Tim's decision.

And if you do, I can't really argue with you.  I'm not going to defend my actions.  I was being irresponsible, even dishonest.  There are no excuses for behavior like that.

Maybe Tim should have fired me.  At the very least, maybe Tim should not have entrusted the development of his company's next big product to someone who lacked the discipline to stay on task.

Still, the overall results deserve some kind of voice in this argument.  Tim and his company were very successful.  Tim drives a Ferrari now.  Tim's choice worked out very well for me, but it turned out pretty well for Spyglass too.

The Lesson Learned:  Choose your manager carefully

This story may seem like it's about me, but really it's about Tim Krauskopf.

I've never asked Tim why, so I guess I don't really know.  Maybe he just believes that being obsessive to a fault about code isn't the worst character defect for a developer to have.

I spent five years at Spyglass.  The incident described above is just one of many that left me in awe of Tim's leadership skills and discernment.  I don't think I ever really figured out what makes that guy tick, but I still think of him every time I measure myself as a manager and leader.

The part that seems most astonishing to me is that he kept his emotions in check.  Didn't he feel any sort of disappointment or even betrayal?  Why didn't he overreact?  That's what most people would have done.  I probably would have.

All I really know here is this:

Your manager plays an enormous role in determining the success of your career.  Choose your manager very, very carefully.

• Choose somebody smart. 
• Find somebody who is not merely smart, but "emotionally smart".
• Find somebody who is not merely smart, but wise.
• Choose a person from whom you can learn.

Just to be clear, I am not saying you are powerless.  Your success is mostly determined by your own abilities and choices.

But one of those choices is the decision of who you are going to work with.

Don't take that choice lightly.

Update:  See my follow-up.

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.  :-)