We recently started two rescue projects. Though both were different, they suffered from the same fundamental problem – neither were standardized or current on their tech stacks or development processes. It might have been a minor inefficiency here or an unusual approach there. Cumulatively, these issues were negatively affecting their ability to maintain and improve their product.
For instance, one of them did not have any scripts or automation around deployment. Their process was to ssh into the server and manually run a series of commands to perform the deploy. Back in 2005, that wasn’t unusual. By 2010, I would consider it standard for projects to have some sort of deployment automation. In the Ruby on Rails ecosystem, that would have been Capistrano. This might seem like a minor issue but in this particular example it would take little effort to set up and would allow quick and reliable deployment with one simple command. Considering this is something that happens multiple times per week, it would add up to significant time savings over the course of a project’s lifespan.
Standardized and current
What do I mean by standardized and current in regards to tech stacks and development processes? Standardized refers to following what is considered typical and expected for how this type of application is built. For Ruby on Rails projects, that would be following the Rails way. Experienced Rails developers would be able to come into the project and know what to expect. Rails, in particular, uses convention over configuration among other things so you experience benefits when you follow this practice and encounter resistance when you don’t.
Current refers to parts of the technology stack or practices that are preferred solutions by the industry today. An excellent example would be the use of JavaScript. In 2006, the modern use of JS would have been Ajax, likely through Prototype. In 2010, JQuery would have been the preferred approach. In 2018, you likely would have seen a component-based approach such as React. If you encountered a project in 2018 that was using Prototype, you would say that project did not stay current on its use of JS.
The same thing can be said for software development processes. These are all the practices and conventions that software teams follow in the lifecycle of building and supporting application development. Some examples are automated testing, deployment scripts, continuous integration, and code reviews through a pull request. If you’re used to working on an Agile or XP team, you have expectations about what that would include. If you then joined a team that had no standard on these practices and let each developer choose their own way, you’d have a big mess. What was considered best practice in 2006 may no longer be the case in 2018.
In the world of software consulting, we are constantly working with the latest standardized tech stacks and evolving our development practices to match modern ways. You may encounter a new approach or technology in your new project. One example could be using GraphQL vs JSON API. You would experience the pros and cons of this new approach to providing data. When you start your next new project, you would have the opportunity to pick what’s going to work best, whether that’s going with GraphQL or not.
For existing projects, this is not often the case. It’s not easy to swap out some part of your tech stack or development process so many end up sticking with the stack they started with. When starting on a legacy project, we joke that we can tell when it was started based on the stack and its supporting practices.
Worth it?
You might wonder if keeping your tech stack and software processes standardized and current is worth the effort. Over the course of my career, I’ve seen the benefits to following this path as well as the drawbacks for those projects that didn’t. Though it does take time and effort, there’s no doubt in my mind that keeping your stack current is important.
We’ll start with the basics, your tech stack and all its components will have new versions released, some of which may trigger an architectural shift in how your application is put together. These changes are done to improve security, stability, ease of development as well as bring new capabilities to your tech stack. To ignore these upgrades or to not consider the shift in how applications are built will leave your application frozen in time. This could result in security vulnerabilities not being patched or the inability to take advantage of performance improvements.
You may find that some external service your application relies on will force you to use some new standard to connect to its API and you will be unable to do so since your application hasn’t stayed current. Imagine if you could only work with SOAP or CORBA, what would you do if some important service only provided REST or GraphQL endpoints?
What about development practices? Let’s focus on our deployment example from above. By not automating that process, you’re leaving it to a person to manually go through all the steps that a computer (via script) can do on its own. On its face, it’s about efficiency, which could add up to hours each week saved when embraced. It’s also about consistency and reliability. What happens if that individual misses a step or makes a mistake? This mindset of doing things manually extends into how the server was configured and has to be maintained. One of the huge changes in the last decade was the rise of the cloud and the ability to completely automate your infrastructure. There are many advantages to treating your application’s infrastructure this way but a project that is manually deploying their code is far from able to take advantage of it.
There are two major benefits that keeping standardized and current yields. First, it accelerates shipping of new features. From reducing manual steps with the process of automation to simplifying the development process, developers can spend more time on building features that add value. Second, it eases the process of bringing on new teammates. They’ll already be familiar with many of these technologies and processes so they’ll fit right in. If they have to go learn your homebrewed solution to something that was better implemented by a standard open source library, they’re going to need more time to onboard.
Why aren’t all teams doing this?
There are many reasons why this isn’t the case for software teams everywhere. Over the last two decades many businesses started developing their own software. Some of these businesses hired less experienced developers who aren’t staying current on technology.
Many developers don’t know what is standard or current. It could be that they don’t follow the latest trends or don’t make time to evaluate them. They may not feel comfortable trying them out or don’t see enough value in changing what has worked in the past.
I certainly understand existing applications not jumping on some new trend or change in technology usage. Some of the trends may seem like fads or may not serve their business case at all.
I think it’s important to separate the hottest trends that fall into the fad category versus tried and true shifts in how we build software that provide true wins. If you look at the history of software development there was a time when automated testing or version control was not standard or commonplace.
Keeping current
I will mention two approaches I use to stay current. First, I read a steady stream of tech posts and articles. Generally, I get them from email newsletters, twitter, and tech news sources. Across all these sources I’ve set my funnel wide enough that I’m aware of what’s happening in the tech industry. Honestly, there’s so much that many weeks I don’t have enough time set aside to read everything but at least I’m skimming headlines.
Second, I network and talk to my industry peers about what they’re using and their experiences with it. Local meetups are a great place to start. I also attend conferences, such as RailsConf and RubyConf in the Ruby space, that allow me to interact with folks from all over the world. Back in 2005, I attended a No Fluff Just Stuff conference that expanded my horizons in exactly this way.
The primary point is to set the intention to stay current. Make it part of your routine, whether that’s reading up on things weekly or digging into some new technology on a quarterly basis. Our industry moves so fast that if you don’t make this investment in your professional skill set then you will find yourself disconnected from what your industry peers are doing and unable to provide informed advice about the best way to build modern software systems.
A word of caution
There is a caveat. By staying current, I do not mean always jumping on the newest thing and implementing it into your production system. ThoughtWorks has had their technology radar for years that gives advice on which new technologies, methodologies, and practices are ready, in their opinion, for adoption. Staying current is more about knowing what’s out there and being able to evaluate if you should bring that into your project. This also seems the appropriate time to plug a friend of mine’s post on when to say no to a new technology.
- Share:
