Seeping Matter

This is a very painful and sad post, so by definition it should be hilarious.

It looks like my 1998 Kawasaki KX 250 will belong to someone else tomorrow.  I bought that bike, worn and beaten, six years ago.  I brought it into my garage, took it apart, cleaned it, painted it, put new graphics and a new seat cover on it, gave it a new rear race tire, had the forks rebuilt by Pro-Action, and gave it a new Renthal rear sprocket.

This, my friends, is how you show your motorcycle just how much you love it.

I’ve loved every minute I’ve ridden it.  I love that rush of adrenaline I feel when you kick the engine to life and you feel the motor revving beneath you.  I love the awesome power as you launch off the line and the pull you feel in your arms as you climb through the gears and that amazing 250cc two-stroke powerband.  I love that feeling of soaring high above the ground (where “high” means “a multitude of inches”).  I even forgive my bike for that time I was trying to learn to double-jump and instead I broke my collarbone.

If any girls read my blog they probably think this is so dumb.  And to that, I say this:  I had a fair number of girlfriends when I was single, but when I found one that I felt this strongly about, I married her.  And if that doesn’t show you up, well, I don’t even know what I meant by that.

Seriously, I really wish I could keep it.  Maybe someday, when my career doesn’t require every spare minute of my time and investments of large sums of money in laptops, maybe then I can have another one.

Until then, there’s a part of me that will be dead.  There’s a part of me that will ache every time I watch motocross or supercross racing live or on TV.  There’s a part of me that will feel like I sold my soul in order to try to move my career forward, and that part will let me know how disappointed it is with me for the rest of my life, especially if I fail.

It will definitely be a bittersweet memory.  Like the CRX, I’ll love it forever.  And I don’t care if you think that is stupid.

So, for posterity’s sake, here’s some pictures to remember my baby by:

Catching tons of air at Bunker Hill Raceway in Delta, 2004-ish.

I love this picture.

matt Hobbies, Sports Career, CRX, Hobbies, Motocross

When a mommy and a daddy love each other very very much, like my wife and I, sometimes they have a life-changing event which starts with a very simple conversation, like, “Honey, do you think we should get a new MacBook Pro?”

At least, that’s what happened in our family.

One night, we were just laying there together in bed.  All the kids were asleep.  I turned toward my wife and softly said, “What would you think if we got a new MacBook Pro?”

She got a bit of a twinkle in her eye as she turned and snuggled in toward me.  ”Why do you want one?”

“Well, I’ve been thinking, pretty much it is time for me to get a decent laptop.  Even though I don’t want to spend the money, and even though we are trying to do the Dave Ramsey Dance, I think it is holding my career back.  I don’t think it is wise to continue without one.  I think it is an investment that we need to make in my career,” I said in the most romantic way possible.

She kind of bit her lower lip, then said, “Well, why are you thinking of a MacBook Pro?”

“Their laptops are simply the best hardware available,” I explained seductively.  ”I would dual-boot it with Boot Camp so it ran Snow Leopard in one partition and Windows 7 Ultimate in the other partition.  Then I could create a domain-joined account in the Windows 7 partition with a separate virtual drive that holds all of the company data that I can protect with BitLocker.  That way I can use my laptop to work remotely and also have excellent Mac hardware.  I’m getting excited just thinking about it.”

“Oooooh, baby, I love it when you talk to me like that.  Let’s do it!” she said.  So with that, we turned off the lights and went to sleep.

Some time later, the long-awaited day came.  I was at work when my wife called.  ”Honey, it is time,” she said.  ”The MacBook Pro is here.”

I rushed home to this:

They are prettier after they are born.

I must admit it didn’t look like much. But I know that true beauty lies within. Within the box, I mean.

Sure enough, we didn’t have to wait long before the laptop started making its way out.

It's crowning!

When they first come out they have this weird whitish covering on them.

Now THAT'S a good looking laptop! He (she) is so handsome (pretty)!

It's a boy (I guess)!

We decided to name him Steve, for obvious reasons.

matt Technology Career, Humor, Mac

I attended LaunchUp, a monthly meet-up for people interested in tech startups, last Thursday.  My friend Josh Coates, Mozy founder, spoke first, where among other things he described the two types of people at the event:  people who have done, are doing, or are planning to do a startup, and people who like to talk about it but are too chicken to do it.

I’m definitely in the second category.

Of course, Josh’s talk was the most interesting, in case he reads my blog.  But the second talk, DJ Waldow’s talk on community management, was interesting too, particularly to me as someone who’s tried (and failed) to start an effective online business.  It wasn’t so much that there was any one particular point that Waldow made that really stood out to me; rather, the more he spoke, the more I realized how important what he was saying really is:  In order to compete today, businesses have to be active in managing their online reputation and in creating awareness of themselves among their customer base.  The ultimate?  When your presence in the community and the industry is so prevalent that when they think of your business area, they think of your business.

Since I don’t have my own business, I am my own business.  So this made me wonder, how well am I doing?  How synonymous is my  name with the software engineering industry, or other things?

Since I know how incredibly interested you are, here’s a detailed table of my findings.  For each term, I conducted a search on both Google and Bing.

Search Term:  ”Matt Ryan”: Searching for just my name is pretty disheartening.  No results relating to me in the first twenty pages on either site.  It doesn’t help when you have the same name as a pro football player and a musician.  I don’t even show up on Wikipedia’s Matthew Ryan disambiguation page.  Hrrmm.

Search Term:  ”Matt Ryan blog”: Not much better.  No results for me in the first ten pages on either site.

Search Term:  ”Matt Ryan homepage”: Finally, a result.  Google gave me a result for www.mvryan.org, my homepage, on page 9 result 9; Bing, oddly, gave their first result for me for my user profile page on Novell’s developer website, from back in my days working for Novell’s developer services team.

Search Term:  ”Matt Ryan software”: Now we’re honing in.  Google’s fifth result on their first page was for my developer.novell.com profile page; Bing gave two results for me on their first page; the third for my LinkedIn profile, the eighth result on that page for my user profile on SourceForge.net.

Search Term:  ”Matt Ryan software engineer”: Google showed me love twice on page one, results three and seven, but Bing really showered down their devotion by giving me five results on the first page.  I got top billing with the first result on the first page, along with results four, six, seven, and ten.

Bing really seems to be favoring me more than Google, but surely that’s not because I work for Microsoft; it must just be a coincidence.  Anyway, it seems I’m fairly well associated with my profession, but there’s definitely still some work to be done.

Some other searches:

“Matt Ryan Microsoft”: Google, page 1 result 2; Bing, page 1 result 2

“Matt Ryan Mozy”: Google, page 1 results 2-6 (oddly, the first result is for a Matt Ryan on the mozy.com blog but that isn’t me, even though I worked for Mozy for a year); Bing, page 1 results 1,2,3,5,6,9

“Matt Ryan Novell”: Google, page 1 results 1-6, 8-10; Bing, page 1 results 1,2,4,5,8-10

“Matt Ryan Eclipse”: Google, page 1 results 1,3,5,7; Bing, page 1 results 1,4,6,8,9

“Matt Ryan IBM”: Google, page 1 result 2; Bing, page 1 results 1,10

“Matt Ryan Spillman”: Google, page 1 results 1,2; Bing, page 1 result 1

“Matt Ryan utah”: Google, page 2 result 2; Bing, page 1 result 1

“Matt Ryan 350z”: Google, page 1 result 2; Bing, page 1 result 3

“Matt Ryan world superbike”: Google, page 1 result 1 (and 2, and 3); Bing, page 1 result 5

“Matt Ryan supercross”: Google page 1 result 9; Bing, page 1 result 9

“Seeping Matter”: Google page 1 results 1-4,6,8; Bing, page 1 results 1-4

“Coding Frogs”: Google page 1 results 1,2; Bing, page 1 results 1,2

matt Technology Career, Software Development

I have a good friend named Chris Cooper.  (No, not the actor.)  I worked for Chris for many years when he was Director of Developer Services at Novell; now, Chris is a partner with UV Partners, a venture capital firm in Salt Lake City.

Working for Coop (he goes by Coop, not Chris; calling him Chris seems weird) was a very important educational experience for me, primarily because Coop is a businessman, not a technologist, by background.  Because of this, Chris taught me things about the software business that no other manager or director that I’ve worked for has been able to teach me.  In particular, Coop helped me understand many of the reasons why Novell made some of the decisions they made, and why they didn’t make others I thought they should.  Knowing this doesn’t mean that they are right, but it certainly helped me to gain a different perspective.

Some time ago I had the opportunity to meet Coop for lunch in Salt Lake City.  I asked him how he was liking his work and he gushed about how much he loved his job.  Then he admitted, “You know, I never would have even considered this as a career opportunity for me, let alone would I have thought I would like it so much.”  He briefly covered his background — education in business, joined Novell as a sales representative, established key relationships with others, always tried to execute in his assigned role — and then this opportunity played out for him.  We discussed how odd it is that as young people we fret so much about which major to choose and which college to go to and which classes to take and which job opportunity to pursue, almost as though we think that the sum of of these decisions is going to head us down a career freeway, at high speed towards a specific destination, with no exits or detours or scenic byways, when in fact many, many people end up somewhere completely different from what they had planned.

I mentioned this later to a long-time friend who had spent many years in his chosen profession as a physical therapist before making a career change to sell educational technology to schools (yeah, I know!).  Of course he could really identify with this.  He said that often we think of our career not only as a path, but as a freeway like I just mentioned.  But in fact, he said, our career is more like a waterway.  It might be a little stream, or a large river; it might be straight or twisty; it might be fast-moving and exiting, full of whitewater rapids, or it might be slow and steady, if somewhat boring.

He continued the analogy by saying that as you float along the waterway you’ve chosen, you might eventually realize, “Uh, I don’t think this is going where I want to go anymore.”  Maybe it started out going the direction you wanted, but quickly or gradually turned a different way.  Maybe you thought it was heading one direction, only to find that it actually wasn’t heading where you thought it was.  Or maybe it is still going where you once thought it was, but you’ve changed your mind about what you want.  Clearly, if you want to end up where you intended to go, you’ll have to pull your raft out of the waterway and choose another one.

That’s why I say, your career path probably isn’t.  It probably is a waterway.

This is why this post over the weekend by Seth Godin really stood out to me.  I’ve got a big extended family with lots of younger people (siblings, siblings-in-law, cousins, etc.) for me to give advice to that they can quickly ignore.  I’ve seen many of them struggle with this.  They choose a major because it is easy instead of choosing a major because it is interesting, or they don’t finish their degree at all, or they don’t even make choices in college or a career because they are afraid to commit their whole life to it.  I believe in the value of education, but sometimes I’ve wondered why it matters at all if your career is so much left to chance?

Seth’s post identifies the link for me.  Education should be preparing you to take the choices as they become available to you.  You might have a career endpoint in mind, but you can’t be so in love with that endpoint that you won’t consider opportunities and alternatives that become available to you along the way.  How do you even know you will like that endpoint anyway?  Fretting about choosing the right endpoint is pointless.  Your career isn’t a path, it is a waterway.  You don’t know whether the waterway leads where you want or not; you choose one based on the best available knowledge and judgment you have at the time.  You can always get out and choose another one.  So just get in and get started!

matt Business, Education Career, Editorial, Introspection, Novell

Last week Novell announced that they are finally getting rid of their CTO, Jeff Jaffe.  It’s buried in the press release, but if you look hard enough you’ll find it.

It’s really too bad, because this press release really did not do much in the way of raising Novell’s stock price.  It must be because the news of Jaffe’s departure is buried.  If Novell had made a press release just about that, stock would surely have gone up.

As far as Novell goes, things can only get better.  I heard people were literally cheering in the hallways when they heard the news.  No, I’m not making that up.

Understand, I don’t have anything against Jaffe personally, so this isn’t meant as a personal attack.  I really don’t want to get too critical of people, generally.  But the fact that Jeff Jaffe was a CXO-level professional says a lot about what is wrong with corporate America in general, and Novell in particular.  He was very well compensated because he was expected to lead the company, but instead people at Novell wonder what he even got paid anything for at all.  If you had worked at Novell, you would know what I mean.

In a technical company like Novell, the CTO, if you have one, is expected to provide the technical leadership.  What products should we be focusing on?  What company strengths are we going to leverage?  Who is our target market and our customer?  What is our go-to-market strategy?  What is our partnering and third-party-developer strategy?  You’d expect a CTO to be intimately aware of all this stuff, and providing clear, consistent, and frequent direction to his engineering core to help bring about a technical vision that will win in the market place.

Jaffe’s strategy, on the other hand, was to completely disappear.

In fact, the only time I can ever remember him saying anything at all was just after he’d held a two-week-long brainstorming session with a bunch of his distinguished engineers.  I knew they were doing it, because it was going on in a conference room on my floor at Novell, right by the bathrooms and the elevators.

Presumably, the purpose of this session was to get the Novell brain trust together and answer questions like these to come up with a competitive strategy.  Of course, I wasn’t in the meetings, but the accounts I heard were a bit different from what I’d expected.  Apparently Jaffe went into the meetings with an idea of what the strategy was.  The first week was spent with the distinguished engineers trying to help him see that his strategy was not going to work.  Towards the end of that week they collectively gave up, and spent the second week trying to figure out how to not make his strategy sound so ridiculous.

A few days after the meetings, he announced his strategy in a company-wide conference call.  Basically the strategy was this:

• The open source community is full of people who like to develop software and give it away for free.  They just like to work on interesting projects.
• We like to make money on software and we have lots of great ideas.
• Thus, perfect synergy.  We will give the open source community ideas of software to create that will make us money.  Since they have nothing better to do, the open source community will gladly make this software for us.  Then our engineers will add a few key features, tie pretty bows around it, and sell it.

This same day I received an offer to work for Mozy.  It was pretty clear that Jaffe’s strategy was a joke.  Embarrassing, even.  I remember thinking, “Things are never going to change around here if this is the best strategy our CTO can come up with.”

I was pretty discouraged about it.  It is hard to work for management that doesn’t instill confidence.  It is really surprising to me that a person could make the kind of salary he made with the kind of title he had and still do such a lousy job of leading.  How in the world did he ever get the job in the first place?

After the call, I walked to the office of a teammate to vent about it.  I told him, “I know in the past I’ve joked about some of the decisions different people in our upper management team have made, and I’ve quipped, ‘I could do their job better than that!’  Of course, we both know that I was kidding.  But this time, I’m completely serious when I say this:  I could do the CTO job better than Jeff Jaffe.  I know I could.”

My friend said, “Yes, I know.”

When I was at Novell, this happened fairly often.  Employees regularly felt very discouraged, disheartened, and demotivated because of executive management.  I figured that was pretty much just the way companies worked, and that it happened like that everywhere.

Which is why I marveled at this fact, when Jaffe left.  I contemplated how I’d felt that way, and realized that I’ve never once felt that way about my management chain at Microsoft.  On the contrary, I find that I am continually amazed at the level of professionalism, attention to detail, quality of decision-making, and overall caring about the company that I find in my management chain.

