When Companies Fail

Posted on October 23, 2024 by way0utwest

I own a Tesla, which is essentially a computer on wheels. Much of the way the car works is driven by software, which I love. New features have appeared and minor fixes come through in the same way that they do for apps on my mobile device. It can be annoying to wait for an update to install, which has happened when my wife or I start the update remotely and don’t realize the other is planning on driving. Fortunately, I can set these to run overnight from my phone and they mostly disappear into the background.

I don’t worry about Tesla failing, at least, that hasn’t been on my mind, but I ran into this article about a company in China that is failing. The WM Motor Company filed for bankruptcy, and perhaps coincidently, their app stopped working. Owners couldn’t manage basic functions. The company put the server back up, but that brings up a bit of a concern for software that depends on external connections.

This raises concerns for Fisker in the US, and really, for any sort of device that one might buy that could depend on an Internet connection for operation. It’s one thing to have updates and options, it’s another for a device to just stop working because the company is gone.

Consumers don’t have a lot of power with regard to software companies, but we do have some. As software becomes more prevalent and important in other parts of our lives, I would advocate for some sort of open-sourcing of software in live devices if companies fail, or even if they decide to discontinue support. I have a 23-year-old car that works fine, and I can get parts. Dealers don’t want to work on it, and it has been a challenge at times to find OEM parts, but there are plenty of third parties.

We ought to have third parties in software as well.

Most of you work for a company, which often makes its own software. If your company abandons a piece of software, everyone adapts and moves on. Even if your company sells a service, it makes sense they could discontinue the service. However, when you sell a physical product or even a physical install of software, I think you ought to give customers a way to maintain their system if you decide to stop doing so.

Update: another issue with Fisker (SMH)

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | 6 Comments

Using SQL Compare in Read-Only Databases

Posted on October 21, 2024 by way0utwest

Recently a customer asked if SQL Compare and SQL Data Compare can be used with a read-only database as a source. It’s a good questions as I’ve seen some tools that create temp tables or do some other work in a source database, which might cause problems. Certainly someone running SQL Compare against production would want to ensure it works as a read-only application.

This post will look at SQL Compare with a database set to read-only. I’ll do a second post on a login that only has read authorization.

This is part of a series of posts on SQL Compare.

Setup

I’ve got a couple of databases that I use for Compare demos. In this case, compare5_prod and compare1. The compare5_prod is set to read only, as you see below.

2024-10_0103

My connection is as a sysadmin, but that doesn’t override a read-only database. As you can see below, Compare works fine:

2024-10_0105

This is because SQL Compare is not writing anything to the database. We read metadata and then process that in-memory on the client before returning the results.

You can see this also works in SQL Data Compare.

2024-10_0106

Summary

This was a very simple example, but I find that clients always would prefer to see examples already completed and proof that something works when they are evaluating software. Hopefully this helps answer this question.

SQL Compare is an amazing tool that millions of users have enjoyed for 25 years. If you’ve never tried it, give it an eval today and see what you think.

Posted in Blog | Tagged , , , | 1 Comment

Tech Debt Perils

Posted on October 21, 2024 by way0utwest

My wife and I have been thinking about some new audio equipment. We’ve been a little unhappy with our Bose soundbar because of the software flakiness and sporadic network connectivity issues. In looking around, I saw a Sonos product, but after reading a bit about the company’s recent history, I decided to look elsewhere.

Sidebar: if any of you have recommendations that aren’t high-end $$$$ audio, let me know.

I saw this article about some of the problems Sonos has had, and it resonated with me. I’ve been in a place where I’ve worked on software that had a lot of technical debt and needed to be changed/improved to help grow the company. Management was pressing everyone to get the software ready quickly, without more concerns about the customer experience or the quality.

That seems to be what happened with Sonos, where they released new products and new software, with the software missing functionality that their customers needed. There were bug reports, bad press, lower sales, and canceled raises/bonuses. Those last ones, to me, ought to be completely focused on executives and managers, but I’m sure that’s not the case. Management rarely takes the blame, but ultimately they are responsible for hiring, training, steering the employees, and deciding to launch.

The story reads like a summary of The Phoenix Project. Technical debt, poor project management, and pressure to increase sales combine to create a disastrous launch. It’s always hard to know where to assign blame, but clearly, good software engineering wasn’t a priority, nor was reducing technical debt. I know it can be hard to balance the need to alter software with the need to keep it maintainable, but in this case, they made poor decisions.

The article says there were yelling and screaming in meetings, and concerns from developers about pushing back on senior leadership on the timelines and demands. Some of us might have been in those situations, and my experience has been if there is management that doesn’t value software engineering, any particular developer is vulnerable to a layoff or termination if they complain. If management doesn’t value software, they don’t value developers and think they can be easily replaced. I’ve seen quite a few companies start to fall quickly with this attitude when developers are not valued. I also see constant job openings and employees constantly looking for other opportunities at these organizations. People only stay long enough to find another job.

Software is complex. It’s going to have some bugs. There are always tough decisions about which things to work on now and which to delay. I hear those conversations, and I find myself trying to balance the needs of sales and engineering. We need both, and we also need to ensure we can change directions in the future. Paying down technical debt should be a regular occurrence to ensure the software is maintainable and adaptable. I know that when we look to quickly take advantage of new opportunities, this can mean we’re adding new technical debt. Walking that line is the key to success.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged | 4 Comments

Denver Dev Day Oct 2024 Slides

Posted on October 18, 2024 by way0utwest

Here are the slides from my talk today: CI in Azure DevOps

If you have questions, please feel free to contact me (top menu above).

Posted in Blog | Tagged , , , | Comments Off on Denver Dev Day Oct 2024 Slides