When I wake up in the morning and look at my phone or log onto my computer to deal with the myriad of things I do, I am dealing with software that has been created to serve those purposes. The software that I use to check email, utilize social media, open a weather app, read the news, write an article, or work on writing and recording music is primarily done on commercial, general-use applications. Whether this be done via mobile apps on my phone, desktop apps on a computer, or web apps in a browser, this is what most everyday people work with and deal with.
By contrast, Custom Software Development is done when there is a need or a place where what is available “off the shelf” will not fit my needs. This is more common inside of organizations: The customers are not a distant set of people looking to buy a software product that we create; instead, they are our co-workers, trying to accomplish the tasks they need to do each day. Or, we might notice that there is a need in the market for an existing product to do something differently, or to act or perform in a way that the core product cannot do.
At present, I work in a group where that is our specialty. We create custom software for organizations to take data and transform it to be used by other applications. Put simply, this is not something any off-the-shelf product can do for us or for our customers. We have to “reinvent the wheel” frequently. It’s a fun challenge but make no mistake, it has its challenges.
How Digital Transformation Impacts Software Development
Digital Transformations (DX) are typically big drivers of change and determining future direction in companies. They often modify or disrupt every part of an organization––and that is by design. Changes may be moving from on-premises infrastructure to fully in the cloud. They may be focused on taking advantage of online capabilities in ways your business never has before. Additionally, earning and revenue streams may be optimized and improved.
Make no mistake, everyone involved will feel the impact of these changes. They also come with significant software retooling and platform availability for applications being used. We often think about how these changes will have an effect on end users. Just as important is a question less frequently asked: How will this affect software organizations whose responsibility is software development in the first place?
As I have had the opportunity to work in environments that have emphasized the role of Continuous Integration and Continuous Delivery (and with it, the goal of achieving Continuous Testing as well), I have also had the chance to see our Operations Team focus more attention on the goals of DevOps and the methodology that lets us steer towards that goal. In many ways, we are actively working towards getting to that effective DevOps goal and each day gets us closer.
In CI/CD environments, automated tests are the linchpin of a successful build and deployment. When tests go bad, they cause failed builds, necessary research, and examination. And, of course, if there is a real error, the need to be fixed and rerun. However, what often happens is that a test changes slightly or the underlying environment changes in a way that may cause a test to fail at certain times but not others. These situations are frustrating and I often mutter to myself, “Can’t the test figure these things out on their own?” Today, the answer is “Yes, they can!” Or, at least they can to a point.