Earlier this year, Andrzej Frydryszak, .NET Developer at ITMAGINATION attended a few conferences on software development. The list we compiled is a list of the most significant points the attendees of the conferences have heard from some of the top engineering leaders in the US & Europe. Here goes:
You are working on your software, and you are ready to deploy it. All tests pass, and test coverage is on a decent level. Knowing this, we may deploy our code, and continue to work on it in peace. As much as this is not the optimal scenario (and as rare as it is) our code may still fail. Yes! Therefore developers need to always observe their code, and have it report metrics all the time. In case anything fails, you need to have your systems ready to deliver your logs to you. As Andrzej writes:
Observability is crucial. Without it, developers are blind. It gives us an opportunity to react to every problem occurring in the system at any time.
Serverless is a way of running apps (seemingly) without any servers involved. Of course, it is a major simplification – there are always servers involved; only in this case you do not do anything with them, and they come preconfigured. It’s touted as the new black, except… It’s not a perfect remedy to all ailments. For starters, you cannot configure the underlying server, as we mentioned before. You don’t really know what’s under the hood, either. The main drawback is the approach’s major benefit at the same time. You don’t have to configure anything, so instead of deploy ⇾ worry, it’s more of a deployment ⇾ forget.
There are benefits of either serverless or serverful solutions. In the modern systems, it is common to join two approaches to gain most of the solution.
Not all software development trends are good ideas. Do you remember CoffeeScript or Ruby? Sadly, we do. Luckily, Kubernetes (K8S) don’t seem as if it’s are going to join the two in the valley of sorrow. K8S are making DevOps specialists lives’ much, much, easier.
Here are the benefits you can expect by introducing containerization and container orchestration as a core tenant of your technology strategy:
Beyond the obvious benefits, we’ll leave you with some case studies that we hope will inspire you and help you decide if using Kubernetes is right for you, as well as show more in-depth benefits:
Other intesresting case studies worth checking out:
Have any questions about how to optimize your K8s deployments or whether it’s the right choice for you at your current scale? Make sure to reach out to us to talk to Maciej Gos, our DevOps competency leader.
Monoliths of large sizes are somewhat of a yesterday’s tale. They haunted developers for long, though not anymore. Splitting huge unitary codebases into smaller scale apps is the new way of doing things. It fireproofs your applications, reducing the frequency of errors, and making apps safer in case something wrong happens. The downside is, apps become harder to test, and it takes more resources to do so. For teams of a smaller size, it still makes more sense to maintain a monolith.
Divide a monolithic application into independent microservices.
React, Angular, and Zuul, from Meta (which used to be Facebook), Google, and Netflix, respectively, are tools countless developers use in their jobs every day. Without the tools these organizations released at no cost to all those willing to use them, everybody’s job would have been much more difficult. Countless services would not have seen the light of day, as it would have been too hard or too time-consuming to write these apps. All because, before writing them, one would have to figure out how to e.g., write front-ends for scale, on their own, without sharing the lessons learned would be extremely inefficient.
This is why we have to praise open-source & free software maintainers, creators, and all others contributing to the creation and maintenance of such software.
Creation of a tool/technology and making it open-source (or making it free) gives the organization eternal glory.
There is a common rule in software development – don’t reinvent the wheel. Knowing that we likely have faced the same problem as somebody else before, the rule becomes all the more valuable. This is why engineers and developers from around the world use Architectural Patterns to structure their projects – not to waste time on thinking about how to figure out solutions others already came up with.
Much of modern pieces of software use patterns like CQRS and Event Sourcing. Don’t reinvent the wheel, use the patterns.
The fact that we have newer and newer programming languages isn’t a surprise. They all come and go, and leave to be replaced by others. Nobody codes in Algol or Pascal anymore. One old-timer, C, is still around, however, though that’s a topic worth exploring on its own.
One noteworthy aspect is the way in which they all evolved during the years. At first, imperative languages were the only ones around. Then the boom for Object-Oriented languages came, and now, some might argue, that they are being pushed out by languages such that are much more flexible, mixing some imperative, functional, and object-oriented features.
The way languages evolve is getting more and more independent of the systems we work on, and with. Modern languages are cross-platform. Thanks to the growth of DevOps, the language selection becomes less and less important.
The classic infrastructure on a physical server in the basement is displaced by cloud providers and related technologies. We have VMs as a service, data bases as a service and many other infra elements as a service. Major of planning in a software solution has moved to the high level design of an infrastructure since much can be automated based on it. Additionally, we have containers and container orchestration. It takes over the complexity, since we can divide the system into smaller and simpler parts.
Application code gets more independent of the platform. The complexity, however, lies in the infrastructure and operations. Application developers focus increasingly on business logic. DevOps engineers handle the rest.
Adopting specific processes usually leads to learned behaviors, which ultimately lead to habits. At least, that’s the theory of it.
In some cases however, processes stay processes that people trudge through just to go through the motions, but the behaviors never develop. Think of it this way, how many development teams have you seen go through all the Scrum rituals but not actually working in an agile way? Too many? We agree.
So what can you do? First of all, team buy-in, this is always the first step that needs to be established. If your team does not see the value in working using this methodology, then all the processes and rituals will not move the needle much in the long term.
The second step is to make sure you have a great scrum master and project manager to ensure good practices are being passed onward and that any objections are being
The third step is to realize: forcing Agile values & the Scrum framework down people’s throats when it doesn’t hold any merit will get you nowhere, fast. We’ve covered this point and many more in detail in our post titled ”Scrum isn’t the answer for every IT project (itmagination.com)”.
SCRUM can be agile, but it does not guarantee agility. Agility comes from behaviors, not only processes.
As we wrote many times before, security cannot be an afterthought. We cannot simply “leave it for later.” Checking apps for security issues has to be integrated into the DevOps process, and into the development process itself from day one. Luckily, there are few tools we may use to make the process frictionless. One of them is Snyk. It’s a comprehensive tool to “[f]ind and automatically fix vulnerabilities in your code, open-source dependencies, containers, and infrastructure as code[…].”
We must apply security checking procedures in the development cycle. Security is a base of trust – the currency of the future.
As the three main cloud providers enjoy virtually no competition, and differences in services they provide are (more or less) arbitrary. The only difference that we may see, realistically, is the difference in the price of services. This is why, being biased about this one particular provider is not necessarily bad. There really is, mostly, little to no difference.
Choose whichever provider you are comfortable with, and already know. Assess as you go, and don’t be afraid of change.
Cloud providers have no virtual competition and no cost arbitrage. Cloud infrastructure costs are very dependent on inflation and recession.
Platform as a Service, Infrastructure as a Service, Database as a Service, Software as a Service, Backend as a Service… We spared you more examples, and you should get our point across. Everything you can think of can be done by a third-party and sold to you.
Using these services is a trade-off. You give up some control to become leaner, and to be able to iterate faster, as well as to save some money upfront.
Due to the growth of the importance of cloud providers and serverless approach, every piece of software can be done as a Service.
Visual Studio Code took the world by storm. The combination of having the backing of Microsoft, having an Open-Source license, being written in TypeScript, and allowing for an easy extension of functionality were great decisions. The text editor is, by far, the most popular choice among modern programmers. Other choices, such as Intellij-based Integrated Development Editors (IDEs) or Vim, are in Code’s shadow, though JetBrains’ Fleets might change that.
Thanks to the multiple extensions and customization tools, VS Code becomes the most popular IDE among developers.
TensorFlow, Google’s framework for Machine Learning is an incredibly popular choice among programmers. For one, it is in GitHub’s top 20 for the most starred repositories. Then, there are multiple ports, including the JavaScript one, which teams use in their e.g., React Native apps, or web apps in React or any other JS framework. This provides enormous flexibility, and allows teams to embed the solution in many solutions.
Thanks to TensorFlow we can implement AI solutions in web applications. The models for training are provided by the library. Developers should focus on training them.
Hiring juniors is a good long-term strategy. While there is no “best strategy” that’s a fit for all companies, hiring juniors and training them is definitely one of the best ways to grow and retain in-house talent.
Hiring juniors is a great way to scale up your team slowly over time, and building an internal culture that is easier to mould when compared to hiring people who are possibly set in their ways. Juniors also give a fresh perspective and are more in touch with current trends.
There are a few cases where this isn’t ideal, for example when you your company needs to scale and develop new features very quickly. It’s also not the best if you have a small in-house team who are always trying to catch up with their backlog due to unrealistic development expectations. In that case, hiring an external technology partner to help with development while scaling up the in-house team in tandem could be a great middle-ground solution.
Hiring juniors to train them as a strategy doesn’t come without pitfalls. Juniors who are on your team are not vetted by previous companies, they don’t have a work history, and it may very well be a hit or a miss. The unfortunate reality is that while this strategy can be great with appropriate compensation packages, junior employees may find themselves in positions where they can double, triple, or even quadruple their salary by simply moving companies, rather than waiting or pushing for a promotion or raise.
This is why it’s so important to have transparent salaries and pay scales to show people where and how they can advance in their career path. This is why it’s also very important to have great onboarding programs to make sure that the time spent on training the juniors is well-spent and benefits both the mentors and mentees.
According to numerous studies, a great long-term hiring practice for software developers is to hire non-experienced engineers and train them into the ways of the organization.
That's it. Fifteen of the most impactful trends in 2023. Which one is the most impactful in your regard? Did wemiss any? Let us know!
.svg){kind=small}