I thought perhaps it’s just because I’m new, so I mentioned this to a guy on my team who’s been with Microsoft for over ten years.  He said, “Pretty much, that is how I’ve always felt about my management chain too.”

Novell breaks my heart.  I wanted so badly for Novell to succeed while I was there, and I still want good things for Novell.  I know many great people who work there.  Novell’s problem has never been in the individual contributors; it’s been with the company leadership.

So getting rid of Jaffe can only be a step forward.  It may be too little, too late, but it’s worth a try.

matt Business Career, Microsoft, Novell, Rants

Last week marked three months that I’ve been working at Microsoft.

As I’ve discussed before, making the decision to leave Mozy for Microsoft was not an easy one.  Let’s face it:  I’m not exactly a spritely youth anymore.  I’ve worked at a lot of different companies — and when I say “different,” I also mean, “different from each other:”  Small companies you’ve never heard of (Spillman Technologies), large companies you’ve surely heard of (IBM), companies whose politics continue to keep them from succeeding (Novell), companies who manage to succeed in spite of the politics (Mozy), and companies that just frankly exist only as dark, ghostly nightmares in the frightening nether regions of my mind (Enterasys Networks).  Yet as different as these places are from each other, one thing mostly remains the same:  the process of creating software is the same everywhere.

So that makes a decision to leave hard.  Since the process of creating software is the same everywhere, it is the intangibles that end up mattering, such as whether you like your boss, whether you get a nice computer or monitor, how comfortable your chair is, etc.  When you consider leaving, you wonder what unidentified intangibles you’ll be giving up and what you’ll be getting, and whether you will feel like this was a good trade a year later.

Leaving Novell for Mozy was like this for me.  I got many, but not all, of the intangibles I expected when I went to Mozy.  I gave up all of the intangibles I expected I’d give up from Novell, like five weeks of paid vacation and a beautiful window office on the 7th floor looking directly north to Mount Timpanogos.  Some things at Mozy ended up being worse than I expected, e.g. the 5% pay cut last spring.  Of course, I do realize that it is not Mozy’s fault that I didn’t get all the intangibles I expected; I set that expectation, not them; I failed to assess the situation accurately.

Nonetheless, as I contemplated leaving Mozy for Microsoft, I thought about this.  “Well, software engineering is the same everywhere.  So since the in-and-out of the job function is mostly the same, I wonder what intangibles I’m gaining and what I’m giving up?”

Well, I failed to assess the situation accurately again.  I made one key error:  Software engineering is NOT the same everywhere.

In particular, it is not the same at Microsoft.  At Microsoft, software engineering is more… uh… yeah:  more.

More better.

Have you ever worked for Microsoft?  If you haven’t, you don’t know anything about us.  I know you think you do.  You don’t.

Never in my career have I ever worked in any organization that took software engineering as seriously as Microsoft does.  I was very surprised to see how seriously we consider things like security and software quality.  I’m aware of the reputation Microsoft has received over the years for bugs and security issues.  Maybe things are different now, or maybe that whole thing was just a function of being the world’s largest, most powerful, and most widely used software company.  At any rate, I can tell you from personal experience that security and quality are very important here — important enough that we will delay shipment if we don’t feel like it meets our standards.  While this may seem obvious, I’ve never seen this commitment to quality permeate throughout an organization like it does here.

It has been incredibly refreshing to see a company take software engineering as seriously as I do.  I love that I’m free to require explanation or justification from my management when I don’t understand something.  I love that I’m supported in insisting on perfection in software design, code, and process to the degree that I can help us deliver it.  I love that people can communicate with me honestly and openly without worrying about my feelings, and that I can do the same with them, because, unlike some places I’ve worked, there is an undercurrent of trust and mutual respect between me and all of my peers wherein we know and believe that, despite having different opinions, we are each talented and capable professionals with the best interests of the company at heart.  I love being surrounded by incredible talent that makes me feel both humbled to be a part of the group and inspired to improve myself every day.  I love working for a company where, instead of feeling like my career has topped out and has nowhere else to go, I feel I have broad, wide-open vistas of learning and advancement just laying before my feet; opportunities sitting before me just waiting for me to seize them.

I had no idea a software company could be that much better than what I’d experienced in the past.  It is really awesome.  It may not be for everybody.  Not all software engineers care enough about delivering quality software that they will do whatever it takes — write unit tests, participate in code reviews, follow rigorous and time-consuming processes, be a small fish in a big pond — in order to do it.  But if you care about delivering quality software, like I do, I must say I highly recommend us.

After only three months I find myself saying something I never thought I’d say:  I love working at Microsoft.  I really do.  Intending absolutely no negative to any other company I’ve worked for (with the exception of Enterasys Networks, I have fond memories of great talent, great people, and great product deliveries at every company), working at Microsoft is unlike anything else I’ve ever experienced.

matt Programming Career, Microsoft, Mozy, Novell, Programming, Software Development

I got an interesting e-mail the other day from Novell:

Please Note: You have been sent this email because you are listed as an administrator of one or more Novell Forge projects.

