Last year, I took the initiative to build a new internal developer portal with several other great engineers. We were all very enthusiastic, but there was one fundamental thing missing. Altogether, we had 0 to no experience with TypeScript and MERN stack, on top of which Spotify’s Backstage platform was built. 

All of us were passionate backend engineers with a few years of experience working in the infrastructure department. Our tech stack consisted of more traditional technologies like Java’s Spring and SQL databases. Naturally, the biggest concern was how we would handle technologies we weren’t familiar with and build user-friendly and intuitive interfaces. After all, we were backend developers who preferred writing command-line instructions, deprived of a sense of good user experience. 

 On the other hand, we had an ace up our sleeves – a deep understanding of how our platform works. 

 Contrary to popular belief, we pulled off deploying Backstage in our platform and integrating it with the existing tools without any major challenges. The biggest issue was (and still is) its adoption. 

So, where is the catch?

Backstage has its set of core features, but it is also possible to extend it with your own or 3rd party plugins.  Core features or 3rd party plugins usually work without much hassle – your custom configuration gets injected in premade modules through YAML files.  

You can build interactive forms with multiple steps without writing any React code. This core feature is called Software Templates. We wanted to facilitate the bootstrapping of the Redis cluster. We had the define form which accepts configuration and actions that will be invoked on submission. The form was again defined through YAML. We had to write those simple actions in TypeScript, but after all, which developer doesn’t know how to write a function in any language? 

  When we decided to improve Search, another core feature, the biggest effort was to optimize the PostgreSQL search engine and decide if it was worth going a step further and experimenting with Elasticsearch – in the end, it was.   

While setting up authentication and SSO, the challenge was to explore all existing methods used throughout our company and unify them under one. Again, a task better suited for a platform engineer. 

With custom-made plugins, there was a little bit more React / TypeScript work. You have to figure out React fundamentals and start writing code. Backstage already provides out-of-the-box React components that follow their design principles, so you won’t have to think about colors and paddings. If those components are not enough, you can use MUI components from which the Backstage components are derived. Don’t worry, the internet is brimming with code examples. 

In the end, our knowledge of the platform and underlying infrastructure played a major role in our experience with developer portal integration. Lack of experience with frontend frameworks surely slowed us down a bit, but we learned along the way. 

The struggle

The biggest challenge, however, was yet ahead of us. It was (and still is) transitioning users from the old toolset they’ve been accustomed to. Despite the significant improvements in user experience and the addition of new functionalities, most users remain hesitant. 

To illustrate, we have a 10-year-old application management dashboard that is extensively used, but also notorious for its bad user experience. We modeled the new one after it, with a better user experience in place, but our developers still prefer the old one. When we asked them why they were not switching to the new one, their answer was simply – we don’t trust it. 

We also developed several nice and shiny plugins, a few features based on user requests, and resolved bugs we introduced on the way. Despite these efforts, our Backstage has yet to catch momentum. 

We acquired most users when we organized a two-day hackathon, where each of the 9 teams built a plugin they needed. Only one plugin is extensively used, but it brought around 40 daily active users, which is only 5% of our engineering organization.  

Despite the struggle, I believe that with good marketing, workshops, and constant improvements, we will bring most of the engineers to use and contribute to Backstage. When that happens, I’ll make sure to let you know how we managed to do it. 

The post You don’t need frontend developers for Backstage integration. But you do need adopters. appeared first on ShiftMag.

Have you ever met an engineer who dreamed of becoming a Community Manager? Well, Eleftheria Batsou is one of those unicorns.

Starting in engineering, she quickly expanded into social media and tech conferences, capturing stakeholders’ attention and transitioning into DevRel – from Hashnode to thriving at CrabNebula.

We spoke with her about the crucial role of a Community Manager in the tech landscape.

Every tech company needs a Community Manager

How has the role of a Community Manager evolved in the tech industry over the years?

Eleftheria: Initially, CMs were primarily tasked with fostering engagement and maintaining a positive atmosphere within online communities and forums. However, our role has since expanded and become more strategic. 

As technology and online communication continue to evolve, this role will likely adapt further to meet the changing needs of both the community and the organization they serve.

I honestly believe it’s a critical role that every tech company, independent of its size and power, should have.

