<strong>Thoughtworks</strong> Holding Inc (TWKS) stock is down -66.75% over the last 12 months, and the average rating from Wall Street analysts is a Buy. InvestorsObserver’s proprietary ranking syst

Thoughtworks Holding Inc (TWKS) Stock Has Fallen -12.71% This Week: Buy, Hold, or Sell?

Get the most recent info and news about ThoughtWorks on HackerNoon, where 10k+ technologists publish stories for 4M+ monthly readers.

Thoughtworks Holding, Inc. provides technology consultancy services in North America, the Asia Pacific, Europe, and Latin America. The company's consultancy services integrate strategy, design, and software engineering to enable enterprises and technology disruptors to thrive as modern digital businesses. It offers enterprise modernization, platforms, and cloud services, including modernization strategy and execution, digital platform strategy and engineering organization transformation, cloud modernization, cloud-native application support and evolution, and platform assessment and remediation; and customer experience, product, and design services comprising idea to market, customer experience strategy, product management transformation, and product design and delivery. The company also provides data and artificial intelligence services, such as data strategy, intelligent products, data platforms and data mesh, continuous delivery for machine learning, and data governance; and digital transformation and operations services, which include delivery transformation, digital fluency, organization transformation, value-driven portfolio management, technology strategy, executive advisory, and digital foundations training. It serves its clients in various industry verticals, including technology and business services; energy, public, and health services; retail and consumer; financial services and insurance; and automotive, travel, and transportation. The company was founded in 1993 and is headquartered in Chicago, Illinois.

ThoughtWorks

is a regular time to take a look at what experienced industry experts think might be the next wave of tools, practices, and technologies to consider or stop using. Thoughtworks’ Technology Radar I always look forward to adding many new “blips” to my list, or seeing which are growing in adoption since you last took a look. Version 27 is out now, and it continues some trends that the radar has been following for a while, such as “platform as a service” or forms of group programming. This round-up is far from comprehensive, but just the blips that appealed to me or that, I thought, might appeal to you. If any of them take your interest, or you have an opinion on anything I’ve featured, ! head over to your profile and let our readers know Mainstreaming of Machine Learning It really does feel like that in the past 6 months or so, machine learning went from something that mostly only developers and data scientists interacted with to something that the public had awareness of. There was announcement after announcement of another ML or AI-based tool that spat out some sort of media after you fed something into it, and we were swamped with thousands of strange-looking images and videos of celebrities. This also means that developers interested in experimenting with ML also have a lot more resources available to them in the shape of data sets and frameworks to use those data sets. Of relevance to experimenting developers is , a field of machine learning enabling a variety of always-on use-cases and targeting battery-operated devices. TinyML Another is , a method for creating ML pipelines that might be more familiar to developers from other backgrounds. feature stores This radar also covered ML-related tools for improving the developer experience of building and training models, for example, the practice of “federated machine learning” for aggregating model data across machines for processing or synthetic data for initial model testing. Continuous Observability Despite being a relatively new term, “observability” has rapidly grown from a loose collection of practices and standards for building a better picture of a running system to become a broader term to mean, well, to mean all sorts of things. The latest area of the developer workflow to receive insights is one that I am surprised took so long, observability for continuous integration and delivery pipelines. While CI and CD certainly bring benefits, processes frequently go wrong with very little insight into what until you try, try again. Now, a handful of existing observability vendors and open-source projects are bringing tracing-style visualizations of continuous processes to hopefully help you debug quite what was going on. Software Bill of Materials As developers lean increasingly on semi-anonymous containers and packages for their work, those focused on security and legalities looked on and wondered, “do we trust this?”. This concern has led to a rush to standardize and normalize (in enterprise, especially) a “software bill of materials”, often referred to by the comical acronym, SBOMs. While, in theory, “anyone” can dig into an open-source project and see what its components are, this is generally easier said than done and isn’t possible with closed-source projects at all. Recent high-profile vulnerabilities in software revealed how small dependencies can bring such large problems. While SBOMs could go a long way to help, I wonder how many companies will want to reveal their inner workings and be honest about them. Sustainable Coding This is a topic that I was inspired to cover myself after speaking with someone from Thoughtworks about their Carbon cloud footprint tool. The tendency to endlessly throw new frameworks, tools, and cloud frameworks at a problem has led to many of us forgetting that all of these lines of code actually run somewhere on something. And that leads to carbon emissions. Water motivated by altruistic reasons or financial, and an ecumenic downturn leads to cost savings, this is a topic more are talking and thinking about. Closely related to the environmental cost of projects and their infrastructure, and an option I’ve seen used by production teams is which estimates the cost impact of changes you make to Terraform definitions. infracost Responsibilities as Code Any SaaS company defines service-level indicators (SLIs) and service-level objectives (SLOs) that their clients can expect. However, how companies defined these have often been a bit haphazard and non-standard, and with so much else defined in codified pipelines, why not this fundamental component too? Several Observability providers now offer this option and of course, a group of people started a standard, . OpenSLO A No to Node I dabble in JavaScript and TypeScript and have noticed a handful of emerging runtime alternatives to Node recently. I am not sure what is wrong with Node, aside from being fairly old now, to warrant alternatives, but I guess competition is good 🤷‍♂️? is one newer alternative that I tried a few months ago, and I’ll admit I wasn’t really sure what benefits it brought me, but it uses WebKit’s JavaScriptCore instead of Chrome’s V8 engine. Bun Again, variety isn’t a bad thing. Bun is written in , which I had never heard of before, and it claims to be a “drop-in” C/C++ replacement. Zig Which leads nicely to… C+++ If Zig, Rust, and other languages are anything to go by, numerous people feel that C++ needs a more modern replacement. Google has thrown another option into the list of contenders with . Carbon The language is still in experimental stages but claims to be easier to understand and onboard with. Google has a tendency to spin up many experimental projects and then dump them again, so Thoughtworks’ suggestion is currently “wait and see”.