When Novell Forge was first launched Novell recognized the need for a site dedicated to providing hosting services to a growing number of software development projects, many supporting our open source initiatives. Novell Forge quickly grew and was soon providing these service to nearly 1000 such projects. Demand for new projects has all but disappeared during the past two years while a number of additional project hosting options have begun that can provide a similar set of services to those of Novell Forge.

Now that there are many other options, Novell can turn its focus to other areas and pass the project hosting responsibilities to these other dedicated hosting sites. Novell will be decommissioning the Novell Forge system on December 15, 2009.

This is interesting to me because it is not entirely true.  I should know, because without me there would never have been a Novell Forge.

It’s a bold statement, I know.  It’s one I’m happy to explain.

I came to Novell from IBM in 2000.  It didn’t take long to realize that Novell’s developer story and strategy, or rather the complete lack thereof, was (and still is) a significant weakness in their overall execution.  People buy a computer operating system in large part because of the applications that they can run on it; if a business wants to run a CRM system, they’ll want to be sure that whatever platform they buy will run a CRM suite that is acceptable to them.  This is why having a strong developer strategy is crucial to platform providers, and almost everyone seems to understand this.  Novell certainly should; NetWare owned the x86 server market in the 80’s and early 90’s until Microsoft entered that market.  Initially, the Microsoft offering was not necessarily better than NetWare in terms of stability or performance, but Microsoft definitely outgunned Novell when it came to applications.  It was so much easier to create applications for Microsoft’s platform that their supported portfolio dwarfed Novell’s, and that was a significant key to dethroning Novell’s dominant position in the x86 server market in the mid 90’s.

Anyway, when I came to Novell and learned this, I thought that probably Novell’s Developer Services organization just didn’t know what to do (a mistaken analysis, I later learned) and if I worked there I could probably fix everything.  I was pretty young, arrogant, and naive then.  But in 2002 I was presented an opportunity to work in Developer Services and I took it.

One of the first things I was asked to do was to provide support to customers programming to eDirectory.  I decided to try to learn more about how to do this the same way our third-party developers would, by using the resources that were available online.  I found what appeared to be our authoritative how-to-program-to-eDirectory tutorial, got most of the way through my sample app, and got stuck.  Finally I started asking questions.  I quickly learned that everything I’d been doing was wrong; the authoritative documentation was incorrect.  It used an out-of-date and deprecated API and was no longer considered best practice.  It was some two or three years out of date, but hadn’t been changed yet because changing the documentation was just too painful.

I felt this situation was unacceptable.  We needed the freedom to create an abundance of rich and helpful developer content and to have it published and updated freely and frequently.  We needed to be able to do this without going through drawn-out and tedious approval processes and staging phases for even minor edits.  We needed to be able to continuously deliver not only whitepapers but tutorials and sample applications.  I felt that what was needed was a complete overhaul of Novell’s developer site, converting it into a web application where administrators (Novell Developer Services employees) could update the content and have complete control over what information was being provided to our developer community.

I discussed this with a colleague and my manager, and then we called a formal meeting to discuss this proposal.  I think there were four Developer Services employees in the room.  As we discussed the reasons to do this, other advantages surfaced.  A key issue was that, in Novell’s then-existing developer forums, many Novell developers were already contributing to solving each other’s problems, including answering each other’s questions and even sharing code, from small snippets to complete applications.  We realized that instead of top-down support flowing from company to customer, what our customers really preferred was community support with Novell as an active participant.  As we discussed this, one of my colleagues suggested that instead of writing the web app I suggested, we should do a project hosting site, like SourceForge.  Such a site would allow us to participate as a community with our users to exchange sample code, documentation, tutorials, and other content.  Novell Forge was born.

As we began to socialize the idea, we found out that a separate group within Novell had been tasked with creating a project hosting site for internal company use.  When we both became aware of each other’s goals, the synergies were obvious and it seemed apparent that we should try to coordinate our efforts.  Interestingly, we had human resources to give to the project but lacked funding for capital expenses; the other group had capital expense budget but lacked human resources.  Ultimately we agreed that, as my team developed the Novell Forge solution, we would also develop an internal-use version of the site to meet the goals of this team; in exchange, they would help us to get the hardware we needed to host Novell Forge.

Around the time Novell Forge was launched and completed, a number of people involved directly or indirectly from that team claimed credit for having launched Novell Forge.  Some of them were quite handsomely rewarded by the company, presumably at least in part due to their claimed credit for the site.  Others still claim in public that they are responsible for the site even though they had absolutely nothing to do with the conceptualization, proposal, approval, or implementation.

Meanwhile, those of us who did come up with the idea, who did make the business case and get the approval and deliver the site, well, we pretty much had to settle for a brief pat on the back from Novell.  Or did we even get that?  Anyway.

Novell Forge, despite its pretty lame name and humble beginnings, was actually quite well received by the press.  It earned kudos for Novell from Dave Kearns of NetworkWorld, which was not exactly easy to come by.  And as Novell tried to reinvent itself with an open source focus, purchasing such open source companies as Ximian and SUSE Linux, the existence of Novell Forge was frequently cited as evidence that Novell was serious about an open source strategy (example).  Interest in the site grew quickly and it soon hosted over 1000 external projects, as stated in the e-mail I quoted above.  My team was excited about the traction the site was gaining.  We had many, many ideas for how to grow the site and make it an even more useful tool for software developers.  We had more work to do than time to do it, and it was neat to feel like what we were doing had an impact to Novell.

