For most, it is just another open source project, but for me, it is a part of me.  There’s not much there yet, but I’m pretty pleased with it anyway.  If you are interested, take a look or even get involved; I’d love to have you onboard.

“What kind of computer work did you do?” I asked.

He replied, “Oh, I worked for Boeing for 24 years writing COBOL software.  Then they laid me off, and I couldn’t find another job.  So now I drive an airport shuttle for minimum wage plus tips.”

I’ll be 16 years into my career this  year.

To say that was a bit of a wake up call is an understatement.  It said to me, “Matt, you are 2/3 of the way to irrelevancy.”  Time to get things into gear before it is too late.

I started off 2010 with some enthusiasm and even determination, you might recall.  My intentions were good, but apparently karma didn’t like it.  Maybe I came across too arrogant, I don’t know.

All I know is that in 2010 it seemed like the blows just kept coming, one right after another.  You know in those Rocky movies (just pick one, they are pretty much all the same after Rocky 1) where, at some point during the fight, he just stands there and keeps getting hit over and over and over again?  Yeah, like that.  $12000 of car repairs in a single year alone can do that to you, even if you aren’t trying to do the Dave Ramsey dance.  If you ARE trying to do the dance, that makes it worse, because it compounds the feeling of failure.  Combine with that a major misunderstanding at work plus missing a coding deadline right around the same time my daughter came down with a serious life-threatening illness causing me to miss a week of work with her in the hospital right at the time year-end evaluations were due…

It was not a very good year.

So it was early last fall when a friend of mine suggested I read Seth Godin’s book “The Dip,” which I immediately followed with “Linchpin.”  Reading these two books in that sequence changed my entire outlook on my career.

The premise of “The Dip” is very simple.  Think of a time when it has seemed to you like things just aren’t working out, when they seem harder than they should be and not nearly as fun or fulfilling as you had hoped when you began.  Maybe it is in a job or a career.  Maybe you are trying to learn to play an instrument or you are training for a marathon.  ”The Dip” that Godin is speaking of is this time — the time past the beginning, when things were new and exciting, but before the time when it becomes fun again because you are really good.  In “The Dip” he explains how to tell whether the low point is really a dip or just the beginning of the end.

To me, however, the biggest lesson was this:  If you try hard enough, you can envision what the dip will be like for any new endeavor you think of starting, and you can decide early whether you think you are interested in going through the dip.

I think it is a natural law that anything worth doing or having has a dip associated with it, where the size of the dip is proportional in depth to the value of the thing worth doing or having.  Learning Spanish was like this for me.  At first, it was interesting and novel (“Hey, check me out!  I can say an entire sentence in Spanish!”).  But then there was the long arduous time period where it just was not happening.  I’d hear people speak in Spanish but I couldn’t translate what they were saying fast enough to understand them; I’d try to reply but I couldn’t translate my thoughts to Spanish fast enough to keep their interest.  But I pushed and pushed, and suddenly one day it happened:  I was suddenly thinking in Spanish.  I could understand and speak without any problem.  I was truly bilingual, and it was fun again.

Learning to write computer software was like that.  So was learning to play the piano, and a host of other things.

Since I know that anything worth doing has a dip, and since I also believe that the size of the dip is proportional to the pursuit, I should be able to objectively analyze a new endeavor at the beginning.  I should be able to imagine how it will be to achieve excellence in this endeavor, and I should be able to envision at least some of that which will constitute the dip.  Then I can analyze up front whether I think it is worth the effort.  Then, if I so choose, I can move forward with a bit more awareness and less surprise when the dip hits.

However, there’s another perfectly good alternative:  I might be honest with myself and realize that I’m not willing to see it through.  In this case, I’m better off to focus my energy in other areas where I AM willing to make the investment.

(There is a point to all of this, really.  I’m getting there.)

For a good 15 years of my career, almost since my career began, I’ve thought about starting my own software company.  I’ve had numerous ideas for products that might be monetizable over that timeframe and have conducted various levels of research for many of them.  Eventually, every one of these ideas got shelved or abandoned.  And suddenly, after having first read “The Dip” and then “Linchpin,” with the context of the Money Flow Principle, I knew what I had been doing wrong.