Developer Trends from Thoughtworks’ Technology Radar 27

Tendencias de desarrolladores del Radar de tecnología de Thoughtworks 27

Tendances des développeurs du radar technologique de Thoughtworks 27

थॉटवर्क्स के टेक्नोलॉजी रडार 27 से डेवलपर रुझान

ソートワークスのテクノロジー レーダー 27 からの開発者トレンド

Tendências de desenvolvedores do Technology Radar 27 da Thoughtworks

Xu hướng dành cho nhà phát triển từ Radar công nghệ của Thoughtworks 27

Thoughtworks 技术雷达的开发者趋势 27

The Noonification: Effective Techniques Against Disinformation (11/15/2022)

A while ago released an for anyone to host their own personal radar. ThoughtWorks open source repository technology I was curious to see how the reputable company implemented it and strangely I noticed a lot of concepts that reminded me of Java, such as and error handling with . stateful objects try/catch/exception All the application really does is take a single input and produce a tech radar. A Java-esque approach seemed inappropriate for that use case so I decided to rewrite some of it in ! Elm Step 1: Model the radar Let’s start things off by thinking about how to model the radar itself. If we model our problem carefully it can simplify the work ahead of us. First let’s consider what we know about the data. The radar is split into and . These quadrants and rings represent different categories that several can be placed into. four quadrants four rings blips Since we know there are only four quadrants and rings let’s represent those as . union types So far so good. Next up, the blips. Modeling the blips requires some extra thinking because there are two representations of a blip. The first representation is the blip data from the Google Sheet ( ). The information included is the , , , an flag, and a . example name ring quadrant isNew description The blips that are visualized on the radar need those same 5 properties but in order to be displayed on the radar they also need an . x-y position Several ways to model these blips include: This option uses fewer types but will inevitably lead to more . Throw all properties into a single record and make the type of the position field a . Maybe maybe handling This option removes the but at the cost of in two separate record fields. Treat the blips from the Google Sheet as a distinct type and record from the blips visualized on the radar. maybe verbosity duplicating data Since the properties of the radar blip are a superset of the blips from the Google Sheet we can . A blip positioned on the radar will have the Google Sheet blip data in addition to a defined position. represent the data with composition There are other options worth considering, especially options that leverage union types, but the third option will suffice for now and we can refactor later if needed. Next up is visualizing the radar. If you’re curious on how we’re doing in comparison to ThoughtWorks’ open source example then swing on over to their OO equivalent modeling . Step 2: Visualize the radar Now that we have the basic building blocks to construct a view let’s start building the radar visualization. The first thing I want to do is get the quadrants and rings visualized. We’ll heavily use SVG and borrow a lot of the styles from the ThoughtWorks open source project. I’m sure they won’t mind. Creating an arc The radar isn’t a circle. It’s technically four quarter-circles put together, a.k.a arcs. Circles in SVG are not that hard. Arcs, on the other hand, suck big time. Here’s a demonstration of what I mean. With the above code working it will be exiled to a utility module so that we don’t have to think about the implementation details for creating an arc in SVG. Visualizing quadrants Visualizing a quadrant only requires that we visualize 4 arcs (rings), each with a different radius. Not bad. If we do this three more times and provide different numbers we get the entire radar background. Visualizing blips There are two types of blips that can be visualized which is determined by the flag. One is a rounded triangle and the other resembles a smudged circle. isNew I’m going to simply transcribe ThoughtWorks’ for these blip visualizations to Elm. code ..more SVG implementation details that we’re not going to look at ever again. Next up, visualizing mocked blips on the radar. Step 3: Wire up the view with mock data Before we consume actual data from a Google Sheet we’re going to mock up some data to make sure our blips are correctly displayed on the radar. The above function is but it will produce 16 blips on the radar, one in each ring in each quadrant. However, this brings up the question of where exactly to position the blips. temporary I went ahead and peeked at how . In short, they produce a sinusoidal curve that a blip is to be positioned on and if it collides with another blip it will try another random position on this curve. ThoughtWorks did it We can do the same thing in Elm but it brings up an interesting topic.. how to do randomness in a pure functional language. <quick detour> Pure randomness with generators In Elm, every function is a pure function. In order to produce randomness we can ask Elm to generate us a random value for a given seed. A random value and another seed is returned so that we can use that seed to ask for yet more random values. However, if we’re producing many random values then managing these seeds becomes extremely tedious and prone to mistakes. Fortunately, Elm gives us the concept of a . According to its documentation, Generator a generator is like a recipe for generating certain random values. Here’s an example generator that can be used to produce random integers from 3 to 7. Random.int 3 7 Here’s another generator for producing a random list of even values under 100. Simply creating a generator doesn’t actually produce a random value. It still has to be passed to . Random.step (randomEvens, nextSeed) =Random.step (generateEvenValues 10) (Random.initialSeed 123) Given this knowledge we can compose a few generators to randomly position blips along a sinusoidal curve and keep producing values if there is a collision. This will behave identically to the ThoughtWorks algorithm and it also happens to be where we convert the to . List GoogleSheetBlip List PositionedBlip Randomly positioned blips with Generators I realize we went from 0 to 60 with generators in about 90 seconds. If the above code is not immediately understandable, don’t worry. Like much with Elm, it is initially unfamiliar but it very quickly becomes second nature to read that code. </quick-detour> Blips visualized with randomness When we run the mock data at the beginning of this section into our view function we get a radar with blips on it. At this point we can keep throwing data at the radar and verify that the algorithm for determining blip positions is working. The positioning here seems reasonable. Moving on. If you’re tracking progress here’s how ThoughtWorks is doing the same . It’s also worth noting that the radar is mirrored along the y-axis because we hard coded the random seed. That’s fine. Step 4: Model the app state Just as before, modeling the app state is incredibly important. When writing your own Elm applications it’s worth pausing, discussing, and considering the trade-offs for how to model your data. For this application we already have a radar but we’re missing a page to enter a Google Sheet url. I chose to model that page state like this: It will have a form with an initially empty url. The form might have an error and we’ll want to know if we’re actively retrieving the Google Sheet. There are to this approach, but we’ll stick with these three properties for now. alternatives That covers what I’m calling the . Lastly, there’s the that needs to be provided to The Elm Architecture. Landing Page Model This is loosely based on except with a few things cut out for the sake of simplicity, such as not dealing with routes for such a small application. Richard Feldman’s SPA example It’s important to point out that at a high level this application is in one of two states: We’re on the landing page and interacting with the url input form We’re on the radar page interacting with a tech radar Step 5: User input, regex, data retrieval, and error handling The landing page involves , , , , and in all of those cases. I’m going to skip the user input part because if you made it this far you know how to do that already. receiving input from the user parsing out a Google Sheet ID performing an HTTP request parsing the response handling errors If I’m wrong and handling user input in Elm is new to you I suggest pausing and checking out this example . Regular expressions in Elm We’re about to go 0 to 60 again. Hang on. The user will supply us with a link to their published Google Sheet, such as “ ”. https://docs.google.com/spreadsheets/d/11Fd0lwNIEUs2ymxNEiTfpM5CoQHQbMuOId8TjrQHDn0/edit?usp=sharing Hidden within this URL is an ID that we need to perform an HTTP request. It’s that unreadable string between “/d/” and “/edit?”. First we’ll declare a regular expression that will find that ID. It goes without saying that credit for this regex goes to ThoughtWorks again. Within that regex are groups and we care about the first group specifically. In order to apply a regex to a string we use the function. find matches =find All sheetIdRegex url That returns a list of matches that take the following shape. Our Google Sheet ID is hidden within the list. So what we want to do is get the first match in the list of matches returned from , and on that first match find the first item in its . submatches find submatches If you’ve worked with Elm lists and before you’re probably already aware that we’re about to go head first into . Thanks to the code to pluck off that ID and produce a Result isn’t too bad. List.head MaybeLand elm-community/maybe-extra The first collapses the double Maybe that occurs when you do a on a List of Maybes. However, it’s still a Maybe returned from so the second collapses it one more time before converting it to a Result. MaybeExtra.join List.head Maybe.map MaybeExtra.join Retrieving the Google Sheet data Once we have the ID we can make a request to retrieve the Google Sheet data in CSV format. When this Cmd is performed it’ll call with the Result. httpResultToMsg The above function does the following On success, split the string by new lines Iterate over each row and attempt to parse the CSV as a blip Successfully parsing data puts it in the list while parse errors are added to the list. blips errors Send off a Msg with the blips and any errors Parsing each CSV row is as simple as attempting to map the data onto our data model defined earlier. Conclusion This post is getting long so I’ll wrap things up by making a few observations in rewriting some of the ThoughtWorks Tech Radar. The BYO radar project used for , for graphics and HTML templating, and for Google Sheets. It uses to model its data and incorporated rather than gracefully handling errors. chance randomness d3 tabletop parsing stateful object instances exception handling The code is fairly complicated and even with understanding the desired behavior it’s difficult to track the implementation details. Most of all, after spending so much time in that code I still don’t understand what much of the code does. On the other hand, a functional approach with Elm yielded more comprehensible code with similar functionality. In fact, once you grasp the way Elm does randomness and regular expressions you’ll realize the code is much more simple too. To see the partial rewrite in action check out these two links: http://ckoster22.github.io/elmradar/ https://github.com/ckoster22/techRadar/tree/blogpost