Even though Novell didn’t seem to care about it.

Oddly, in spite of what my team thought was a pretty obvious success, we could not get approval for funding to continue to promote the site.  The team was gradually reduced in size, again and again.  When people would leave, their vacancies would languish unfilled until that position was eventually lost.  The team was instructed to not develop the site but instead to work on undefined new work in other undefined areas, wasting many person-years of development effort.  The community could sense Novell’s lack of investment and they lost interest.  Novell Forge became a laughing stock.  It was used as evidence of what a company does when they “just don’t get” open source, when it was ironically used as evidence of Novell’s good faith not too long before.

Things finally came to the point where there was only one employee assigned to maintain the site, along with other unrelated duties (I, and the rest of the team, had by now been reassigned to different projects).  Novell Forge was completely unsupported by Novell’s IT group, leaving instead the support of the site to this one individual.  I recall an occasion where the site went down over the weekend and was out for a couple of days.  It was obvious that the site was in demand, because users made Novell aware of the outage quite quickly.  However, Novell was not willing to pay for 24/7 support for the site, so instead of being brought back online right away, the site was down for the entire weekend until that resource came in to work the next Monday.  My manager brought this to the attention of our team with the insistence that we address it.  He stated that from that point on, that one employee would be the primary off-hours maintenance person for the site, and I would be the backup.

I then asked if Novell was going to start reimbursing me for my cell phone bill.  He said no.  I asked if they were going to buy me an additional cell phone, pay that bill, and also pay me extra to carry that additional phone.  He said no.  He said they would just list my personal cell number in the emergency contact list, and would call it if there were an emergency.  I stated that in that case I maintained the right to not answer.  He stated that I would have to answer, that it was my assignment.  I claimed that Novell could not require me to answer my personal cell phone if I’m the one paying the bill.  I then reminded him that in Novell’s support organization, at least at that time, people that were expected to respond 24/7 had their cell phone bill paid by Novell, were paid an additional amount to be on call, and were paid an additional amount if they actually took a call and worked that call during off hours.  I said, “If the site is important to Novell, that is what Novell should do.  If the site is important, it should be important enough that Novell is willing to pay in order to maintain uptime and keep our customers satisfied.”

Novell was not willing to pay.

I shortly moved on to a different team within Novell, and the other guy left the company altogether.  I’m not sure who has been maintaining the site since then.

What Novell chooses to do with their money and their human resources is their business.  This isn’t meant as a criticism; I don’t claim to have the right experience to criticize their decision to strangle Novell Forge to death.  This is simply meant as a statement of fact, and the facts are pretty clear:

• You get what you pay for.
• Novell did not pay for Novell Forge by giving due reward and recognition to those who truly brought this idea to the company.
• Novell did not pay for Novell Forge by feeding its success with additional funding, promotion, and development.
• Novell did not pay for Novell Forge by giving it the kind of support and maintenance that its customers expected.
• The customers of Novell Forge were initially enthusiastic, but grew to sense the lack of commitment by the company and thus stopped participating.
• Novell Forge died as a result.

Novell Forge may be planned for decommission this December, but it died years ago.  And don’t think you can fool me, Novell.  Novell Forge did not die because of lack of interest by the user community.  Novell Forge died because you did not care about it.  Whether that was a good decision or not is not for me to decide, but please, Novell, at least be honest with your community.  We did not kill Novell Forge — you did.

UPDATE:  Dan Reese, a member of my team back then, corroborated this in his blog.

matt Rants Career, Editorial, Interesting, Linux, Microsoft, Novell, Shameless Self-Promotion, Software Development, SUSE

Last Thursday, 9/3/09, was the grand opening of Microsoft’s Utah Development Center (UDC) at Thanksgiving Point in Lehi, where I work.  We’ve been working here since the beginning of August, so this was more like the “official” grand opening and not the “technical” grand opening when we are first allowed to enter the building without wearing hard hats.

Microsoft invited Senator Orrin Hatch to attend the grand opening.  In the spirit of full disclosure many of you who have read this blog for a while know that at times I have exercised my constitutional right to express my opinion on Senator Hatch on this blog before; he does represent my state after all.  However, since he attended as a guest of my employer, I’ll keep that out of it for now, and express a sincere thanks to him for making our grand opening a special event for us.

Brad Anderson, the Corporate VP over UDC, was also here, as were other business dignitaries from Utah and some news folk.  He demoed to Senator Hatch the Microsoft Surface that we borrowed from Redmond for a few days just for this occasion.

Brad Anderson tells Senator Hatch about Microsoft Surface (Photo Courtesy Andy Hodgkinson, reused by permission)

Then Senator Hatch picked up a plastic guitar, quickly formed a band, and began shredding to Guitar Hero World Tour.

Utah's Newest Band - Senator Hatch and the Important People (Photo Courtesy Andy Hodgkinson, reused by permission)