In tech, community building is crucial. What strategies have proven effective for fostering engagement and collaboration?

Eleftheria: Certainly, fostering engagement and collaboration is essential for success. Here are some of my favorite strategies:

• Produce Valuable Content – informative articles, tutorials, videos, or webinars tailored to your community’s needs and interests (for instance, I specialize in creating Rust-related content at my current job)
  
• Provide multiple channels for communication (social media platforms, chat groups, and email support)
  
• Cultivate a knowledge-sharing culture where members freely share expertise and insights (for instance, the Tauri Discord server features a dedicated “showcase” room for sharing projects
  
• Host both online and offline gatherings
  
• Collaborate with other tech communities, related projects, or influencers

Community building is an ongoing process

Consistency is also very important?

Eleftheria: Yes, consistency and regular updates! You need to maintain a consistent presence, regularly update content, respond to questions, and keep the conversation going, but don’t be a spammer! Transparency builds trust and keeps members engaged.

Community building is an ongoing process, and staying attuned to the evolving needs and preferences of your members is key to long-term success.

How has your background in tech influenced your approach to CM, and vice versa?

Eleftheria: My engineering background has significantly influenced my approach to community management, especially as it pertains to DevRel. Understanding the technical intricacies of the product or service allows me to engage more effectively with community members, address their technical queries, and provide meaningful support. This background also enables me to bridge the gap between the development team and the community, translating technical information into accessible content.

Conversely, my experience in community management has reinforced the importance of clear communication, empathy, and active listening, which are crucial in both fields.

Be an Engineer first, then move to DevRel

What advice do you have for individuals who are interested in combining roles in community management and engineering?

Eleftheria: For me, it’s crucial to start by understanding the value of both fields. Building a strong technical foundation is essential, and cannot be replaced by anything else. I see CS graduates wanting to be developer advocates, my advice would be to wait a few years, work in engineering jobs, gain some technical experience, and then move to DevRel roles.

Looking ahead, what do you envision for the future of open source and the role that community management and engineering will play in shaping it?

Eleftheria: I’d love to see the open source expanding into an even more collaborative and inclusive ecosystem.

Community management and engineering should have pivotal roles in shaping this landscape. As open source continues to evolve, community management should play a significant role in nurturing and sustaining these communities, ensuring they remain vibrant, inclusive, and supportive spaces for collaboration. 

What is the most exciting tech innovation or trend that you believe will shape the future of the industry?

Eleftheria: One of the most promising tech innovations is the advancement of AI and machine learning. More particularly, and in my field, I’m looking forward to seeing how the AI tools will advance and improve in the areas of content creation (generating ideas, writing articles, auto-cropping/editing images, generating videos, making short audio clips, etc.) and code generation (tools like Copilot, auto bug fixers, etc.).

The post An engineer turned community manager shares her secrets to tech community building appeared first on ShiftMag.

As the tech realm hurtles forward into the unknown, we’ve delved into the experiences of tech professionals to understand the tools that shaped their 2023 tech stacks.

They provide a snapshot of the current landscape, and we also venture into their predictions for the forthcoming year, unraveling the threads of emerging trends that promise to redefine technology in 2024.

Paige Cruz, Senior Developer Advocate (Chronosphere)

“My tech stack majorly changed in 2023 since it was my first full year working in technical marketing (having spent the last six-ish years working as a Site Reliability Engineer).

My current company, Chronosphere, builds on top of open source observability standards and projects, so I’ve gotten to know Prometheus and a bit of PromQL, deepened knowledge of OpenTelemetry including the Collector and instrumenting for metrics, use OTelBin all the time to validate Collector configs, leverage Podman containers for building workshops that work across a variety of attendees’ machines, RevealJS powers all my team’s workshop decks and Mastodon for social media.

In my personal life, I use Ghost for my personal blog, Fathom Analytics for blog statistics, NocoDB to organize my vinyl/fragrance/craft inventories, Llama Life to manage my to-dos, ProtonMail for email, Backblaze for backups, Kavita hosted on PikaPods for eBooks/PDFs, GrandPerspective for analyzing and optimizing where to clean up disk space, swipewipe for managing photo collection on mobile.

In 2024, I think we’ll start to see more companies experiment with the metrics interoperability between Prometheus and OpenTelemetry, whether that’s instrumenting metrics with OTel and sending/storing them in Prometheus or sending Prometheus metrics through an OTel Collector and onto a vendor or self-hosted storage solution. 

Another bet is that FinOps, which emerged as a way for companies to understand, manage, and forecast cloud infrastructure costs, will expand to encompass the costs of observability/monitoring.

With the focus on cost-efficiency for 2023 and heading into 2024, this is one area that organizations cannot continue to ignore. I recommend proactively taking a look at the trends for observability spend, ideally broken out by owning team, service, environment, and cardinality to get a sense of where things stand today.”

Meade Kincke, Founder & CEO of Imperfektus

“My 2023 tech stack included Rust, WebAssembly, Kubernetes, Helm, Docker, K3S, Proxmox HA, Zola, Zero Trust Networking.

As for 2024, I think we are going to see further development in WebAssembly, replacing Javascript/Typescript, more inventive things being done with aviation and electric vehicles, and an emphasis on security – both software and physical.

Just as blockchain has been the trend over the past few years, AI is the current trend that will continue to be pushed into anything and everything. Unfortunately, only about 1% of it will be useful. With that being said, that 1% should be very helpful.”

Meade will also be one of a speakers in our Shift Conference in Miami, Florida (April 23, 2024), so if you’re planning to attend – prepare your questions!

Gift Egwuenu, Developer Advocate (Cloudflare)

“My tech stack in 2023 was mostly focused on modern web development and a bit of exploration with AI. I mostly utilize Nuxt for front-end development, benefiting from its server-side rendering capability.
I use Cloudflare Workers as my go-to choice because it helps me leverage and reduces latency and scalability when building out my applications.

Whenever I needed to store assets, I used Cloudflare R2 for object storage, and Tailwind CSS was my go-to choice for UI design because of its utility-first approach.

Of course, I can’t leave out the rise of generative AI in all of this. So, I also spent some time exploring building AI applications using OpenAI API and Workers AI.

A notable addition to my stack was Astro. I started using Astro for building out my front-end demos, which was very efficient with content loading and component-based architecture. I’m already familiar with Nuxt.js, and was invaluable in helping me ship quickly. 

This combination of tooling allowed me to create fast, scalable, and user-friendly web applications.”

On the other hand, in 2024,  I anticipate a steady rise in the use of generative AI, with more large language models becoming a key part of the already existing ones from last year.

The trend is set to drive broader adoption of generative AI across various industries. And I know many businesses will want to adopt AI into their workflow to help enhance customer experiences and improve operational efficiency.  This advancement will transform industrial operations, providing innovative solutions to traditional challenges.

On the front-end framework side, there will be an increase in the adoption of front-end frameworks that are focused on performance and efficiency. Frameworks like Astro and  SolidJS, known for shipping less JavaScript, to likely become more popular. This shift reflects a growing demand for faster and more efficient web applications.”

The post FinOps, WebAssembly, and AI: What are you adding to your tech stack in 2024? appeared first on ShiftMag.

“The tooling or framework is not going to have the impact on 2024 that I think the stress, pressures, and eventual burnout are going to have on developers in the cloud-native world in 2024”, says Eric D. Schabell, Director of Technical Marketing & Evangelism at Chronosphere, a cloud-native observability tool.

He believes this will lead not only to unhappy developers but also fuel career movements as they seek more satisfying and happy workplaces in 2024.

Eric has also published his predictions for emerging trends in 2024 on his blog, and this is his list of the most important trends for the year.

Prioritizing mental health

In his blog post, Eric highlighted several trends he believes will shape the industry in 2024. One of them is the focus on cloud-native burnout.

Every role, from Site Reliability Engineers (SREs), DevOps, engineers, developers, and managing any part of the cloud-native engineering experience within an organization. They all resonated with this being the number one theme out there.

According to research in a 2023 Cloud Native Observability Report, which Schabel refers to in his blog post, and which surveyed over 500 engineers and developers:

• They spend 10 hours on average – a quarter of their 40-hour work week, trying to triage and understand incidents
• 88% reporting the amount of time spent on issues negatively impacts them and their careers
• 39% admit they are frequently stressed out
• 22% said they want to quit

Because of that, Eric’s prediction is that the attention this topic got in 2023 will expand and deepen into all areas where organizations are trying to grow their cloud-native footprints:

“In 2024 we will hear more about burnout-related stress, hear more ideas on how to solve it, and see it become one of the biggest topics of conversation at events, online, and at the coffee machine”.

High stress = high turnover rate

The stress and burn-out discussed in the first prediction are expected to lead to increased career movement, thinks Schabell. High levels of stress, burnout, and pressures in cloud-native organizations contribute to high turnover rates.

I predict a surge of career movement. Over 25% of current tech roles will take the plunge and try to find fulfillment in now roles, new organizations and take on new opportunities.

Focus on cloud-native cost management

Since its inception in early 2019 and subsequent integration into the Linux Foundation in 2020, the FinOps Foundation has evolved into a crucial entity for both cloud-native and cloud-utilizing organizations. Throughout 2022 and 2023, organizations have increasingly recognized the necessity of deriving value from every dollar spent on cloud-native services.

Along these lines the FinOps Foundation has become the central gathering place for practitioners in the FinOps role across all kinds of organizations. 

His prediction is that the continued growth seen in the field of FinOps in 2023 in cloud-native organizations will evolve in 2024 into a permanent value-add for more and more organizations.

“CIOs, CFOs, and CTOs are going to lean more in 2024 on the FinOps roles, processes, and education to manage their cloud-native spend to ensure the value per dollar spent continues to have impact on their cloud-native investments”, says Schabell.

Read more:
What is developer burnout and how to prevent it
How to implement FinOps

The post 2024 will be the year of cloud-native burnout appeared first on ShiftMag.

As Lin (Senior Director of Developer Relations at Postman) says, this shift, alongside investments in voice and chat interfaces, reflects a dynamic landscape where developers increasingly explore alternatives like GraphQL and gRPC.

Let’s see what will be the hot things among developers in 2024.

Generative AI fuels Low-Code Tool Investments

“The number one trend I think we’ll be seeing is an investment in low-code tools powered by generative AI“, says Lin. She highlighted that Postman specializes in crafting developer tools tailored for API work, so recently, she has seen more teams seeking low-code options.

This is indicative of the rising importance of APIs within businesses, the prioritization of developer experience, and also the expansion of who is working with APIs (it’s more than just developers). 

This demand, she adds, when coupled with the latest availability of generative AI frameworks, is already resulting in tooling companies investing heavily in redesigning software interfaces to interact with voice and chat, a new layer of abstraction designed to increase developer productivity.

Diverse API Evolution

There is, also, diversifying API technologies. “In the Postman State of the API report, we asked 40,000 developers what API technologies they’re using.

REST is still by far the most popular architectural style because it’s so ubiquitous, but has been declining in market share usage, year after year.

This is the case, claims Lin, because more developers are looking to other API technologies to address issues they face with REST; for example, GraphQL and gRPC were designed to avoid over-/under-fetching. Also, developers have more options for real-time communication, such as webhooks and WebSockets. 

To conclude, Joyce Lin emphasized that developers are actively exploring diverse options, leading to the creation of multi-protocol solutions within their organizations. This trend extends across various aspects of the tech stack, encompassing infrastructure, frameworks, tooling, and API technologies.

The post API Predictions 2024: REST is taking a rest, and we’re entering an era of API diversity appeared first on ShiftMag.

* PaaS: Paymaster as a Service

In our increasingly digital world, one revolutionary technology has been silently reshaping how we think about transactions: blockchain. You’ve probably heard of L1 (layer one) blockchains, like Bitcoin and Ethereum, but blockchain technology is much more than that. It’s a new way of storing data and executing transactions – secure, decentralized, and transparent.

However, as with any emerging technology, it has its unique challenges.

Understanding the Challenge: Gas Fees in Simple Terms

Imagine that every time you wanted to send an email, you had to pay a small fee. This fee isn’t in your regular currency but in a special kind of digital token unique to your email provider. Sounds inconvenient, right? That’s kind of what it’s like to perform transactions on blockchain platforms, like Ethereum.

These fees are called “gas fees,” and they’re essential for the operation and security of the blockchain. However, they require users to have a specific digital currency: a native token, like ETH for Ethereum, which can be a significant barrier for many, as is not always convenient or practical.

The Emergence of Paymasters as a Solution

To solve this issue, the blockchain community developed a concept called “Paymasters.” These are smart contracts (special programs) that address the gas fee problem by sponsoring these fees on behalf of users (Sponsored Paymaster) or allowing alternative methods of payment, like using the ERC20 token. (ERC20 Paymaster). This innovation has the potential to significantly enhance user experience and accessibility on blockchain platforms!

However, the creation and implementation of Paymasters, even on advanced networks like zkSynzkc, an L2 scaling protocol, can be complex and time-consuming. Dealing with Paymasters demands lengthy learning processes from developers, project founders, and even average users.

Recognizing this problem, we at txSync, developed a unique solution to simplify the process called txTsuko!

Introducing txTsuko: Paymaster as a Service

Enter txTsuko – new revolutionary product on txSync, that simplifies the entire process of building, deploying, and customizing a paymaster on zkSync with just a few clicks! txTsuko takes the concept of Paymasters to a new level by offering a Paymaster as a Service (PaaS) solution.

By developing txTsuko, we’ve significantly reduced the technical barriers typically associated with Paymaster setup and operation. This is a game-changer, because set-up, which would typically take days for zkSync veterans, or even weeks to months for newcomers, can now be accomplished in minutes with txTsuko.

It marks a significant step towards making blockchain more accessible and efficient.

How does it work?

As mentioned before, setting up a basic Paymaster involves intricate processes, including coding calculations, performing validations, and initializing transactions, all of which are crucial for creating a functional Paymaster.

We turned this complex process into an easy-to-use, intuitive interface. To build a basic Paymaster using txTsuko, follow these simple steps:

1. Go to txTsuko website
2. Connect and verify your wallet (Note: A ‘wallet’ in the blockchain context is a digital tool that allows you to interact with your blockchain account, similar to an online banking app but for cryptocurrencies.)
3. Name your paymaster
4. Choose between Sponsored or ERC20 paymaster types

e.g. If you chose ERC20 type, you need to select your ERC20 token to be used in this paymaster

5. Hit “Create Tsuko”

And that’s it! You now have a paymaster address which is ready to be used by any DApp (A decentralised application) on zkSync.

The Key Features of txTsuko

While developing txTsuko, we focused on incorporating features that would bring significant value to developers and users in the zkSync ecosystem. Two standout features of txTsuko are the Monitoring page and Restrictions.

• Monitoring page: Once your Tsuko (paymaster) is live, we instantly activate transaction monitoring. This means that every transaction that includes your Tsuko address (a unique identifier that functions like an account number) is tracked and displayed on your dashboard in real time. You’ll see total and individual transactions, ETH spent on gas fees, and user counts. This level of monitoring offers a powerful insight into how Tsuko is being used. It’s not just about numbers; it’s about understanding user behaviors, identifying usage patterns, and gaining a deeper understanding of how your Tsuko interacts with its users.
• Restrictions: Restrictions are rules that you specify for your Tsukos. With the help of Restrictions, you can have more control over who can use your Tsuko (your users), as well as which specific smart contracts or even their functions can connect to it. Additionally, you can reuse Restrictions you created in multiple different Tsukos. Basically, they’re an innovative approach to add conditions to special use case paymasters, transforming how transactions are managed in the zkSync ecosystem, making it more efficient and versatile.

In just four days since the launch, over 400 Paymasters have been created using txTsuko. This milestone is not just a number; it’s a clear indicator of the platform’s ease of use and the real need it addresses in the blockchain community!

The future of paymaster creation is here!

txTsuko aims to bring the future of paymaster creation to the present by providing a faster, easier, and more efficient way of building paymasters. The product is designed to bring paymaster usage on zkSync to everyone, and to constantly evolve by offering its users a wide palette of tools to help on this journey!

And this is just the beginning! Behind the scenes, our team is relentlessly pushing the boundaries, constantly innovating to expand txTsuko’s potential and user-friendliness.

To ensure you’re always in the loop with the latest features, updates, and announcements, be sure to follow txSync and txFusion official X (Twitter) accounts.

And if you want to dig deeper and learn even more informations about txTsuko and paymasters, make sure you check out this blog post where we explained everything you need to know.

You can also follow txSync on X (Twitter) here or join its super friendly community on Discord!

The post txTsuko (PaaS): A Game-Changer in the World of Transactions appeared first on ShiftMag.

The ten biggest technology companies employ over 2.6 million people, according to the Fortune Global 500 list. Developer Nation data showed that at least 18% of software developers currently work for companies with 501-5,000 employees, which often falls in the category of Enterprise Developers.

Enterprise developers are responsible for creating and maintaining the software that powers businesses, organizations, and everyday life. Developer Nation interviewed a few enterprise developers from different verticals to learn more about their work priorities.

A third of all enterprise developers work in the US

When it comes to enterprise development, North America and Western Europe reign supreme. The United States alone boasts over 31% of the global enterprise developer workforce, followed closely by Western Europe with over 28.6%. However, Israel, despite its smaller size, punches above its weight with a significant concentration of enterprise developers, accounting for around 9.5% of the global total. 

If we break down the enterprise populations by region, we find that 22% of software developers in South Asia are very large enterprise developers.

These enterprises are likely using their global connections to capitalize on price here: the median per-hour cost for Android development in India, a large hub for app development, is $30. In North America, the rate is five times as high. For example, SAP — the largest non-American software company by revenue — has based its largest R&D lab outside Germany, in India. 

Enterprise developers are mostly backend developers

SaaS (web) development is a particularly popular area for enterprise developers. Over 68% of enterprise developers are involved in SaaS web development. 

Besides web apps, enterprise developers are dominated by their involvement in the backend sector: 64% of enterprise developers are backend developers. Enterprise businesses typically have more sophisticated needs that warrant engaging backend developers. With the myriad of resources at their disposal, enterprises are more easily able to develop large-scale, connected products with complicated backends — IoT devices, for example.

Desktop apps also have a significant presence, with over 41% of enterprise developers working on each. While the involvement drops in the mobile sector compared to the first three. Just under 35% are involved in mobile. The relatively short scope and scale of mobile app development makes small business engagement in this sector achievable.

For enterprise companies, a mobile app, or a web app, is only one small part of a giant machine of software; but for smaller organisations, the mobile or web app might be the entire product. 

 Artificial intelligence is a growing trend, with around 33% of enterprise developers working on AI-related projects. 

Industries: SaaS, fintech, data analytics…

The majority of enterprise developers work in the Software-as-a-Service (SaaS) industry. Financial services and banking have seen a huge increase in the last year or so, with over 21% of enterprise developers working in this vertical.

Data analytics and business intelligence products and services are also major industries for enterprise developers. Almost 20% of enterprise developers work in these sectors. The remaining enterprise developers are spread across a variety of industries, including telecommunications, health, pharma, education, retail, and manufacturing.

The 26th, Global Developer Nation Survey is live, open to all developers. Your insights and experience will shape the developer landscape and help tech companies improve the tools you are using every day.

Take the survey now and leave your footprint in shaping the industry of tomorrow!

The post Enterprise developers: what they do, where, and how appeared first on ShiftMag.

In 2024, we might be heading back into our home offices. Wait, what?!

This unexpected shift is one of the possible tech industry trends predicted for the year, as shared by Michael Coté, Senior Member of Technical Staff at VMware. In this interview, he delves into the complexities and potential universality of Kubernetes, questions the rising prominence of Backstage in DevOps, and navigates the evolving landscapes of Java and remote work.

Let’s delve deeper into these potencial trends.

Will Kubernetes see a rise in popularity?

“Does using Kubernetes actually make application development and delivery better?” asks Michael. For years, he says, we’ve read that Kubernetes is powerful but complex. “We’ve also heard that application developers are not actually supposed to use it directly, let alone build all the app platforms and tools they need to make Kubernetes easy to use.

So, who is Kuberbetes for, and are those people getting value out of it versus just using a standard VMs or more exotic things like serverless? Survey results have been sort of good, people get some benefits. If you look at estimates for how many apps run in containers to get a sense for how much Kuberbetes usage there is, you see something like 15% to 20% globally.

Coté suggests that for Kubernetes to become universal, it must extend its reach to encompass 50%, perhaps even 70%, of workloads. Is this alignment with the community’s aspirations, or is Kubernetes intended to remain deeper in the stack, beyond the reach of application developers? Only time will tell.

Backstage is a rising star in the DevOps world

Michael pointed out that in 2022 and 2023 Backstage became super popular, at least in interest. “I don’t know how widely it’s used now, but it solves a legitimate problem (a framework and community for building a DevOps-oriented intranet for app developers – an internal developer portal to use the clunky word for the category of tools).

How widely will get used? Is it easy to use and does it deliver the benefits, or just result in the same old thing? “Platform engineering” and Backstage have a symbiotic relationship now – though, ironically the progenitor of platforms engineering a concept/category isn’t exactly a Backstage company, I think.

Java landscape is evolving

Another factor shaping the industry is the evolution and migrations within the Java landscape. “Oracle has changed licensing terms for their Java VM, there are older versions of the Spring Framework rolling  out of community support, and large enterprises are forever in the process of migrating and modernizing their apps”, says Coté.

He also pointed out that there’s a strong drive to make changes in the Java system – when it comes to costs, things tend to happen more actively compared to situations where the motivation is abstract, like with “digital transformation”.

Is remote work making a comeback?

Michael also predicts that remote work will have a significant impact – which might come as a surprise to some. “Tech people are in limited supply versus the demand for every organization to use software as its primary way of running the business. This is always a problem.

Over COVID and the last few years, many of these workers have come to cherish working from home – and if the share prices of companies are any indication, working remotely works well. However, many executives seem to be allergic to the concept.

However, Michael thinks it can make cases for both positions; it just depends on how you engineer the company to run. For example, long-time pro-remote work executives like Matt Mullenweg (of Automattic/WordPress) have emphasized that you can build a system of work where remote work is great.

“As executives try to bring people back to the office, workers have a bunch of bluster that they’ll rebel and quit – and some other companies may be happy to hire them and have them work remotely,” he says.

So, will people go back to the office? Could executives alter their perspective? We’ll see how things unfold this year.

The post Kubernetes will rise, and Java will change – what else can we expect in 2024? appeared first on ShiftMag.

Why?

During one quite difficult period in the development of the product my team was working on, some super urgent, should-already-be-done-yesterday, topics were discussed. The neverending list of super-important items was just thrown at the table. Uneasy estimates were given. Nobody wanted to hear the word difficult. And nobody said the word pressure. 

At that time, my brain worked faster, and my mouth had fewer restraints than today.

I stood up against the requirements and said, “All of this can’t be done so it meets the future with open arms. We can do it, but we must make sacrifices.“

My manager, at the time, asked me: “Well, this is quite a generic statement, don’t you think? What’s the real issue?“

The idea of the magic triangle popped up in my mind at that moment.

The Triangle

Definition

The concept behind the triangle is very simple.

When working on any task (unit of work), the task workload is divided into three categories (or vertices – points):

• Scope (increase/decrease) – the amount of work that must be carried out. It can be anything, from brainstorming, spiking, and investigation, all down to development and testing.
  
• Speed (speed-up/slow-down) – the pace at which you perform the given task. The faster you are, you can produce errors. The slower you are, you could end up producing fewer errors.
  
• Quality (increase/decrease) – the overall quality of the task outcome. I personally get lost in the definition of quality, so I’ll be highly subjective: a good and proper analysis followed by an even better, clean task execution. Or it can be said: “done by the book”.
  

By definition, each category requires an investment.

The following two statements have empirically proven to be true (this is a blog post, not a math book ):

• You can’t fully satisfy all vertices. There is no fast solution on a huge scope that can be done with the utmost quality.
• Moreover, you can, at any given time, fully satisfy only two vertices.

Use-cases

Let’s imagine that you want to have something done really, really fast.

• In case you’re going to invest extra effort in quality, then you need to decrease the scope. There is simply not enough time to do a huge scope by the book. Unless you are a superman. Or a cowboy.
  
• In case you’re going to invest extra effort in scope, then you need to decrease the quality. Small time frame and a lot of work to do – let the hacking begin!

Now, let’s switch the formula and say that you want to increase the scope:

• In case you want to deliver a quality solution, this will definitely require more time – you’ll be slower.
  
• In case you want to deliver a fast solution, the quality will suffer.

Technical Epics

I wanted to bring up one special case: we want to do something really slow with the utmost quality in mind. What will happen with the scope? Well, the scope decreases. We are focusing on a small unit of work and we’re doing it really, really well. We’re definitely not gonna wander around the entire system to make a cross-cutting change.

This case is, usually, embodied in technical epics (tech debt).

Why?

Let’s start with one key difference between product and technical epics. Technical epics must be carried out on existing running systems, and must satisfy the “already defined set of system behaviors and rules”.
Product epics are like clay. They can be modeled and spiked until we figure out the proper solution that fits all use cases and satisfies all requirements. And it’s much harder to work on the existing set of rules and boundaries, especially if breaking them could be a big problem.

As such, technical epics require time and precision. With variable, but usually low, and quite narrow scope.

Adding Weights

The weights idea was added later on, in order to give more flexibility to the idea. In nutshell:

• A weight on a scale of 1-50 is associated with each vertex.
• The total weight to distribute among vertices is 100.

With this in mind, an ideal distribution is 33.3 per vertex.

Let the distribution begin…

The post The magic triangle of software development appeared first on ShiftMag.

Scrum makes peace when there is war, bringing together business people and developers. Defined like that, it sounds like a win-win situation.

But then, if one is a Scrum Master, there is a good chance that many people don’t like them and that their role is greatly misunderstood. When you mention Scrum to developers, they won’t hesitate to express negative opinions, criticize, and make fun of it. At best, they will say Scrum Master is a fictional or non-existent role.

To find out if Scrum and Scrum Masters deserved the hate, we talked with Josip Osrečki, a developer turned Scrum Master and a Head of Business Agility at Devōt, a mid-size development agency.

Why people don’t like Scrum?

If we look at the early examples of agile stories before Scrum appeared, people didn’t like project managers either. There has always been this negative attitude towards organizational structures that impose rules, and Scrum is usually imposed on employees. The resistance starts because it comes with new concepts like backlog and sprint, Josip explains:

A big problem lies in the heap of new words that aren’t tailored to programmers. If someone came to me with a completely new framework and started throwing words like refinement and retrospective at me, I’d resist at first.

Another reason people don’t like Scrum is because organizations don’t use it correctly. When it’s not used correctly, it becomes Zombie Scrum. Josip compares it to driving a car:

It’s like driving a car. Someone tells you to go left, and then go right. It would be best if you thought about the goal and how to reach it.

We have a daily, ergo, we do Scrum. It’s like thinking you’re smart just because you have a brain.

Scrum brings people together in one team

Scrum is a perfect tool that enables short feedback loops and product development in small increments so that something can be validated in time, Josip points out:

You create a small part of the application and check if it works. Incremental development is significant in software because of its complexity.

Bringing developers and business people together in one cross-functional team solves the problem of long feedback loops. Also, it eliminates situations such as developers hating the business analysts who wrote 100 pages of documentation or business analysts blaming the developers for taking too long to do the job.

When you make all the teams sit together, then people start talking in a different language, Josip explains:

As a developer, I have learned that there is a customer out there who has requirements, not just my code. The business analyst knows that some technical requirements are not easy to solve, and that’s why I need to go through what they want me to do so that I can see if I can do it at all.

Scrum brings people together in one team and enables short feedback loops. Then we can be much more adaptable in the market.

Scrum Master is not a two-day certificate

Scrum Master role implies that the person should know only Scrum in order to “manage” the team. This often gives them little real mandate to support true organisation change. This is why some people in Agile are already moving away from the term Scrum master and so does he.

He prefers the term organizational or team performance coach because Scrum master sounds like they are the master of the whole team. On the other hand, an organizational coach sounds like someone who wants to enable people to work more comfortably and for the team to improve, Josip points out.

Also, the trivialization of the role has dramatically inflicted a lack of respect for the position. There are examples of people getting a Scrum Master certificate after a two-day course. It’s no wonder that people think that a Scrum Master brings coffee and arranges meetings, Josip explains.

The post Why do developers hate Scrum Masters? appeared first on ShiftMag.