One of the things I'm learning at Sun is how a different culture works and how to spot telltale signs to clue me in. At a high level, I could say that Sun moves slow and NetApp moves fast. But the subtle nuances of how that impacts my day to day work experience is not captured in this 30,000 ft view.

I was at NetApp for 6 years and I've been at Sun for a week. But I've spent the last 3-1/2 years at NetApp comparing the ways the Engineering departments in both companies work. At NetApp, they had to mash cultures from people who liked startups, people who had worked at Sun, SGI, and Tandem. After a while, they also had a fair share of ex-HP developers. And finally, they got a large dose of Spinnaker Networks during that merger.

The common theme was the startup mentality of ditching process when it got in the way of shipping product. NetApp attracted those engineers who wanted to code and didn't want a lot of red-tape in their way when they went to checkin. And with a certain class of customer, or a certain range of products, that cowboy style was okay.

But both NetApp upper management and engineers recognized that wasn't good for all customers and all products. So there had been a push to put process in place to ensure a higher quality product. One of the models discussed was the Sun model.

The NetApp model could be described as everyone checked changes into the main code line and didn't really care if it broke the build. When a release was about to branch from main, things would get stricter. Pushing the changes from main to a shipping release was harder.

The Sun model can be described as don't break main.

At NetApp, it was always fun to watch a ex-Sun engineer do their first checkin and break main. They would sweat and rush to back out their changes. The NetApp approach was to instead fix the change which had been checked into the branch.

As I read the Sun new hire wiki pages and found presentations online, the tone is indeed don't break anything with your changes. Processes, which NetApp have only recently enacted, are spelled out in detail. As an example, at NetApp, the rule was that when you changed source code, you kept the format which was present. It didn't matter if you were a tabber or a spacer, or how you wanted braces to line up. You kept the style of the original author.

At Sun, it is much simpler - you have to run the source cleanly through a style tool, cstyle(1), to ensure a consistent format. I was happy to discover this, I used to have my students do it before they could hand in programming assignments.

This issue doesn't sound that big, but think of the implication of having to code review lines because a developer converted tabs to spaces. You scour the code, trying to decide what the programmer changed - you don't always see the easy answer. As an aside, I used to find bugs in another company by paging down the source code to find where a contractor had made changes. It was easy to find, I kept the code in a consistent style and he was a slob. Once I found his code, I started to fix the formatting issues and invariably would soon spot the bug.

But the gist of this post is why is it easy for Sun to have this process and not NetApp? It again goes to culture differences between the two. At NetApp, some of the early influential developers were ones who left Sun and the processes being developed there. They wanted freedom to code (by the way, NetApp is going through the same growth pangs in deploying process and loosing developers to startups because they want to just code) and productize really cool systems.

And there were many cultural islands, i.e., HP, SGI, Tandem, etc, where things were done just a bit differently. NetApp was a melting pot, where the question asked was always: "So, you are ex-?". But all of these pots had their own champions and each had the perfect way to solve the problem.

Back to the 30,000 ft view, the really exciting thing about coming to Sun for me is the emphasis on already having process to ensure quality - soak your changes for a while in a group development branch, run it on your desktop, etc. What does that allow me to do? It allows me to focus on development and working on cool technology. If you recall, the start-up mentality is to flee process in order to focus on checking in all the code you desired. But eventually, without upfront effort, you will pay the time in the backend fixing bugs.

Both NetApp and Sun deliver really cool technology into your data center - they just go about development differently. Sun is ahead of NetApp as far as process wrapped around delivering quality is concerned. Don't get me wrong, Sun can still have issues and NetApp is diligently working on their process models. I also think that Sun will start to move faster, in large part I see see OpenSolaris spurring that movement. Again, I think Sun can deliver quickly when it wants to and NetApp can sometimes be slow to move itself.

The title of this states I'm proud to be ex-NetApp, by the way, I'm just as proud and excited to be at Sun. I left NetApp to come to Sun for many reasons, but none of them were because I hated NetApp or their products. In large part, I felt Sun offered more risk, and hence more reward. I was also very ecstatic about the chance to work with OpenSolaris.

One reason I did leave NetApp was that I never was an "ex-" systems company. My background had been first in applications in a small shop in Tulsa then later in Stillwater. In between I spent time at grad school (in AI and genetic programming) and as a professor.

But now I can raise my head proudly and state I am "ex-NetApp".

Technorati Tags: Company Culture Culture Sun NetApp Network Appliance