(They are not very good.)

About this time is when the press conference began. All us employee-types were ushered into the foyer for a photo. You know how when you are trying to do something important, you distract your little kids by giving them something else to do? And how you might even say to your eldest child, “Can you go entertain them while I get this done?” That is pretty much what happened. They sent Senator Hatch in there to keep us from coming back in and ruining the press conference.

Microsoft UDC People, and Senator Hatch. Yes, I'm in this photo - I'm the incredibly handsome one. (Photo Courtesy Andy Hodgkinson, reused by permission)

I know, it looks like a family photo.

Later, we found out that apparently Brad explained to the press that here in UDC we work on “virtualization technology, which is one of the hottest areas in the tech industry today.” This is pretty accurate.

Unfortunately for KSL News, who picked up the story, they don’t really understand what “virtualization” is.  So when they graciously ran the news story, they made it sound like both the XBox 360 and the Surface are developed here in Utah.  And the Deseret News article made it sound like a lot of the key features of upcoming Windows 7 were developed here in Utah also.

I came to work very excited the next day.  I was excited to see how much we’d gotten done in just one month; I had no idea.  Alas, I found that the news folk were misled.  We are still working on enterprise desktop virtualization, just like we always have.  I had to resign myself to the fact that our team is simply freakin’ awesome, not unbelievably freakin’ awesome.  Oh well.

matt Technology Career, Microsoft, Shameless Self-Promotion, XBox

Merriam-Webster’s dictionary defines discipline as:  “…”

Nah.  Just kidding.

Most software teams I’ve worked on have had some degree of discipline around what code changes go into the codebase.  This tends to take the form of:

• Any change should be associated with a defect or feature that is documented somewhere.
• Commit small, isolated, related changes, all associated with a single defect or feature, that can be easily rolled back.
• Test changes before committing them; avoid breaking the build at all costs.

That last one seems most obvious, but it is so critical that it has to be stated anyway.  Think of it this way:  If you work for me on an already functioning product, I would rather have you do NO WORK AT ALL than to break the build.

Of course, I would not pay you to do no work at all, either.  But breaking the build is taking the product in the opposite direction from where we want it to go.

Some time ago I worked on a software team* where a team member had a problem with this kind of discipline.  Details don’t matter too much, but the net effect was that whenever this person made a commit, the rest of the team would tense up and hold their breath as they integrated the updates.  This person had broken the build enough that his/her commits weren’t trusted by the rest of the team.  And even if the code would compile and run, you still didn’t trust the changes because this person would often sprinkle in little changes hither and yon that were not tied to a documented defect or feature, and often wouldn’t even call out the changes in the commit message.

(As a slight distraction here, I’ll point out how frustrating this is when the team member works in the same office as you, as cited above.  When that person works remotely, it becomes MUCH MUCH WORSE.)

I discussed this with my boss one day who wasn’t sure what to do.  We had a person on the team who was obviously very talented, but who was just not following good practice despite repeated requests to do so.  I offered up the suggestion that I’m restating here, which is basically the following:

Disciplined software engineering should be a prerequisite to having the rights to make critical code contributions.

In other words, no matter how talented a programmer is, they shouldn’t be allowed to contribute code to critical parts of the product if they do not exhibit sufficient discipline to be there.  So what are the “critical parts” and what is the “sufficient discipline”?  The critical parts are the parts that, if they are broken, the software doesn’t perform it’s primary function.  For a product like Firefox, the “Help” dialog is almost certainly not critical, but the HTML parsing engine definitely is.  The sufficient discipline is what I outlined above, but primarily centered around not breaking the build.

So to summarize, what it means is, someone who continually breaks the build should be disallowed to commit changes directly to the critical parts of the product until they earn that right back by adopting the discipline required.  Of course, if you are that free-spirited maverick, there’s a pretty strong incentive now to change your approach.  You may not be paid to be disciplined, but you are paid to deliver software, and if you can’t deliver software because your approach is irresponsible, this should encourage you to get on track.

Some teams choose to approach this by building elaborate systems that enforce proper behavior.  I could build a complex checkin proxy that automatically merges my changes with the latest changes in the repository, builds the product, and then runs the tests (there are tests, right?), and then only makes my commit once all of that passes acceptably.  That’s nice and all, I suppose.  But it seems like a lot of infrastructure, overhead, and process to impose upon the whole team, when to me it seems reasonable to expect that professional software engineers have enough discipline to do this on their own.

So if you aren’t doing this now, how do you go about changing?

Well, you’ve gotta have a suite of automated tests in order to do any of this – a “broken” build is defined as one that does not pass the automated tests.  If you do not have any automated tests, it is time for you to repent, my son.  I do not have time to go into this here, but you must confess your grievous sin and atone by writing an automated test and adding it to your build process.  Just one test is enough to get started – but it MUST be available as a part of the normal build process.  Then every time a build passes the test suite but is, in fact, broken, update your test suite.

Now that you have automated tests, insist that your developers do the following before they commit:

• Update.
• Build.
• Test.

See?  It’s easy.  If the tests pass, they can commit.