Rewriting the ThoughtWorks Tech Radar in Elm

Akshay Rawat’s Innovative Payment Solutions for the Gig Economy

Akshay Rawatın Gig İqtisadiyyatı üçün İnnovativ Ödəniş Həlləri

Akshay Rawat inovativní platební řešení pro koncertní ekonomiku

Soluciones de pago innovadoras de Akshay Rawat para la economía informal

Inovativna rješenja plaćanja Akshaya Rawata za ekonomiju koncerata

Akshay Rawat innovatív fizetési megoldásai a koncertgazdaság számára

Akshay Rawat-ի նորարարական վճարային լուծումները Gig-ի տնտեսության համար

ギグエコノミーのためのアクシャイ・ラワットの革新的な決済ソリューション

Акшай Раваттың концерттік экономикаға арналған инновациялық төлем шешімдері

Innowacyjne rozwiązania płatnicze Akshaya Rawata dla gospodarki gig

Инновационные платежные решения Акшая Равата для экономики свободного заработка

Қарорҳои инноватсионии пардохти Акшай Рават барои иқтисодиёти гиг

Akshay Rawat 为零工经济提供创新支付解决方案

How I Got Llama 3 to Revere God!

116 Stories To Learn About Noonies2021

Does the team or app size affect the release process? Well, it depends. Let’s imagine a startup with one small team. In this case, the team usually makes a feature, and then just releases it. Now, let’s imagine a large project, for example, a banking app, with many teams working on it. In this case, there should probably be a process, release cycles, and maybe some bureaucracy. Without that, there will be chaos. So, when does it become clear that it’s time to set up such a process for your app? In this article, I’ll share my experience of implementing Release Train for the Dodo Pizza app (Android and iOS) and the problems we faced that made our team implement Release Train. If you are the Team Lead/Tech Lead of an Android or iOS project that is growing fast and you have not managed the release process yet, I hope that our experience will help you. How It Used to Be In 2021, we were already using a Trunk-based Development (TBD) approach in our teams. We covered the code with feature toggles, decomposed tasks, and ran unit and UI tests. Our feature branches didn’t live long, and we had CI working. The release process was very simple: whoever was ready to roll their feature out, rolled it. Ideal Scenario Here’s roughly what our branch workflow looked like. Several teams (gray, blue, orange, and green) worked on different features. Since we were working according to TBD, each feature could live through several consecutive branches. For example, the gray team made their feature in 4 steps, the blue and orange teams made theirs in 1 step, and the green team made theirs in 2 steps. When a team finished a feature, they could roll out a release. For example, if the blue team finished a feature, they could do a release. Then, the orange team would finish a feature and do another release. We had the perfect flow, as it seemed then. It worked great up to a point, but all good things come to an end. Something went wrong: tough, crowded, and unpredictable Mammoth The first problem we encountered was that releases started accumulating a lot of features and became too big. The teams didn’t always want to release their features right away. The release and regression process was time-consuming and took 3–4 days. So if your feature was small and not urgent, you didn’t always get to release it yourself because probably, some other team would do a release soon, and it would be included in that release. Roughly it looked like this: This was quite a fragile arrangement, especially when the number of teams started to grow. Many teams developed many small features, and the total volume of new code in each new release became huge. When someone got to release their big feature, they had to release a whole together with it. mammoth The mammoth-releases resulted in: delayed regression; higher risk of regression bugs; higher risk of getting a bug in production. We needed to make it so that even if the blue and orange team from the example didn’t want to release, the release would be done somehow. Bottlenecks Every team is unique, and every feature is different. Sometimes, things happened in such a way that several teams would finish their features around the same time. In this case, there was a lot of “wait for me, I’ll merge it tomorrow morning, I promise!” going around. In the end, such bottlenecks resulted in: releases turning into mammoths; delayed releases negatively affecting the releasing team’s plans especially if everybody else’s needs were met. We needed to make 2 crucial changes: The releasing team shouldn’t need to wait for anyone; every other team should know when the next release is expected. Lack of Predictability Imagine, the blue team made a small feature and expected the orange team to release it soon. But something went wrong, and the orange team didn’t roll out the release either because of some problems of their own. As a result, the blue team told the business that the feature would be in production soon, but it turned out to be not soon enough. As a result, it is impossible to predict when the feature will be in production. This doesn’t mean that the blue team is irresponsible. If they have a super important or urgent feature, then of course they will release it themselves. But in other cases, there is no way to tell exactly when the feature will be available to the users. As you can guess, we were experiencing such issues quite often. We needed to be able to tell exactly when customers would get a feature in production regardless of its size or urgency. All 3 problems (mammoth releases, bottlenecks, and lack of predictability) are closely related and complement each other. However, probably the most fundamental and important of them all is the lack of predictability. It generates other problems. Release Train We've had enough; it was time to make a change. The was supposed to help us do that. Release Train The term Release Train means different things: a , or a that manages the release process. Here, we’re going to talk about the scheduled release process. scheduled release process dedicated team I like the way Release Train is described by Martin Fowler in the “ ” article, and the definition given by (maybe it belongs to Martin as well). Patterns for Managing Source Code Branches Thoughtworks in their tech radar This is how we have defined Release Train for ourselves: Release Train is the process of coordinating releases between teams. All releases happen on a fixed schedule, independent of whether the features are ready or not. The train doesn't wait for anyone. If you are late, you have to wait for the next one. Let's break it down with a couple of examples using our color-coded teams. Solving the Mammoth Problem Release Train happens on schedule and does not depend on who has merged what into the main branch. In the example below, the features from the blue and orange teams will be released. The rest will wait for the next train. We could wait a bit longer, but then we'd get a mammoth. Resolving Bottlenecks At the same time, the Release Train helps us plan our work more efficiently. Let’s say that the blue team originally planned to finish a feature later. But since everyone knows the release date, they can slightly rearrange their plans to finish the feature early. Or, on the contrary, they can realize that they will definitely not be on time for the next train, and hence, they can finish the feature safely because they know the whole schedule. In the example below, the blue team wanted to get to the release and merge all their changes before the release. Otherwise, there might have been a bottleneck. Most importantly, Release Train . gave us predictability by design These examples may seem obvious to some, but we solved problems as they arose. When there were no problems with releases, we didn’t bother using Release Train. When problems accumulated, we realized that the time had come. How to Implement the Release Train in Your Team The first thing we did was write an . An RFC refers to both the process itself and the design document that use before they start working on a project. Some use RFCs specifically, some use ADRs, and some just call them by the more generic term Design Doc. RFC many companies At Dodo Engineering, we use both RFCs and ADRs. Our RFC process looked like this: We drafted an RFC document; we discussed it in a small group, collected comments, and made adjustments; then the RFC was communicated to a wider group; then we implemented it; after that, we gathered feedback, tracked metrics, and evaluated results. The structure of the RFC document for our Release Train was as follows: description of the Release Train process; what teams are involved, what they are doing; what the schedule will be; metrics. In drafting the RFC, we relied on the experience of other companies: SkyScanner Soundcloud Monzo Facebook First Implementation First, we came up with this process: release every week; create a release branch on Wednesday morning; complete regress, and send the app for review on Friday; start rolling out the release on Monday. Release team: 1 iOS and 1 Android developers from one of the feature teams; 2 QA engineers. create a new release branch on Wednesday; make a schedule one quarter ahead, indicating when it's each team's turn to release. After a quarter get together and extend the schedule. Schematically, our Release Train looked like this: It Didn't All Go Smoothly After a month, it became clear that although the first experience felt great, It was really hard to do a regress every week and be done by Friday; there was no time for hotfixes, and they sometimes happened. In 2021, our regression test used to take 3–4 days on average. We managed to shorten it to 2–3 days in 2022, but sometimes, it would exceed that time frame. We continued covering regression cases with e2e tests, but we didn’t have 100% coverage yet. We had about 70% and 60% coverage of regression cases on each platform respectively. The takeaway from this is that it will likely be uncomfortable to run a release cycle every week. as long as you have regression tests taking a few days to complete, The Final Answer We ended up moving to 2-week release cycles, and Release Train now looks like this: release every 2 weeks; create a release branch on Wednesday morning; regress, and send the app for review on Friday; start rolling out the release on Monday. Release team: 1 iOS and 1 Android developers from one of the feature teams; 2 QA engineers. make a schedule one quarter ahead, indicating when it's each team's turn to release. After a quarter, get together and extend the schedule. roll the release out gradually; do the hotfixes if needed, now when we have time for them; a week later on Wednesday, create a new release branch. This is how the process looks if everything goes according to plan: It all looks like a weekly cycle except there’s plenty of time left for potential hotfixes. This is what it will look like in case of extended regression tests: No big deal either; there’s still time even for hotfixes. How Did the New Process Affect Predictability? The main goal for us was . It can be broken down into two parts: to increase predictability When will the application be released; In which release will my feature get into? We answered the question “When will there be a release?” by implementing the Release Train process. Now, each team will be able to answer the question “in which release will my feature end up?” independently at the moment when they plan and evaluate the feature. Before, it was impossible to say for sure because another team might or might not do the release. Now, everything depends only on that team’s own planning. To further confirm this, we conducted surveys amongst mobile developers, QA, and product managers, where together, with other questions, we asked: When is the next release? (100% answered this question). Did Release Train help you plan your teamwork? (75% answered positively, but some perfectly predicted their work even without a Release Train). Release Train has also helped us with code freezes and release freezes. We had several of them, in addition to New Year’s Eve (for example, September 1st and some holidays). Now, with Release Train, we don’t have to adjust to these dates by creating release branches, regress testing, and all that. Releases work on schedule; we just open them in the stores later. Impact on Metrics Beyond just solving problems, we also measured metrics. Let’s take a look at the main ones. Lead Time The first important metric we measured was the . Lead Time commitment to release This is what the graph looks like. I marked the point when we started the Release Train process with an arrow. The graph shows that Lead Time went down to somewhere around six days. Is six days a long or short time? Google Benchmarks There are , but it’s mostly for the backend. On their scale, they distinguish the following groups: benchmarks from Google for this metric Elite: less than an hour High: 1 hour to 1 week Medium: 1 week to 6 months Low: 6 months or more I believe that for standard mobile apps, lead time should ideally aim for half the length of the release cycle. This is equivalent to merging a task into the main branch every day. This said, . if the release cycle is 14 days, Lead Time should aim for 7 days Bugs Per Regression Another metric we track is the number of bugs per regression. It describes how stable the release candidate is. If the previous release was a long time ago, then we probably created a lot of new code that might potentially contain a high number of bugs, and we might spend more time on regression and fixes. At one point, this metric was down to three bugs. The specific numbers aren’t that crucial, but overall, you can see that the trend has gone down. More Metrics I’ll briefly discuss what metrics were also monitored as part of the Release Train. Crash-free. We always keep an eye on this metric. There was a hypothesis that it would drop due to our attempts to fit the regression into a tighter timeframe. Well, no drop happened. We wondered if frequent (weekly) releases would have an impact on customer churn and on deleting the app. As a result, we detected no impact. Implement, Improve We like the current process as we think it has achieved its goals. We also know how to improve it further: We continue to work on automating the regression to make it simpler and faster. So far, we have left out the part on work automation (scripts for branching), but this would also be a great point of growth in the future. Our app works in 20 countries, and we need to translate the application into many different languages. There is an internal service for this, but developers still have to participate in this process manually before release. Automating this process potentially might improve the release cycle even further. Summary While we were relatively small, we didn’t need a Release Train. When we faced the fact that we couldn’t predict releases, their size, and number, we decided to implement Release Train. At first, we tried weekly release cycles, but because of time-consuming regressions, we had to switch to two-week release cycles. We’ve been living this way ever since. Now, we have predictability of releases, and metrics show positive dynamics. We plan to increase the coverage of regression cases with e2e-tests, automate the process of working with branches, and optimize the process of translations. I hope this article and our experience will help you, especially if you have already faced similar issues and they made you think about the release process. Thank you so much for reading my article. I hope you enjoyed it. If you have any questions or suggestions, drop me a line in the comments, and I’ll be sure to read it! And . Usually, I post about Android development and software engineering in general. follow me on Twitter Also published here

