Tag: Software Engineering

With the advent of electric and autonomous vehicles, the amount of software required has grown exponentially. That means newly formed teams must grow overnight, which has two extremes of competing difficulties.

I have watched firsthand as a Napolean-esque CEO fired great talent because the CEO’s hardware background didn’t permit comprehension of building a creative, software team. I’ve seen a frustrated director literally (and dangerously) slam a glass-top, conference table while summarily dismissing managers for being honest about the overwhelming deluge of software defects. I’ve watched dozens of corporations believe a revolving door of low-cost staff augmentation from offshore corners of the world may outperform a more-expensive-per-salary team.

Source: The Complex Creation Of Newly Needed Software Teams In The Auto Industry

Legacy transportation companies making the transition from the ECM-centered software development world to the vehicle-as-a-network-of-computers world should probably rethink their software development methodology, tools, and processes as part of the move. If you adopt a completely-new development platform, but continue to use the legacy process — and the middle management that has been running it — you will transplant 25 years of technical debt into the new paradigm, right at the start. It would seem to be the very definition of the job of “information” and “technology” officers of the company to recognize that their company’s software development systems are 25 years behind the current “meta,” reject the entrenched power structures that have restricted progress for decades, and bring in new people who understand modern software development to setup new teams, tools, and processes.

Well, I guess, that would be the approach if you wanted the company to stay relevant for the foreseeable future. However, if your goals are otherwise, it might not make sense. For instance, if you just wanted to spend the next 10 years collecting stock options to exercise at the opportune time — say, for instance, when you know the company has slid into technical irrelevance to the point of becoming an irresistible target for acquisition by a company which has its software development act together — then your approach to the technical debt problem might be different than mine. It might look a lot like doing nothing at all. Which would hardly be surprising. I mean, look at how much companies in the US are willing to sacrifice long-term success for short-term profits, and how well rewarded such behavior is. You wouldn’t be able to fault people inside the company if they look like they are following the exact same strategy, personally.

Programs can’t work for years without reboots anymore. Sometimes even days are too much to ask. Random stuff happens and nobody knows why.

What’s worse, nobody has time to stop and figure out what happened. Why bother if you can always buy your way out of it. Spin another AWS instance. Restart process. Drop and restore the whole database. Write a watchdog that will restart your broken app every 20 minutes. Include same resources multiple times, zip and ship. Move fast, don’t fix.

That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.

Source: Software disenchantment @ tonsky.me

About 20 years ago, I was working as a Unix sysadmin, and sat in on a meeting about moving an internally-developed application from another data center to mine. It ran on Windows, and died, literally, every day, and required a restart of the whole machine to fix. The manager in the meeting (who, I note, I recommended not be hired, and who was fired for sexual harassment just a few months later) said, “OK, we’ll just schedule it as part of maintenance tasks to preemptively reboot the machine every night.”

I literally snorted. I asked if it were not possible to, you know, actually fix the program? Find the memory leak, or whatever was the problem? I mean, it was written by us; couldn’t we get the programmer to fix their own program? The answer was, of course, no, with the added insinuation that it ridiculous that I suggest that the programmer still had work to do!

About 4 years ago, I wrote a program that helped a lot of people get their jobs done much more easily and efficiently. Per Douglas Adams, “This has made a lot of people very angry and been widely regarded as a bad move.” I was forced to hand the program over to another team, where it has run, with only one tiny patch, for 4 years now. It is not a trivial program, or architecture. To my knowledge, neither the clients nor server ever crash, or need to be restarted. I’m very proud of this.