Voice of the DBA

Tag: software development

  • The Old Way or the New Way

    Many of us are employed because of our talent and experience. We get things done and our organization values what we do. We got this position because we did something well, as a DBA, developer, manager, or some other role.

    It’s natural that we feel confidence in our abilities and knowledge. However, that shouldn’t prevent us from learning new skills, techniques, and patterns for getting work done. As much as many of us want to feel we regularly learn in technology, I often find that customers, clients, and friend struggle to change their habits.

    Why is this? There is a good post on the topic that looks at why people want to use the old way. It’s from the perspective of the developer that shows something to a client, but I think this applies to many parts of our world. Making change has an effort, and the effort needs to have a high enough return to be worth making a change.

    In terms of development, do we change our efforts when something is slightly better? Perhaps, especially if there security or resource changes could be high for our final deployment. What about if the changes are most nebulous, like slightly less technical debt? Or if there is a chance for more future flexibility in the design? The benefits we get back are sometimes hard to measure.

    The changes also need to be considered for a team. A change for my coding habits might be low with little disruption to my workflow, but the change for a team of 10 is a multiple of the effort. We all have to make a change, and that can disrupt an entire sprint, or a series of sprints if our focus and rework increase as everyone tries to adapt.

    My general rule of thumb is that some change has to be at least 20% better in some way. It has to make a fundamental difference to be worth the effort. This is one reason I never moved from Google to Bing. Bing works fine, but it’s not 20% better. I’m not sure it’s 1% better. It’s different, and that has a high cost to me to change.

    Moving to new ways of working can be good, but the movement needs to be careful and slow, especially in a team environment. However, we also need to learn to move more when there are enough benefits. We sometimes forget that last part.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Something Old Something New

    My neighbor had a 1978 Ford Bronco when I was growing up. He drove his kids and I around to various events, and I loved that car. The look, the removable back, the spacious interior. It was a car I’ve always wanted to own. As I’ve gotten older, however, the rough ride and lack of modern amenities have made me rethink buying an older version. I’ve become spoiled in my older age

    Ford just announced a modern version of the Bronco, bringing back the iconic truck after over two decades. What is interesting to me is that they appear to be trying to take a page from software design and customized websites by allowing lots of custom options. It appears in this look at the truck that much of the truck body can be removed and replaced with custom sections. I’m sure plenty of third party companies will offer new colors, shapes, lights, and even accessories that might truly make this car your own.

    Of course, car manufacturers want to make money, too. There are some mechanical differences with engines, transmissions, and suspension, but also a variety of settings for the drivetrain. However, different trim levels have different numbers of drivetrain settings. I wonder if there is a difference in the models or this is a software limitation (with a different physical switch). I wouldn’t be surprised if this were the case.

    I had hoped years ago that we would start seeing more customization in cars with manufacturers building a flat chassis and custom bodies, having features into software, providing interfaces, allowing for more plugins from their own and partner suppliers. Instead, it seems like we’ve gotten more and more proprietary designs, trying to lock in users rather than selling the flexibility of design. I guess that’s the way of capitalism, doing what’s best for the company rather than creating an ecosystem that might excite the consumer.

    While I know modern vehicles are built for efficiency and airflow, I think many of them start to look alike. I would hate to see every car look the same, as they have in some movies. I miss the different designs and details from the past. I would like to think that at some point we’ll see modern electric engines, controls, and features available in customized, 3D printed bodies and better software interfaces that allow us to bring back the look of the past with the best of today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Building Better Software for Everyone

    When I first started to use the Internet, everything was text. We used Archie and Gopher, crawling through Usenet lists, with most everything in text format. When the WWW gained popularity with Netscape and visual browsing, this was just a new way of getting information for me. It made sense, and seemed easy.

    These days, using the WWW is something many of us do without a second thought, browsing on mobile devices as well as large computer screens. Many of us have become used to transacting business and using software as a tool throughout much of our lives. However, that’s not easy for many people, including lots of those with some sort of disability. To them, much of the content available seems disjointed and disconnected.

    Not too long ago the US Supreme Court let a ruling stand that notes the Americans with Disabilities Act applies to online content. Plenty of web developers and designers might decry the additional work they may have to undertake to comply, and certainly lots of companies would rather not spend any resources, or few, in this area. However, this is something that has started to matter more to me over time.

    I’m getting older. At 50+, my eyes and ears don’t work that well. I find myself struggling at times to consume the information on a screen. More than once I’ve gotten annoyed with the text on the screen and tried to zoom in, only to have everything get larger, requiring me to scroll left and right to read something. What happened to the reflow of text on the WWW when we zoom in?

    There are ways to change font sizes, and I find myself taking advantage of them more and more. However, there are many people with disabilities that are harder to overcome and they expect that websites and apps have accessibility features. I’ve seen no shortage of complaints that too many software designers are highly connected, physically capable 20 and 30 year olds, who design for themselves, not for a wider audience with varying needs.

    I am trying to do better. I don’t want perfect to be the enemy of good, and I know that some of the content on SQLServerCentral isn’t as accessible as it could be. When I find things pointed out, I work to change them, and I also am trying to do better with images and media content to be more compliant. As I’ve grown older, I appreciate more and more that my work gets used by many people, and the way they interact with the computer isn’t the same as mine. Accommodating them just seems like the right thing to try to do.

    Steve Jones

  • Rolling Back One Bug for Another

    I was working with a customer recently that develops software for use by their clients. They work in a DevOps style flow, regularly completing work and sending that to their clients. In one case, they released a hot fix quickly to resolve a bug in their software. In this case, the developers received the report, triage’d the bug, and released the fix in less than a week. Their clients were happy with the response and speed at which the fix was delivered.

    Unfortunately, they also released another bug with the fix. The new bug was in an unrelated area of the software, created by separate changes to the code. Now they had a dilemma. The hot fix helped some customers, but the fix also broke some things that other customers cared about.

    What do you do here? If you were in charge of this software team, how do you decide what to do? You can pull the patch, but that means some clients might have broken software. You can leave the patch out there, but then you risk other customers being upset by a new bug.

    There isn’t a good solution here, and the more clients you have, the more likely that you have a large split of customers wanting version 1 versus those wanting version 2. You could rebuild the hotfix to remove the new bug, or you could make another patch that just addresses the second bug. The latter idea is what DevOps would suggest, with a roll forward to a third version of the software. The idea being you keep improving things and fixing bugs as you continue to develop new features. You will release some bugs, but you can fix them quickly.

    The downside of this is that if you release too many bugs, customers are loathe to upgrade. When this happens, you start to find yourself having to support many versions of your software. If you respond to customers with special patches that only fix bugs without adding features, you may end up with many more versions than you can track, which can be a real nightmare for developers to manage.

    How do you deal with patches causing bugs? I recently re-read a piece by Eric Sink in which he recounts releasing three maintenance versions to his customers in a week. Embarrassing for a version control vendor. It’s a good (but long) read, and one that might give you some perspective. We can’t squash every bug, and we can’t test for everything, but we can work to continue to improve, chasing the dream of bug free software. Or at least, regression bug free software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.