[embedded]

Wow, armchair engineer, you sound like you really know what you're talking about.

When this old engineer worked on embedded MIPS cores and 802.11[abgn] at Broadcom, everything was under source code control. This was pre-git, so I think we were using cvs. How the hell do you conclude that releasing a zip file means the engineers don't use source code control?

[ozim]

Those kids on HN think that everything cool was invented last summer by some new college grad, funny thing is most of stuff was already invented in 70's but who would care about prehistory of computing.

[pyre]

Yea. I totally remember Web Browsers, Big Data, and Terabyte hard drives back in the 70's. It's too bad that these things were lost to the ages, only to be re-invented in the present.

[nitrogen]

New names for old ideas.

[pyre]

Based on that, SpaceX isn't a big deal, because of the Apollo program, right?

[eliasmacpherson]

Especially because of the Apollo program. SpaceX for all its efficiency, just goes to show how far the present and past few generations have dropped the ball.

[Taniwha]

well as a many time Broadcom customer I've certainly seen the best and the worst of it - I've had large (1000 file) software releases for Broadcom chips that mutated their directory structure release to release, bug fixes would arrive and revert themselves, then after complaints return - integrating a new software drop into our VCS was always fraught and took weeks longer than we expected - people would fight not to be stuck with doing the next Broadcom integration and eventually we'd say "enough! we'll live with it" and refuse to take any new stuff - at one point we got the FE to admit that there was no one master tree inside Broadcom, just personal trees that were passed around - on the other hand other code from them was well maintained and obviously under good source code control.

I think the way to understand Broadcom is to realise that they are really a whole bunch of smaller startup companies, more are continually being bought and brought into the fold, this messes with their internal company culture, chips may have functional units in them that came from 5 different companies, each with their own coding standards, VCSs, documentation standards etc etc - as a result it's pretty hit and miss and may take a generation or two for a new technology to settle down - I kind of get the impression that there's ongoing friction between the remnants of these companies as they find their way in the new organisation

[GFK_of_xmaspast]

The fashion of the day is, for better or worse, "if you don't have a github you ain't shit."

[bdamm]

git is overkill for facilities with small groups working in a common area (not hard to imagine if you're in the hardware biz) and all the engineers are used to cvs command syntax..

[stephen_g]

I'm struggling to think of a situation where Git could be overkill for anything... I've personally used it for hardware and software projects where it was just me, where it was used for small teams (3-5 people), and with hundreds of developers doing on a large code base. It worked well on al of them.

The only thing I would not use version control is if you have files that don't change. Everything else should be in some form of VC (sometimes Git is not the best choice, but it's good for lots of things)

[diydsp]

Semiconductors, especially VLSI, have a different workflow from most software projects. There are supposed to be as few releases as humanly possibly due to the enormous cost of each release. There are not expected to be a community of developer/designers, each with their own vector of revisions available for development and testing. It is prized to arrive at a single image which is reproduced as many times as possible in practice, rather than in variation, as the lithographic process favors identical reproductions.

In my estimate, Broadcom is on the cusp of reaching a sublime point I've seen in other, unnamed semiconductor companies, at which the number of combinations and revisions of IP within a family of chips becomes difficult to account for.

So, it's really not even a question of git being overkill - it's a question of whether its source code will persist over many times the length of the proejct. Git will be considered for substitution by those deeply committed to CVS simply after a matter of time, once its institutional bugs have been discovered and patched.

[jjoonathan]

Overkill until the network goes down or the server dies or somebody needs to work remotely and the VPN isn't working. I don't know how fast git is wrt cvs, but I remember being pleasantly surprised coming from svn.

You don't have to have a distributed workflow to occasionally reap the benefits of working with git.

[GFK_of_xmaspast]

The best VCS is the one you use.

[bigiain]

There _are_ differences, but yeah - you're arguing about the ranking of the 99.91% - 99.95% better solutions compared to no version control. (Seriously - even CVS and SourceSafe are 99.9% closer to "perfect" than doing nothing)

[ardacinar]

unless it's CVS, or god forbid, Visual SourceSafe.

[nitrogen]

On my one man team, the very first command I type on a project after mkdir is git init. Everything is logged and timestamped, and it is far from overkill. Git is easy to learn after working with CVS

[bdamm]

A one man team is very different from a 20-man team (which I still think counts as small).

Hey, I like git too. Respecting the needs of others not to spend mental load on learning something they don't want to is often important too.

Is it really worth it to spend time re-training the 15/20 engineers that don't already know git? I don't think so.

[MPSimmons]

Agreed. I write lots of small apps by myself, and I use version control to save me from, well, myself.

[akiselev]

Let me guess... BCM43xx? If so, what's your email? This armchair engineer has an eratta shit list a mile long for you. You know, yeahs after the first revision.

[embedded]

I hear you. It's so much worse than you can imagine. By the time the code gets out the door, whether through a dump on the net or even worse, through a channel partner and onto a shelf at Fry's, all the engineers are working on new projects. There is sometimes a six-month lag from the time the code is compiled until it shows up on a store. By then the technology has changed no one gives shit about the old stuff. There is no incentive and certainly no corporate push to go fix the bugs that got shipped. I know I always felt like it would be a simple thing to go patch the code, but it was never a priority for the management.

I'll tell you the really screwy thing about BCM43xx development. We sold reference designs to companies like 3Com and Linksys (before and after acquisition by Cisco), Apple, D-Link, etc. All of them got the same reference design, in theory, but if one of those companies reported a bug in our code, that company would be the only one to get the patched code. As a consequence our code was littered with #ifdef (COMS) or #ifdef (LINKSYS) with specific patches enabled. The other companies, those that hadn't yet discovered the bug, would get updates that we knew were broken. It was terrible for the companies, even worse for the customers of those companies.

Plus there were source releases to those companies and they weren't allowed to know about patches that they didn't receive. So we had a step in our build process called the code transmogrifier. That would go through the code and expand certain C preprocessor symbols so the code no longer contained #ifdef (COMS) or #ifdef (LNIKSYS). That way every company got a different source code release as well. We would do separate compiles of the transmogrified code for each customer.

Then we had all the customization because those companies had fired all their own engineers and instead wanted us to produce a product that was branded "Cisco" or "Linksys". We had to take the exact same code an rebrand copyright strings to make it look like it was written by our customers.

I voted with my feet and left the industry.