See, all this time one main reason I’ve wanted to have my own company was because I’ve wanted to work on what I wanted the way I want to do it.  So I’ve had all these ideas for possible software companies.  And every time I’ve had an idea, one of the first things I start to think about is, “How can I make a business out of this?  How can this idea make money?”

It is at this point where I start exploring financial models and business plans.  I spend time thinking about how to deliver the product and how much to charge, whether it is a rich client or a web application, whether it is a product or a service, whether it is a subscription model or a license model.  I think about the customer I want to target.  I run the numbers to see if it can make money.

And I either can’t figure out how to make any money, or I simply get bored and quit.

When I read “The Dip” and thought about my career, I had a major epiphany:  I’m not sure I am actually willing to see my business through the dip.  I think I understand a little about what needs to be done.  While I don’t claim that I’ve thought of everything, I think I’ve got a fairly representative picture.  And I’m not convinced that I am interested in seeing it through.

However, I AM still interested in working on what I want to do, the way I want to do it.  But now that I realize that I may not be interested in doing it as a business, I feel relieved.  Suddenly I’m not compelled to monetize whatever I choose to do, because I’m not sure that is really what I want.  I’m free instead to just pursue something interesting and try to give society a valuable gift, and trust that if I do, the money will eventually flow in my direction.

I don’t think I can clearly express how liberating this was to me.  At a time where I was feeling somewhat trapped and beaten down, I realized I could start creating fulfillment for myself, with no obligations other than just those I make to myself, to create something that is enjoyable and satisfying and interesting to me, the way I want to do it.

So I did.  I created an open source software project, called Zoomulus.  I’ve been working on it ever since, and it has been great.  There’s not much there yet, and I’m not even sure yet what it will actually be.  But it is mine, interesting to me, done my way, and it is making a big difference in my life.

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

Yes, you read that correctly.  For far too long all us coding frogs have been neglected and discriminated against.  But no more!  My new software development website, www.codingfrogs.net, is up and running!

I will now take questions.

Q:  What is codingfrogs.net?

A:  It is my new software development blog, dealing with the technical, process, and business aspects of software development.

Q:  Where did you get that outstanding frog picture?

A:  I know, huh!

Q:  No, really – where?

A:  It is the original creation of Rosie Leung, which she made available via Creative Commons on her website.

Q:  Are only coding frogs allowed at that website, or may any type of coding animal visit?

A:  codingfrogs.net welcomes any type of coding animal, but frogs get preferred seating.

Q:  Will you allow other coding frogs to guest-post on codingfrogs.net?

A:  Yes, but only if I let them.

Q:  Isn’t the purpose of this post primarily to drive up your PageRank score for codingfrogs.net, even if only by a tiny amount?

A:  Next question.

Q:  Why codingfrogs.net?

A:  Because the domain name was available, of course.

Q:  Is it true that you created this website to Michelle Barnum would quit complaining about your technical posts?

A:  Pretty much.

The Go Gopher

Earlier this week Google announced their new programming language, called Go.

Usually I don’t get too worked up about programming languages.  I already feel like I know more languages than I should need to know, and often a new language seems to me like “Hey, check this out!  Here’s a more complex or non-intuitive way to accomplish a task you already know how to accomplish, but in a language you will never use professionally!”

I know, I’m disappointing you.

But Go!  Oh my, this seems different.  From the blog post:

Go combines the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. Typical…

Wait!  Hold on there — my heart just skipped a beat and it freaked me out.  Can you please repeat that again?

…a dynamic language like Python with the performance and safety of a compiled language like C or C++.

Ooh baby.  Someone help me — I’m shaking with anticipation.  A systems programming language that combines Python and C++?  Can it really be?  It seems too good to be true!  My two favorite programming languages combined in one:  It’s like true programming nirvana!

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.

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.

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

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.