What Problems Does Release Train Solve in Mobile App Development?

মোবাইল অ্যাপ ডেভেলপমেন্টে রিলিজ ট্রেন কোন সমস্যার সমাধান করে?

Welche Probleme löst Release Train bei der Entwicklung mobiler Apps?

¿Qué problemas resuelve Release Train en el desarrollo de aplicaciones móviles?

Quels problèmes Release Train résout-il dans le développement d’applications mobiles ?

मोबाइल ऐप विकास में रिलीज़ ट्रेन किन समस्याओं का समाधान करती है?

Release Train はモバイルアプリ開発におけるどのような問題を解決しますか?

모바일 앱 개발에서 Release Train은 어떤 문제를 해결합니까?

Que problemas o Release Train resolve no desenvolvimento de aplicativos móveis?

Какие проблемы решает Release Train при разработке мобильных приложений?

Sürüm Treni Mobil Uygulama Geliştirmede Hangi Sorunları Çözer?

Bản phát hành có giải quyết được vấn đề gì trong quá trình phát triển ứng dụng di động?

Release Train解决了移动应用开发中的哪些问题？

260 Stories To Learn About Team Productivity

THOUGHTWORKS

thoughtworks.com

10K+ employees

Since 1993

COMPANY RANKING

THOUGHTWORKS

EVERGREEN INDEX #5

Representing this company? Click here to claim and customize this page!

ThoughtWorks WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

THOUGHTWORKS

thoughtworks.com

10K+ employees

Since 1993

COMPANY RANKING

THOUGHTWORKS

EVERGREEN INDEX #5

RELATED COMPANIESRANK

STORIES ABOUT THOUGHTWORKS

Representing this company? Click here to claim and customize this page!

ThoughtWorks WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!