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/stack/methodology and yet don't yet have a business?
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 were real, measurable benefits would take from a few months to a year, with a lot of unproductive downtime.
The current toolchain is not optimal, but it still sort of works. And in a limited environment like set-top, it will probably continue to work.
Bottom line: don't innovate tools for the sake of it. Innovate if it's going to give you more customers and more profit. But not otherwise.
"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.
It's the only reason I only do web stuff now. I like both domains, but the hardware / embedded software industries are just retarded.
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 different from web development. It might ship on a ROM, for a part with < 64kRAM. In circumstances such as this, knowing your toolchain won't add any complexities you don't understand is very important, and it doesn't get much simpler than C. (Also, most good embedded engineers use a restricted set of C that doesn't include things like printf and malloc.)
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.
This isn't necessarily bad. It does get bad when it's exclusive of anything else. When someone tells me they only ever do something one way, what they're really saying is "We're incapable of introspection. We like our self-imposed status quo, and have no interest in improving ourselves."
Of course the other extreme is just as bad - change for the sake of change is just as destructive.
I've heard people describe themselves that way when they meant "We have no process", "We have a very specific process that we adhere to religiously, that has been billed as agile", and "We have a process that we are constantly trying to improve, through retrospectives and the like to figure out what works and what does not". Only with that latter one has the work seemed to get done on time.
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 the target technology. I guess the point of the rant here is to urge people to get new hammers when their current one is getting old.
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.
And here is how it happened: In my case, I was transfered to a company that worked in cooperation with my initial company, so I didn't really have a choice. One colleague was very talented, but coming from a foreign country he couldn't really judge the company. The second colleague started at the company after graduation but grew out of it by learning and doing side projects after work.
I can understand the authors frustration, but I'd like to know how he got the job. If you knew the culture beforehand and joined with the naïvety that it would change for him, he should really be more modest.
I gradually fell back into development in my new job, did a computer science degree part time. Now I really enjoy programming/ creating.
There were warning signs before I ever accepted that job (which ignored because it was well paid). Now I know that money isn't everything and there's work out there where you simply couldn't pay me enough.
And if a company only uses rakes to dig holes imho you can either try to convince management that using a spade is better or stop complaining or just leave.
