Voice of the DBA

Tag: software development

  • Looking Back at Software Development Trends

    In some ways, the world of software development hasn’t changed much. The same sorts of skills and techniques I saw people using on COBOL programs hitting DB/2 and C++ over Oracle 6 are used today in React and C# against Azure SQL database. On the other hand, it does seem that we are more mature in how we work together and the flexibility with which we design systems.

    I saw the results from a survey from 2019 that Atlassian ran for software developers. This was a look at what modern trends might exist, though over a year later, perhaps the world is dramatically changed again. Let me look at each of the four trends they point out.

    I’ve been hearing about microservices for years, but have found relatively few customers using them. I don’t hear a lot about them in the RDBMS space, and I think this is because the idea of separating out each entity (or small set) in a database and having data access only through a front end component doesn’t make sense. There’s power in using an RDBMS to enforce data integrity rules and allow aggregations. I’ve also seen some companies looking for miniservices, not micro ones.

    Manual testing is still very prevalent for customers. While there are lots of unit tests, including some against a db, they don’t always extend through CI to more complex scenarios. Quite a few customers still have bottlenecks where humans look at the application in a larger sense. I think the high cost of tools that run more complex tests is a part of the problem. I’m not sure how we improve this, though I do hope to see more unit or functional tests for db code.

    Feature flags are extremely complex, though I do see them more as a defensive measure, where features are released, but then turned off if there are issues. This prevents a rollback from the app and db standpoint. I also don’t see a lot of use of dark deploys for database features, perhaps because until the app is working, we aren’t sure the data model is correct. Feature flag cleanup is certainly an issue for some clients.

    The last trend is one I rarely see implemented. Looking at customer outcomes, and not just immediate sales, is something that few people seem to do. Perhaps because developers are evaluated on the work they complete, not whether it’s in use. Managers are evaluated based on getting developers to do work, or on the sales that are produced, but it seems that few organizations try to measure the customer impact. We’ve started doing that at Redgate, and I’m interested to see how this evolves.

    Keeping developers motivated, excited about their jobs, and productive with creative solutions is tough. The trends listed from the article seem to me more aspirational for most of the organizations with which I deal. Most clients I know see developers as interchangeable parts, similar to factory workers. I think if they invested a little more in the well-being of developers, both from their mental focus and the growth of their skills, they might find a lot more benefits accruing from their software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • 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