|
| Featured Contents |
| Question of the Day |
| The Voice of the DBA |
Designing for Teams Some years ago, I had to register for my medical benefits with Redgate. My employer had contracted with Anthem for health insurance, and I went to register myself. I found that not only could I not register myself, but there was already an account there with my tax number, and it was under my wife's account. Many years ago, she had health insurance with Anthem through another employer. Anthem kept her record, which includes my tax ID. So today, in 2026, I have to log into my Anthem account with her ID to see my plan. That's likely an older, legacy system, so we might understand that they didn't expect two people to be primary account holders over time, right? Well, we also have a more modern tax software system to deal with. Let's call the software "Chewit" to protect the reputation of the company. When we contracted with an accountant for services, they set up an account for me. However, my wife manages most of the money, so I asked them to add an account for her. Apparently, this "Chewit" business tax service only allows for one person in a household to have an account. This person has to manage the account, so now when my wife logs in with my account, I get a code, and I send it to her. If you think these are isolated, I have 3 or 4 other services that work like this, from well-known, global brands. The quality of data modeling and software development is depressing some days. A lot of what I see from customers at Redgate, often from people who want to use Flyway to smooth our their database change management, is that they have built similar solutions that often depend on A person (or A server or AN account) to work. Someone hasn't modeled things well for teams. Even when we try to smooth out a flow, often I see the users don't account for the complexities of teams working together. I think some of this is because a demo or a model often shows a happy path, and we all tend to think in that mindset of a simple flow. Managing parallel actions is hard, just like parallel programming is a thing many people struggle to do well. Well, they struggle to make the code work without race conditions. I see the same thing in T-SQL. So many people think in terms of singletons, working with a row of data. They don't think in sets, or as Jeff Moden put it recently, about how to work with the entire column at once. Thinking that way is harder and requires a new mindset, but that's why we get paid well. Or should be paid well. We solve the hard problems. The world is more connected, more complex, and more likely to require teamwork. Whether that's between partners/spouses in a household or different groups of people in an organization. We should be designing and modeling for teams, not individuals, in everything from data storage and security to user settings and customizations. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
| Featured Contents |