Now it is time for you to be disciplined.  Committing code that does not pass the tests is a naughty thing to do.  Do not let your developers be naughty.  Take immediate action.  I think I’d take the following approach:

• First time is a meeting with the boss.  Go over the process.  Make sure they understand the process and what happened.  Personally, it seems like it would be tough to misunderstand, but hey, things happen.  Don’t be presumptuous or condescending.  This meeting alone might be enough to get most people in line.
• If the problem continues, require peer review before checkin.
• If the problem continues, another meeting.  This time, express that all of their current assignments have been reassigned to other members of the team, and they are being reassigned work that is not critical to the functionality of the project.  Let them know that you are concerned about the impact this will have on their performance, because they are expected to contribute at a higher level than what their new assignments will allow.  They have to demonstrate changed behavior and commitment to discipline in order to earn the right to do the important work again.
• If the problem continues after that, it is probably performance-improvement-plan time.  Or mutual-agreement-that-they-find-a-different-employer time.

*(To my faithful readers who think they know what situation I’m speaking of, may I remind you that I’ve worked for seven different software companies and thirteen-ish different software teams over fourteen-plus years in this career, so be careful what assumptions you might make.  Thank you.)

matt Programming Career, Editorial, Programming, Software Development

It took me a while, but I finally settled into my routine and got to where I’m reading my RSS feeds most days again.  I was going through the posts of the past month or so, since the job change, and ran across this article on the “Making Good Software” blog about things that keep someone from being a good software engineer, outside of (and often in spite of) an ability to engineer software.

I’ll summarize here.  It isn’t my intent to plagiarize; if you are remotely interested go read the article.  Here are the things:

• Lack of discipline
• Big ego
• Poor communication
• Forgetting the customer
• Lack of proper work prioritization

I have known many of these people during my career.  Indeed, I was one of them.  I remember coming to Novell from IBM almost ten years ago.  I thought I was pretty hot stuff and I made sure my team knew it.  In fact, I actually said (this is embarrassing to admit) on more than one occasion, “There are people who know C++ better than I do, but I haven’t met any of them.”  My ego surely made me hard to work with.  It definitely was a cause of friction between myself and my management chain, and ended up being a (deserved) source of frustration and difficulty for me, until I recognized the problem and started working to address it.

I’m pretty ashamed of having behaved that way back then.  I hope I’m better than that today.  I guess recognizing the weakness is a good first step.  Fortunately for me, back then I was on a really great team with a lot of very capable, patient, and talented engineers that waited for me to learn from my mistakes and to grant them the mutual respect they deserved.  I consider myself pretty fortunate to have been able to learn from them what real software engineering is about.

Over my career I’ve had to work with people like this from time to time, software engineers that manifest one or more of these traits.  Sometimes these guys are pretty talented technically.  I’ve felt sorry for them as I’ve observed, realizing that these weaknesses are going to hold their career back until they recognize them and work to overcome them.  No amount of programming prowess will compensate for it.  And what’s even worse is, often because these people have the personality issues they have, you don’t get anywhere by trying to bring these weaknesses to their attention; they are often unreceptive to this type of feedback.  Like I said, you just have to wait until they recognize it themselves.

I can imagine being in a performance review with someone like this, having them explain to me all the technical awesome they did, and me replying, “Your poor soft skills are shouting so loudly that I cannot hear your technical awesomeness.”  Or, as I said in the title, actions speak louder than code.

I really believe this is true.  To write software professionally, of course you must have technical ability; however, this is a necessary but not sufficient condition for greatness.  The best software engineers I’ve had the fortune to work with in my career, past and present, not only had awesome technical ability but did not exhibit weakness in these areas.  And I’ll tell you what:  Those teams are wonderful teams to be a part of.  Those teams create strong. uplifting work environments and are able to deliver great products that meet customer demand.

Another way to say this is, in order to be a good software engineer, you must first be a good employee.

In fact, I’ll tell you how important I think this is.  The ability to mitigate or eliminate these defects from a software engineer’s persona is so important to me that, if I had my own company and were making the hiring decisions, I would not hire a candidate that I knew had these problems, no matter how incredible their technical ability.

A person with these weaknesses is really only suited to be set to the side to work on a special side R&D project where interaction with other employees is limited, and they don’t have to interact with customers at all.  Problem is, those kind of projects are either a) strategically important to the long-term future of the company, or b) of little to no real value, or c) a combination, often high potential value but with a lot of inherent risk that causes the real value to be low.  If the project is strategically important or of high value, do you really want to reward the biggest jerk in your company by giving him the highest profile assignment, leaving your best engineers to maintain the legacy project?  Wouldn’t you want to have someone working on that high profile assignment that knows how to collaborate with others and assemble all the best ideas to solve the problem the best way, even if that solution isn’t his/her own?  Contrariwise, if the project is of little real value or has so much risk that it offsets the real value, why even do it at all?

Nope.  In my company, if I were ever to have one, I wouldn’t hire or keep an employee who had these weaknesses and was not committed to addressing them.  I’ve seen the difference, both in morale and productivity, between teams where they don’t have these problems and teams that do.

matt Programming C++, Career, Editorial, Introspection, Novell, Programming, Rants, Software Development