21–30 of 31 posts
All hardware companies I've seen on the inside are like this. Philips, FEI, Cisco, ASML, Océ. Somehow, when software isn't the only part that matters, people stick their heads in the sand and pretend like the 1980's never ended. I've given up trying to figure out why or change it. It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.
All hardware companies I've seen on the inside are like this. Philips, FEI, Cisco, ASML, Océ. Somehow, when software isn't the only part that matters, people stick their heads in the sand and pretend like the 1980's never ended. I've given up trying to figure out why or change it. It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.
Longtime embedded engineer here: There is a reason they are "retarded" (BTW, please don't use that word). It comes down to the following: 1) Embedded engineers are generally EE that have taken a course or two in software. Generally they are the "best software guys" from a group of middling to poor software guys. As such, they reach for tools they are familiar with. 2) The product from embedded engineering is much dif…
If a team with extensive experience in CVS is already dragging it's feets to move to SVN, trying to get it to git is a fool's errand. And SVN isn't the plague either, if they could be happy with, it should be good enough for a number of years. At least the migration path from CVS seems a lot more realistic. Moving legacy systems is always a pain, and more often than not it's a matter of having enough people fluent in…
Earlier quoted context omitted.
Interesting way to look at it. You could look at it another way and say what whatever they were doing before worked and got them this far. However, will what they are doing work for their continued future?
It might. It might not. What would the technical and cultural cost of moving to a different toolchain be? The author seems to think that obviously moving to modern tools would be better. Would it? Or would it just add to the chaos? Would build times really improve, would debugging become easier and more streamlined, would issue tracking improve? My guess is that changing the entire culture to the point where there we…
All hardware companies I've seen on the inside are like this. Philips, FEI, Cisco, ASML, Océ. Somehow, when software isn't the only part that matters, people stick their heads in the sand and pretend like the 1980's never ended. I've given up trying to figure out why or change it. It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.
Longtime embedded engineer here: There is a reason they are "retarded" (BTW, please don't use that word). It comes down to the following: 1) Embedded engineers are generally EE that have taken a course or two in software. Generally they are the "best software guys" from a group of middling to poor software guys. As such, they reach for tools they are familiar with. 2) The product from embedded engineering is much dif…
Please don't use p*or, it's one of my triggers
> toolchain
HN is not the place for penis jokes, either
> A big (2B+ $) company. The division in the middle of UK. They make Set Top Boxes - they are somehow good at that. So, despite what the author thinks about their methods and their technology choices and despite anecdotal intermediate performance indicators ("Solving bug takes ages") whatever they are doing is working. How many start-ups do we read about on HN that are using the latest and greatest language/framework…
"Instead of solving the situation, they add more and more advanced tools on top of existing software development chain..."
I'm wondering if those layers of more advanced tools could be re-written piecemeal so that they pointed to a more rational underlying system? Sort of jacking the house up to work on the foundations?
PS: Saltaire (I'm guessing) is a lovely town and the 1853 Gallery at Salts Mill is a must if you are in the neighbourhood.
> A big (2B+ $) company. The division in the middle of UK. They make Set Top Boxes - they are somehow good at that. So, despite what the author thinks about their methods and their technology choices and despite anecdotal intermediate performance indicators ("Solving bug takes ages") whatever they are doing is working. How many start-ups do we read about on HN that are using the latest and greatest language/framework…
Quote from OA "Instead of solving the situation, they add more and more advanced tools on top of existing software development chain..." I'm wondering if those layers of more advanced tools could be re-written piecemeal so that they pointed to a more rational underlying system? Sort of jacking the house up to work on the foundations? PS: Saltaire (I'm guessing) is a lovely town and the 1853 Gallery at Salts Mill is a…
Earlier quoted context omitted.
Longtime embedded engineer here: There is a reason they are "retarded" (BTW, please don't use that word). It comes down to the following: 1) Embedded engineers are generally EE that have taken a course or two in software. Generally they are the "best software guys" from a group of middling to poor software guys. As such, they reach for tools they are familiar with. 2) The product from embedded engineering is much dif…
> poor software guys Please don't use p*or, it's one of my triggers > toolchain HN is not the place for penis jokes, either
Basically it is "compiler and friends". For example: http://en.m.wikipedia.org/wiki/GNU_toolchain
All hardware companies I've seen on the inside are like this. Philips, FEI, Cisco, ASML, Océ. Somehow, when software isn't the only part that matters, people stick their heads in the sand and pretend like the 1980's never ended. I've given up trying to figure out why or change it. It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.
Longtime embedded engineer here: There is a reason they are "retarded" (BTW, please don't use that word). It comes down to the following: 1) Embedded engineers are generally EE that have taken a course or two in software. Generally they are the "best software guys" from a group of middling to poor software guys. As such, they reach for tools they are familiar with. 2) The product from embedded engineering is much dif…
Good point. I won't anymore.
Your experience matches with mine (especially point 1). It's a sad state of affairs, really.
Wrt point two, true, but these days there's a vanishingly small number of problems that can only be solved cost-efficiently on microcontrollers and C.
My favourite example is ASML, world market leader in chip machines, which sell at millions of dollars a piece and could be specced to have any computing power needed, effectively, and has a software stack of 30 million lines of C.
Running on microcontrollers and Sun Solaris computers.
If a team with extensive experience in CVS is already dragging it's feets to move to SVN, trying to get it to git is a fool's errand. And SVN isn't the plague either, if they could be happy with, it should be good enough for a number of years. At least the migration path from CVS seems a lot more realistic. Moving legacy systems is always a pain, and more often than not it's a matter of having enough people fluent in…
10 years ago I managed to convince my employer at a time to move to Subversion from some proprietary system. Labelling a version of their customer facing application took all day as it copied every single file. We moved the code into Subversion as a test and showed we could label it in 1 second. Sometimes you have to show people to get them to understand.
I remember the tedious part being actually moving all the projects, all the teams over. Change the procedures. Change the tools, be it on the dev machines, CI, managers etc.
Then you remake all the weird scripts that were used to take stats, the commit hooks, or the stuff people didn't even remember existed but is still critical 0.01% of the time.
Usually it won't be done in one scoop, more like building the basic viable architecture and moving one project after the other, keep both stuff working in parallel with some people who'll trail behind and keep some translation layer between the legacy and the new system until everyone around has moved and they feel the peer pressure.
I've seen a lot of these transitions in mid size (70~200 people) corps, it would easily take 2 to 6 months to complete, even with goodwill on most fronts. Not the best memories.