Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

Ask High Scalability: How to build anonymous blockchain communication?

This question came in over the Internets. If you have any ideas please consider sharing them if you have the time...

I am building a 2 way subscription model I am working on a blockchain project where in I have to built a information/data portal where in I will have 2 types of users data providers and data recievers such that there should be anonimity between both of these.

Please guide me how can I leverage blockchain (I think Etherium would be useful in this context but not sure) so that data providers of my system can send messages to data receivers anonymously and vice versa data receivers can request for data through my system to data providers.

I believe, it work if we can create a system where in if a user has data, it will send description to the server, The system will host this description about data without giving the data provider details.

Simultaneously server will store info which user has the data. When data receiver user logs in to system and wants and sees the description of data and wants to analyze that data, it will send request to server for that data. This request is stored in the server and it will allow access to data without receiver knowing who wants to access that data, but it will trigger a message to receiver that an anonymous user wants to access data and would data.

Can you please guide me how to build architecture of this system and how to proceed to do a POC?

Categories: Architecture

Software Development Linkopedia December 2016

From the Editor of Methods & Tools - Wed, 12/14/2016 - 12:21
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about project management personalities, better teams, starting a new job, code reviews, agile testing, scaling Agile, IoT and tests quality. Blog: Implementers, Solvers, and Finders Blog: Giving better code reviews Blog: […]

Android Wear 2.0 for China - Developer Preview

Android Developers Blog - Wed, 12/14/2016 - 03:10
Posted by Hoi Lam, Developer Advocate

Today at Google Developer Day China, we are happy to announce a developer preview of Android Wear 2.0 for developers creating apps for China. Android Wear 2.0 is the biggest update since our partners launched their first devices in China last year.

We're making a Developer Preview available today and plan to release additional updates in the coming months. Please send us your feedback by filing bugs or posting in our Android Wear Developers community.

Developing for the Chinese Market

With Android Wear 2.0, apps can access the internet directly on Android Wear devices. As a result, for the majority of apps, having a companion phone application is no longer necessary. This means that most developers creating apps for Android Wear 2.0 may no longer need to import the Google Play services library.

There are two situations where developers will need to import Google Play services for China:

  • Apps that require direct interaction with the paired mobile device - some experiences require Android Wear to connect directly to a paired phone. In this case, the Data Layer API introduced in Android Wear 1.0 will continue to function.
  • New FusedLocationProvider for China - we have added location detection to the SDK for Chinese developers. With the user's permission, your app can receive location updates via the FusedLocationProvider.

You can find more details about how to import the China compatible version of Google Play services library here.

Product testing for Android Wear 2.0 for China

The Android Wear 2.0 Developer Preview includes an updated SDK with tools, and system images for testing using the Huawei Watch.

To get started, follow these steps:

Give us feedback

We will update this developer preview over the next few months based on your feedback. The sooner we hear from you, the more we can include in the final release, so don't be shy!


Android Wear 2.0 中国版 - 开发者预览版

编辑: 林海泉, Android Wear 开发平台负责人

今天在上海举办的Google 开发者大会上,我们正式宣布了一款专门针对中国市场的Android Wear 2.0 开发者预览版。Android Wear 2.0系统,将是自我们的合作伙伴首次发布手表产品以来最重大的更新。

开发者预览版已于今日正式上线。与此同时,我们也计划在未来的几个月内持续进行更新。请您将您遇到的问题在此提交反馈,或者在我们的Android Wear开发者论坛发表意见。

为中国市场开发应用

在Android Wear 2.0系统中,应用可以由Android Wear手表直接连接至互联网。因此,对于大多数应用来说,手机端的伴侣应用也就变得不再必要。这也意味着,多数为Android Wear 2.0开发应用的开发者将不再需要引用Google Play services客户端库。

目前,在两个情况下开发者仍然需要引入Google Play Services客户端库来为中国市场开发应用:

  • 需要与手机直接进行通信的应用 - 有一些用例需要Android Wear手表与已配对手机直接连接。在这种情况下,Android Wear 1.0中引入的Data Layer API仍然可以继续使用。
  • 使用 FusedLocationProvider - 我们在最新的中国版SDK中加入了定位的支持。在用户的许可下,您的应用可以通过FusedLocationProvider来接收定位更新。

您可以在这里找到关于如何引入与中国版兼容的Google Play service的更多信息。

Android Wear 2.0 中国版产品测试

Android Wear 2.0 开发者预览版包括最新的SDK套件,手表测试系统镜像(基于华为手表)。

情按照以下步骤进行测试:

开发反馈

我们会根据您的反馈在未来的几个月中更新开发者预览版。您给我们的反馈越早,我们将会在最终的发布版本中包含更多针对您的反馈的解决方案。敬请期待!

Categories: Programming

Google Developers YouTube Channel Reaches 1 Million Subscribers!

Google Code Blog - Wed, 12/14/2016 - 01:00
Posted by David Unger, Program Manager

Earlier this week, the Google Developers YouTube channel crossed the 1 million subscribers threshold. This is a monumental achievement for us, and we are extremely honored that so many of you have found our content valuable enough to click that red ‘Subscribe’ button.
The Google Developers YouTube channel has been bringing you content for just over 8 years, covering major developer events, like Google I/O and Playtime, as well as providing best practices on the latest tools to help you build high quality experiences! In that time, we’ve shared over 2,000 videos that have been viewed over 100 million times. Here is a look back at how we got to this milestone:

We are gearing up for another year of videos to help developers all over the world. To avoid missing any of it, you can subscribe to each of our YouTube channels using the following links:
Google Developers | Android Developers | Chrome Developers | Firebase
Categories: Programming

Post-Agile Age: Brand-Driven Ecosystems

Brand-driven ecosystems set down roots.

Brand-driven ecosystems set down roots.

Certifications are only one of the drivers that are hardening the boundaries between Agile techniques, frameworks and the outside world.  Brand ecosystems, made up of proprietary methods, tools, and/or tool suites also tend to contribute to hardening of boundaries which slows innovation and evolution of how teams and organizations work. The slowing of innovation and evolution of how work is done is a marker of the beginning of the end of all of the great movements of the past.  In this case, specifically the hardening of brand ecosystems marks the turning point of Agile as a movement and perhaps a hint that the dawn of the post-agile age is nigh.

Brand-driven ecosystems carry many of the same upsides and downsides that were discussed for certifications. Most Agile brands are based on or implemented by a tool or suite of tools.  Three most critical selling points for brand-driven ecosystems are:

  •        Structure helps teams and organizations to behave. 
  •        Standard methods are a mechanism to document structure.
  •        Tools implement standard methods and approaches. 

The three critical selling points support two sets of goals all Agile brands have. The customer-centric goals of brand-driven ecosystems are to make work and communication easier. However, the internal business goals generally are to capture and lock customers into an ecosystem to support the economic needs to the organization(s) selling the brand ecosystem.

While there are positives to brand-driven ecosystems,  there are also problems caused by embracing these ecosystems.  The problems stem from the unintended consequences caused mostly by the by the second set of goals which lock in specific points of view and slow or stop the evolution of ideas.  Four consequences bear deeper exploration:

  1. Change becomes difficult. The first unintended consequence of locking into an ecosystem is that change becomes difficult.  This a is a common issue seen with nearly all software packages.  Brand ecosystems make any change that is outside the boundary more difficult due to the investment in the tool, locking in business processes, and the collection of specific data and history. Just ask any programmer how much fun upgrading a package is if they have made changes to the base code. While configurable tools make change within the boundary of what is perceived as normal practice easy; any deviation outside that boundary is generally difficult.  For example, I have observed multiple organizations that have allowed teams (or departments) to define their own data structures for Agile tools. Data structures are used to define what the data that is tracked and reported. Allowing teams to operate without guidance often leads to teams using “user defined” fields differently (each with different usage and validation rules) across the organization making both sharing people between teams and implementing upgrades a horror story.
  2. Tools define the methods and frameworks. Tools which are typically a part of most brand ecosystems carry their own implied methodology or set of techniques. The methods embedded in the tools are generally proprietary making change difficult if not impossible. I use several Agile tools (and often recommend those tools to others); however, each tool represents a different instantiation of Agile or kanban.  Early in the life cycle of a movement, like Agile, competing brand ecosystems are very healthy. The competition acts as a powerful marketing tool to expand the market. As time progresses and market growth slows, brands shift from expanding the market to locking in customers and revenue streams ( an excellent example of capitalistic behavior).  This change in perspective shifts the intellectual underpinnings of the movement toward the brands and their economic needs from the needs of practitioners.
  3. Tools are put before the processes.  This consequence is a close cousin to the issue with brand defining the method and is a common occurrence in software development (broad definition) environments. Organizations adopt tools in a vain attempt to define how they work without really addressing how Agile (or any other method) is really supposed to work.  For example, I recently talked with a SPaMCAST listener whose company had purchased and adopted a very popular tool suite (one that I would have recommended). Once they had the “tool” training, they used that training to define how they would do Agile, rather than learning Agile and then defining how they would use the tool.  They used the steps built into the tool to define how they work.  They put tool deliverables ahead of customer deliverables. The organization was struggling with the value of using Agile. One example that of this issue shared by another reader of the blog was an implementation of user stories without involving, talking or reference to  . . . users.
  4. Messing with a stable process.  In a very similar vein, one of the classic brand ecosystem mistake occurs when organizations try to retrofit stable processes to a tool or brand suite even though they are delivering value and have good customer satisfaction.  This is sometimes a reflection of the “grass is always greener in your neighbor’s yard” factor, or sometimes a reflection of letting someone with a checkbook and organizational ADD go to a conference. If how work is done isn’t broken, think really hard about messing with it.

Brand ecosystems do not have to impede the Agile movement; they can actually make life easier. However, as the competition for users becomes more heated, stronger boundaries develop all sort of potential issues can arise.  To paraphrase Philip Lew on an upcoming Software Process and Measurement Cast, brands and tools won’t kill agile, people will kill agile with tools. We can buy into and use brand ecosystems, but we need to be very careful that we avoid getting locked.  Software development is not easy, once more than one team is involved the degree of complexity increases. Brand ecosystems become almost a requirement to deliver value. Unfortunately, they come with a cost that is often more than just money, part of the cost is the need to ensure flexibility.

Planned essays in Post Agile Age Arc include:

  1. Post Agile Age: The Movement Is Dead
  2. Post Agile Age: Drivers of the End of the Agile Movement and Method Lemmings
  3.  Proscriptive Norms
  4. A Brand Driven Ecosystems (Current)
  5. A Lack of Systems Thinking/Management
  6. The Age of Aquarius (Something Better is Beginning)

Categories: Process Management

Android Wear 2.0 Developer Preview 4: Authentication, In-App Billing, and more

Android Developers Blog - Tue, 12/13/2016 - 19:07
Posted by Hoi Lam, Developer Advocate

A key part of Android Wear 2.0 is letting watch apps work as standalone apps, so users can respond to messages, track their fitness, and use their favorite apps, even when their phone isn't around. Developer Preview 4 includes a number of new APIs that will help you build more powerful standalone apps.

Seamless authentication

To make authentication a seamless experience for both Android phone and iPhone users, we have created new APIs for OAuth and added support for one-click Google Sign-in. With the OAuth API for Android Wear, users can tap a button on the watch that opens an authentication screen on the phone. Your watch app can then authenticate with your server side APIs directly. With Google Sign-In, it's even easier. All the user needs to do is select which account they want to authenticate with and they are done.

In-app billing

In addition to paid apps, we have added in-app billing support, to give you another way to monetize your Android Wear app or watch face. Users can authorize purchases quickly and easily on the watch through a 4-digit Google Account PIN. Whether it's new levels in a game or new styles on a watch face, if you can build it, users can buy it.

Cross-device promotion

What if your watch app doesn't work standalone? Or what if it offers a better user experience when both the watch and phone apps are installed? We've been listening carefully to your feedback, and we've added two new APIs (PlayStoreAvailability and RemoteIntent) to help you navigate users to the Play Store on a paired device so they can more easily install your app. Developers can also open custom URLs on the phone from the watch via the new RemoteIntent API; no phone app or data layer is required.

// Check Play Store is available
int playStoreAvailabilityOnPhone =
    PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());

if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) {
    // To launch a web URL, setData to Uri.parse("https://g.co/wearpreview")
    Intent intent =
        new Intent(Intent.ACTION_VIEW)
            .addCategory(Intent.CATEGORY_BROWSABLE)
            .setData(Uri.parse("market://details?id=com.google.android.wearable.app"));
    // mResultReceiver is optional; it can be null.
    RemoteIntent.startRemoteActivity(this, intent, mResultReceiver);
}
Swipe-to-dismiss is back

Many of you have given us the feedback that the swipe-to-dismiss gesture from Android Wear 1.0 is an intuitive time-saver. We agree, and have reverted back to the previous behavior with this developer preview release. To support swipe-to-dismiss in this release, we've made the following platform and API changes:

  • Activities now automatically support swipe-to-dismiss. Swiping an activity from left to right will result in it being dismissed and the app will navigate down the back stack.
  • New Fragment and View support. Developers can wrap the containing views of a Fragment or Views in general in the new SwipeDismissFrameLayout to implement custom actions such as going down the back stack when the user swipes rather than exiting the activity.
  • Hardware button now maps to "power" instead of "back" which means it can no longer be intercepted by apps.

Additional details are available under the behavior changes section of the Android Wear Preview site.

Compatibility with Android Wear 1.0 apps

Android Wear apps packaged using the legacy embedded app mechanism can now be delivered to Android Wear 2.0 watches. When a user installs a phone app that also contains an embedded Android Wear app, the user will be prompted to install the embedded app via a notification. If they choose not to install the embedded app at that moment, they can find it in the Play Store on Android Wear under a special section called "Apps you've used".

Despite support for the existing mechanism, there are significant benefits for apps that transition to the multi-APK delivery mechanism. Multi-APK allows the app to be searchable in the Play Store on Android Wear, to be eligible for merchandising on the homepage, and to be remotely installed from the web to the watch. As a result, we strongly recommend that developers move to multi-APK.

More additions in Developer Preview 4
  • Action and Navigation Drawers: An enhancement to peeking behavior allows the user to take action without scrolling all the way to the top or bottom of a list. Developers can further fine-tune drawer peeking behavior through new APIs, such as setShouldPeekOnScrollDown for the action drawer.
  • WearableRecyclerView: The curved layout is now opt-in, and with this, the WearableRecyclerView is now a drop-in replacement for RecyclerView.
  • Burn-in protection icon for complications: Complication data providers can now provide icons for use on screens susceptible to burn-in. These burn-in-safe icons are normally the outline of the icon in interactive mode. Previously, watch faces may have chosen not to display the icon at all in ambient mode to prevent screen burn-in.
Feedback welcome!

Thanks for all your terrific feedback on Android Wear 2.0. Check out g.co/wearpreview for the latest builds and documentation, keep the feedback coming by filing bugs or posting in our Android Wear Developers community, and stay tuned for Android Wear Developer Preview 5!

Categories: Programming

Scratch Blocks update: Making it easier to develop coding apps for kids

Google Code Blog - Tue, 12/13/2016 - 19:02

Posted by Champika Fernando, Product Manager, Google, and Kasia Chmielinski, Product Lead, MIT Scratch Team

We want to empower developers to build great creative learning apps for kids. That's why, earlier this year, we announced Scratch Blocks, a free, open-source project created by the MIT Scratch and Google Kids Coding teams. Together, we are building this highly tinkerableand playful block-based programming grammar based on MIT's popular Scratch language and Blockly's architecture. With Scratch Blocks, developers can integrate Scratch-style coding into apps for kids.

Today, we're excited to share our progress in a number of areas:

1. Designing for tinkerability

Research from the MIT Media Lab has highlighted the importance of providing children with opportunities for quick experimentation and rapid cycles of iteration. For example, the Scratch programming environment makes it easy for kids to adjust the code while it's running, as well as try coding blocks by just tapping on them. Since our initial announcement in May, we've focused on supporting this type of tinkerability in the Scratch Blocks project by making it very easy for developers to connect Scratch Blocks directly to the Scratch VM (a related open-source project being developed by MIT). In this model, instead of blocks being converted to a text-based language like JavaScript which is then interpreted, the blocks themselves are the code. The result is a more tinkerable experience for the end-user.

2. Designing for all levels

Computational thinking1 is a valuable skill for everyone. In order to support developers building a wide diversity of coding experiences with Scratch Blocks, we've designed two related block grammars that can be used in a variety of contexts. One grammar uses icon-based blocks that connect horizontally, while the other uses text-based blocks that connect vertically.

We started by developing the horizontal grammar, which is well-suited for beginners of all ages due to its simplicity and limited number of blocks; additionally, this grammar is easier to manipulate on small screens. You can see an example of the horizontal icon-based grammar in Code a Snowflake (an activity in this year's Google Santa Tracker) built by the Google Kids Coding Team. More recently, we've added the vertical grammar, which supports a wider range of complex concepts. The horizontal grammar can also be translated into vertical blocks, making it possible to transition between the grammars. We imagine this will be useful in a number of situations, including designing for multiple screen sizes, or as an element of the app's learning experience.

3. Designing for all devices

We're building Scratch Blocks for a world that is increasingly mobile, where people of all ages will tinker with code in a variety of environments. We've improved the mobile experience in many key areas, both in Scratch Blocks as well as the underlying Blockly project:

  • Redesigned blocks for improved touchability
  • Fast loading of large projects on low-powered devices
  • Optimization of block manipulation and code editing on touch screens
  • Redesigned multi-touch support for a better experience on touch devices

How to get involved

These first six months of Scratch Blocks have been a lot of work - and a ton of fun. To stay up to date on the project, check out our Github project, and learn more on our Developer Page.

[1] Learn more about Computational Thinking

Categories: Programming

Announcing updates to Google’s Internet of Things platform: Android Things and Weave

Android Developers Blog - Tue, 12/13/2016 - 18:32

Posted by Wayne Piekarski, Developer Advocate for IoT

The Internet of Things (IoT) will bring computing to a whole new range of devices. Today we're announcing two important updates to our IoT developer platform to make it faster and easier for you to create these smart, connected products.

We're releasing a Developer Preview of Android Things, a comprehensive way to build IoT products with the power of Android, one of the world's most supported operating systems. Now any Android developer can quickly build a smart device using Android APIs and Google services, while staying highly secure with updates direct from Google. We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK), Google Play Services, and Google Cloud Platform. And in the coming months, we will provide Developer Preview updates to bring you the infrastructure for securely pushing regular OS patches, security fixes, and your own updates, as well as built-in Weave connectivity and more.

There are several turnkey hardware solutions available for you to get started building real products with Android Things today, including Intel Edison, NXP Pico, and Raspberry Pi 3. You can easily scale to large production runs with custom designs of these solutions, while continuing to use the same Board Support Package (BSP) from Google.

We are also updating the Weave platform to make it easier for all types of devices to connect to the cloud and interact with services like the Google Assistant. Device makers like Philips Hue and Samsung SmartThings already use Weave, and several others like Belkin WeMo, LiFX, Honeywell, Wink, TP-Link, and First Alert are implementing it. Weave provides all the cloud infrastructure, so that developers can focus on building their products without investing in cloud services. Weave also includes a Device SDK for supported microcontrollers and a management console. The Weave Device SDK currently supports schemas for light bulbs, smart plugs and switches, and thermostats. In the coming months we will be adding support for additional device types, custom schemas/traits, and a mobile application API for Android and iOS. Finally, we're also working towards merging Weave and Nest Weave to enable all classes of devices to connect with each other in a secure and reliable way. So whether you started with Google Weave or Nest Weave, there is a path forward in the ecosystem.

This is just the beginning of the IoT ecosystem we want to build with you. To get started, check out Google's IoT developer site, or go directly to the Android Things, Weave, and Google Cloud Platform sites for documentation and code samples. You can also join Google's IoT Developers Community on Google+ to get the latest updates and share and discuss ideas with other developers.

Categories: Programming

Announcing updates to Google’s Internet of Things platform: Android Things and Weave

Google Code Blog - Tue, 12/13/2016 - 18:08
Originally posted on Android Developer Blog

Posted by Wayne Piekarski, Developer Advocate for IoT

The Internet of Things (IoT) will bring computing to a whole new range of devices. Today we're announcing two important updates to our IoT developer platform to make it faster and easier for you to create these smart, connected products.

We're releasing a Developer Preview of Android Things, a comprehensive way to build IoT products with the power of Android, one of the world's most supported operating systems. Now any Android developer can quickly build a smart device using Android APIs and Google services, while staying highly secure with updates direct from Google. We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK), Google Play Services, and Google Cloud Platform. And in the coming months, we will provide Developer Preview updates to bring you the infrastructure for securely pushing regular OS patches, security fixes, and your own updates, as well as built-in Weave connectivity and more.

There are several turnkey hardware solutions available for you to get started building real products with Android Things today, including Intel Edison, NXP Pico, and Raspberry Pi 3. You can easily scale to large production runs with custom designs of these solutions, while continuing to use the same Board Support Package (BSP) from Google.

We are also updating the Weave platform to make it easier for all types of devices to connect to the cloud and interact with services like the Google Assistant. Device makers like Philips Hue and Samsung SmartThings already use Weave, and several others like Belkin WeMo, LiFX, Honeywell, Wink, TP-Link, and First Alert are implementing it. Weave provides all the cloud infrastructure, so that developers can focus on building their products without investing in cloud services. Weave also includes a Device SDK for supported microcontrollers and a management console. The Weave Device SDK currently supports schemas for light bulbs, smart plugs and switches, and thermostats. In the coming months we will be adding support for additional device types, custom schemas/traits, and a mobile application API for Android and iOS. Finally, we're also working towards merging Weave and Nest Weave to enable all classes of devices to connect with each other in a secure and reliable way. So whether you started with Google Weave or Nest Weave, there is a path forward in the ecosystem.

This is just the beginning of the IoT ecosystem we want to build with you. To get started, check out Google's IoT developer site, or go directly to the Android Things, Weave, and Google Cloud Platform sites for documentation and code samples. You can also join Google's IoT Developers Community on Google+ to get the latest updates and share and discuss ideas with other developers.

Categories: Programming

A Scalable Alternative to RESTful Communication: Mimicking Google’s Search Autocomplete with a Single MigratoryData Server

This is a guest post by Mihai Rotaru, CTO of MigratoryData.

Using the RESTful HTTP request-response approach can become very inefficient for websites requiring real-time communication. We propose a new approach and exemplify it with a well-known feature that requires real-time communication, and which is included by most websites: search box autocomplete.

Google, which is one of the most demanding web search environments, seems to handle about 40,000 searches per second according to an estimation made by Internet Live Stats. Supposing that for each search, a number of 6 autocomplete requests are made, we show that MigratoryData can handle this load using a single 1U server.

More precisely, we show that a single MigratoryData server running on a 1U machine can handle 240,000 autocomplete requests per second from 1 million concurrent users with a mean round-trip latency of 11.82 milliseconds.

The Current Approach and Its Limitations
Categories: Architecture

A Scalable Alternative to RESTful Communication: Mimicking Google’s Search Autocomplete with a Single MigratoryData Server

This is a guest post by Mihai Rotaru, CTO of MigratoryData.

Using the RESTful HTTP request-response approach can become very inefficient for websites requiring real-time communication. We propose a new approach and exemplify it with a well-known feature that requires real-time communication, and which is included by most websites: search box autocomplete.

Google, which is one of the most demanding web search environments, seems to handle about 40,000 searches per second according to an estimation made by Internet Live Stats. Supposing that for each search, a number of 6 autocomplete requests are made, we show that MigratoryData can handle this load using a single 1U server.

More precisely, we show that a single MigratoryData server running on a 1U machine can handle 240,000 autocomplete requests per second from 1 million concurrent users with a mean round-trip latency of 11.82 milliseconds.

The Current Approach and Its Limitations
Categories: Architecture

Consider Onions or Round Trip for an MVP

I’m teaching a Product Owner workshop this week, and I had an insight about a Minimum Viable Product.

AN MVP has to fulfill these criteria:

  • Minimum means it’s the smallest chunk of value that allows us to build, measure, and learn. (Yes, Eric Ries’ loop)
  • Viable means the actors/users can use it.
  • Product means you can release it, even if to a small, specific group of test users

My insight came when I was discussing with the class how their data moves through their system. Think of data like an onion: there is an inside kernel and concentric rings around the inside. (If you prefer, a cut-down tree, but I like the onion.) Often, you start with that inside and small (round) piece of value. You then add layers around it, every time you do another MVP (or Experiment, if you’re prototyping).

The data has to do a round trip. That’s why I thought of it in circles like an onion. If you only implement half (or some other part) of the entire round trip, you don’t have the entire circle of minimum functionality.

This image on the left, where you see the feature go through the architectural layers might be a better image.

The actions that the user—whomever the user is—has to go into the system and come out. In an MVP, you might not have a very thin slice all by itself, but it still needs to be a thin slice.

When I think about the idea of the onion, I think, “What is the smallest piece I can define so we can see some results?” That’s the idea of the MVP.

I realize that MVPs might be useful for the team to learn about something in a small test environment. And, the smaller chunk of value you deliver, the more experiments you can run, and the faster you can learn. Maybe the idea of the onion, or the round trip through the feature will help you think about your MVPs.

BTW, I still have room in my online Product Ownership workshop that starts in January. Please join us.

Categories: Project Management

How to Reward Agile Teams

Mike Cohn's Blog - Tue, 12/13/2016 - 16:00

I’ve been working with a company to revamp their bonus and incentive structure as part of the organization’s desire to become agile. No matter how well designed and executed an agile transition is, if incentives remain in place that encourage non-agile behavior, that’s how people will behave.

In “Succeeding with Agile,” I referred to this as organizational gravity. Unless enough of an organization’s culture is changed in becoming agile, organizational gravity pulls the organization right back to where it started.

Improperly aligned bonuses and incentives are some of the biggest sources of organizational gravity.

Incentives and Bonuses Are Different

Before looking at how we can create proper bonuses and incentives, let me clarify the difference between a bonus and an incentive.

An incentive is a reward given to an individual or team for achieving a stated goal. An incentive is offered in advance and is meant to motivate behavior in predictable ways. When my youngest daughter was little, I told her that if she cleaned her room by 3:00 p.m., I would take her to see a movie. That was an incentive.

In contrast, a bonus is not stated in advance. Rather it is announced and given at the time something is accomplished. Again using my youngest daughter as an example, when she came home from school with a great grade on a test I knew she’d studied hard for, I told her we’d celebrate that accomplishment by getting ice cream. That was a bonus.

Incentives and bonuses are both rewards with the key difference being that an incentive is announced in advance whereas a bonus is announced on the spot.

Some Troublesome Rewards

Bonuses and incentives can work against the goals of agile. For example, rewards that single out individual performers discourage teamwork. I’ve seen these in the form of “Programmer of the Year,” “Team Member of the Month,” “Most Valuable Contributor” and more.

Other types of rewards encourage suboptimizing behavior. Many of us have stories about testers who were rewarded based on the number of bugs they found. This type of reward led one tester I met to log over 200 entries into the defect tracking system for a single bug.

The bug was simply that a value was being improperly calculated and displayed on the screen. But the product ran on four operating systems (the current and prior versions of WIndows and Mac OS X), eight different browsers (the current and prior versions of four browsers), and was supported in seven different languages. So one bug was reported on Firefox v59 on Windows 8.1 in French. The same bug was reported on Safari 6.2 on MacOS 10.8 in English, and so on.

Bug reports like this wasted everyone’s time. But that tester sure looked productive in the “Bug Finder of the Month” contest.

How About Money?

Financial rewards are almost always a bad idea. Financial rewards are often introduced by a well-meaning boss who wants a team to make a particularly aggressive deadline. The boss will offer an enticing amount to the team if they can deliver by then.

So far, so good. But the problems arise on the next project. On that, the team may start on schedule, but they’ve been trained that if they get a little behind (or perhaps even only if they report themselves as a little behind), the boss will offer a bonus. This becomes a dangerous cycle.

Besides, financial rewards don’t tap into people’s intrinsic motivations. There’s absolutely nothing wrong with money. Most of us wouldn’t show up for work without at least some paycheck. But we’d like to tap into deeper motivations than the purely financial.

The Team That Taught Me About Financial Rewards

I learned a lot from a team many years ago to whom I gave a large financial bonus. This was two teams of 12 developers, and I gave them a bonus of $75,000, which would be more than $6,000 per person … if I split the bonus evenly.

And that was the trouble. I had allocated the bonus in the budget, so I had the money as a pool to give them. But when it came time to decide how I would give it to the team, I couldn’t decide.

Should I:

  • Give the same amount to each person? If I gave each person $6,000, that seemed unfair to those with high salaries and overly generous to others.
  • Give an amount proportionate to each person’s salary? This seemed the opposite.
  • Weigh the amounts by how many months the person had been on the project? It seemed unfair to give the same amount of money to a developer who joined the project a month ago as someone who had worked six months on it.
  • Give to the developers who had worked on this project but had been transferred off? It seemed unfair to leave them out, but if they weren’t there during the hardest period, did they deserve as much?

I couldn’t decide. I went back and forth on this. Some of the key people on the project knew I was planning this bonus and wrestling with this decision. They offered advice. But each person’s suggestions were always very aligned with what would reward them the most.

And so, I gave up.

I told the team I would give them $75,000 but it was their decision how to allocate the bonus.

I told them the issues I’d been struggling with and said that whatever they decided would be fine. But they had to all agree on the process they’d use and the allocation.

A week after I shifted the problem to them, we had a team meeting. They told me they could not find a way to distribute the bonus money. They argued about it. And they felt the money was interfering with the strong bonds they’d built as a team.

And they gave the money back. They decided they didn’t want it.

I don’t think I’d ever been more proud of--or surprised by a team.

We ultimately decided to spend some of the money on a nice out-of-town trip for everyone plus a significant other. The rest was returned to the budget.

And it was the last financial reward I’ve offered a team.

So How Should We Reward an Agile Team?

So how should we reward an agile team? I think the most important consideration is that rewards should encourage teamwork rather than individual performance. I favor rewards (both incentives and bonuses) that are given to everyone on the team.

This doesn’t mean there’s no role for individual rewards. I think those can be fine, but for individual rewards, I prefer to make them smaller, at least in relation to team rewards.

For example, I’ve worked with a few product owners who carry five-dollar bills and give them to team members who could quote the project’s elevator statement or three main goals when asked. No team member’s life was improved by $5. It was more the knowledge that they passed the test when asked. More than one of these team members pinned the $5 to their cubicle wall.

Similarly, a handwritten note can do wonders in this era of constant email deluge. Take the time to write a note every now and then thanking a team member for something special and specific they did.

One of my favorite rewards for a team is time. TIme is something that everyone seems constantly short of. I’ve rewarded a team with time a couple of different ways, which have been consistently well received. For example, you can offer a team an incentive of a week off if they meet some delivery milestone.

Or if a full week off is too much, offer the team a week (or a sprint) where all work is of their own choosing. They can refactor old code the product owner has been resistant to approving if they choose. They can experiment with new technologies. They can catch up on reading if they want. Whatever they choose is fine.

Another option is to give the team knowledge. If they achieve some goal, send everyone to a conference. If appropriate, everyone goes to the same conference. That’s especially good as you can include some fun time before or after. Or, if it’s better, allow each person to pick their own conference to attend some time during the year.

Or give everyone a book budget. (Yes, this is a financial reward, but it’s a little different.) Or a budget for online learning. Perhaps a Safari membership. Or even one of my video courses. But there are plenty of other options.

There is a role for incentives and bonuses on agile teams. But they need to be carefully designed to be consistent with agile’s emphasis on teamwork. But, done well, rewarding team members with incentives and bonuses can benefit the team and the organization.

What Do You Think?

How do you reward teams? Or how would you like to be rewarded as a team?

Quote of the Day

Herding Cats - Glen Alleman - Tue, 12/13/2016 - 15:00

The speach I love is a simple, natural speach the same on paper as in the mouth; a speach succuleant and sinewy, brief and compressed not so much dainty and well-combed as vehement an brusque - Michel de Montaigne The Essays of Montaigne (1580).

Categories: Project Management

Quote of the Month December 2016

From the Editor of Methods & Tools - Mon, 12/12/2016 - 15:48
Experience shows that architecting is not something that’s performed once, early in a project. Rather, architecting is applied over the life of the project; the architecture is grown through the delivery of a series of incremental and iterative deliveries of executable software. At each delivery, the architecture becomes more complete and stable, which raises the […]

SPaMCAST 421 – Vanity Metrics, Unity of Purpose, Leadership

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 421 features our essay on vanity metrics.  Vanity metrics make people feel good, but are less useful for making decisions about the business.  The essay discusses how to recognize vanity metrics and the risks of falling prey to their allure.

We will also have columns form Steve Tendon with another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here). Steve and I talked about Chapter 13.  Finally, Gene Hughson will anchor the cast with an entry from his Form Follows Function Blog.  Gene and I started talking about leadership patterns and anti-patterns.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Three with the sections titled the Last Stand, Flack, Heavy Lifting, and Rally. I suspect we have 3 or 4 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and  go back to week one and read along!

I have not heard any nay sayers on the idea of re-reading Carol Dweck’s Mindset next; however, just be to fair I am going to include a poll at the end to decide between Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I would like your opinion!

Takeaways from this week include:

  • You are responsible for the atmosphere that you create.
  • Leaders and teams bear the consequence of not dealing with bad attitudes.
  • When someone leaves a team everyone will mourn to some extent.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The Software Process and Measurement Cast 422 will feature our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 421 - Vanity Metrics, Unity of Purpose, Leadership

Software Process and Measurement Cast - Sun, 12/11/2016 - 23:00

The Software Process and Measurement Cast 421 features our essay on vanity metrics.  Vanity metrics make people feel good, but are less useful for making decisions about the business.  The essay discusses how to recognize vanity metrics and the risks of falling prey to their allure.

We will also have columns form Steve Tendon with another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here). Steve and I talked about Chapter 13.  Finally, Gene Hughson will anchor the cast with an entry from his Form Follows Function Blog.  Gene and I started talking about leadership patterns and antipatterns.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Three with the sections titled the Last Stand, Flack, Heavy Lifting, and Rally. I suspect we have 3 or 4 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and  go back to week one and read along!

I have not heard any nay sayers on the idea of re-reading Carol Dweck’s Mindset next; however, just be to fair I am going to include a poll at the end to decide between Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I would like your opinion!

Takeaways from this week include:

  • You are responsible for the atmosphere that you create.
  • Leaders and teams bear the consequence of not dealing with bad attitudes.
  • When someone leaves a team everyone will mourn to some extent.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The Software Process and Measurement Cast 422 will feature our interview with Phil Lew.  Phil and I talked about the topic of Agile risk management.  We explored how risk can be managed in Agile projects and the barriers to effective risk management.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Microservices, not so much news after all?

Xebia Blog - Sun, 12/11/2016 - 18:07
A while ago at Xebia we tried to streamline our microservices effort. In a kick-off session, we got quite badly side tracked (as is often the case) by a meta discussion about what would be the appropriate context and process to develop microservices. After an hour of back-and-forth, we reached consensus that might be helpful

Five Dysfunctions of a Team, Patrick Lencioni: Re-Read Week 11

Five Dysfunctions of a Team

Five Dysfunctions of a Team

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we conclude Part Three with the sections titled the Last Stand, Flack, Heavy Lifting, and Rally. I suspect we have 3 or 4 weeks left before moving to the next book, BUT we still have a number of ideas to extract from this book.

If you are new to the re-read series buy a copy and  go back to week one and read along!

I have not heard any nay sayers on the idea of re-reading Carol Dweck’s Mindset next, however just be to fair I am going to include a poll at the end to decide between Mindset, Thinking Fast and Slow (Daniel Kahneman) and Flow (Mihaly Csikszentmihalyi).  I would like your opinion!

Last Stand

Instead of coming to terms with the situation, Mikey refused to resign and threatens a lawsuit if fired. Kathryn’s restated her position was that she didn’t have to quit, but unless she was willing to change (something she probably wasn’t interested in doing) she would have to leave. In chess this is classically known as a fork. The attacker presents his/her opponent with two possible outcomes (let’s say the loss of a queen or a castle) and the opponent gets to decide which position they wish to forfeit. For Kathryn, both options were an acceptable outcome. Note: in real life, if you are using this tactic it is important to ensure that there is not a third option or the outcome will less controlled. In this case, Mikey acquiesces and indicates she will resign if DecisionTech meets her set of demands. Kathryn said she would try to meet those demands even though they were within her purview, keeping Mikey off balance and holding on to the balance of power.Saying yes immediately in this type of negotiations probably isn’t a good idea. Even if you can say yes immediately don’t, let things sink in and then you can say yes. The Last Stand is an excellent primer on the use of power in negotiations.

The Mikey scenario in the book reinforces the idea that it is critical to be socially aware. Every individual will have an impact on a team, for good or for bad.  Regardless of whether someone is individually superlative, if they have to be part of a team it is critical that they support the team’s cultural and behavioral norms.

Flack

In this section Kathryn informs the team that Mikey is gone, and observes that even though Mikey had been a cancer on the team that her resignation is a downer.

Having been part of organizations that have had to shed personnel because they did not fit the team, I can validate Lencioni’s statement that generally no one enjoys the immediate aftermath of someone being fired or being pushed to resign. In the long run, it is often getting rid of someone that is bad for the team is better for the team, for the organization and sometimes even for the individual.

Heavy lifting

While the off-site, the proverbial show had to go on. The group wrestled with the loss of Mikey. Teams often mourn because no one understands how they will be impacted. This again, from my experience, is fairly common.  Kathryn used a story from early in her career to drive home the point that a bad fit can destroy a team and kill careers.  In the story Katheryn promoted a Mikey like person only to have the team fail to deliver, many people quit and Kathryn was fired.  The story made sure everyone in the room knew the consequences of not acting.  More importantly Kathryn used the story as a tool to tell everyone that she had removed the illness in the team to save the whole team.  Kathryn directly states she does not want to lose anyone else, sending a soothing message to those remaining.

Rally

Section three of the book concludes with the Rally.  When Mikey’s departure was announced to the organization there is more concern among the staff than anticipated.  Most of the angst is over tactical issues. The angst that the organization feels is more than offset by less bad behavior between teams and between the members of the “Staff” (remember that is what the executive team was once called when they focused only on day-to-day activities). Overall everyone in the in the organization recognized more unity of purpose.  The real business issues were being sorted out at the top of the organization rather than to be left to wrestle with by people without the power to make decisions.

Three key takeaways:

  1.      You are responsible for the atmosphere that you create.
  2.      Leaders and teams bear the consequence of not dealing with bad attitudes.
  3.      When someone leaves a team everyone will mourn to some extent.

Poll for the next book! Take Our Poll (function(d,c,j){if(!d.getElementById(j)){var pd=d.createElement(c),s;pd.id=j;pd.src='https://s1.wp.com/wp-content/mu-plugins/shortcodes/js/polldaddy-shortcode.js';s=d.getElementsByTagName(c)[0];s.parentNode.insertBefore(pd,s);} else if(typeof jQuery !=='undefined')jQuery(d.body).trigger('pd-script-load');}(document,'script','pd-polldaddy-loader'));

Previous Installments in the re-read of  The Five Dysfunctions of a Team by Patrick Lencioni:

Week 1 – Introduction through Observations

Week 2 – The Staff through the End Run

Week 3 – Drawing the Line though Pushing Back

Week 4 – Entering Danger though Rebound

Week 5 – Awareness through Goals

Week 6 – Deep Tissue through Exhibition

Week 7 – Film Noir through Application

Week 8 – On-site through Fireworks

Week 9 – Leaks through Plowing On

Week 10 – Accountability through The Talk


Categories: Process Management

Stuff The Internet Says On Scalability For December 9th, 2016

Hey, it's HighScalability time:

 

Here's a 1 TB hard drive in 1937. Twenty workers operated the largest vertical letter file in the world. 4000 SqFt. 3000 drawers, 10 feet long. (from @BrianRoemmele)
If you like this sort of Stuff then please support me on Patreon.
  • 98%~ savings in green house gases using Gmail versus local servers; 2x: time spent on-line compared to 5 years ago; 125 million: most hours of video streamed by Netflix in one day; 707.5 trillion: value of trade in one region of Eve Online; $1 billion: YouTube's advertisement pay-out to the music industry; 1 billion: Step Functions predecessor state machines run per week in AWS retail; 15.6 million: jobs added over last 81 months;

  • Quotable Quotes:
    • Gerry Sussman~ in the 80s and 90s, engineers built complex systems by combining simple and well-understood parts. The goal of SICP was to provide the abstraction language for reasoning about such systems...programming today is more like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?
    • @themoah: Last year Black Friday weekend: 800 Windows servers with .NET. This year: 12 Linux servers with Scala/Akka. #HighScalability #Linux #Scala
    • @swardley: If you're panicking over can't find AWS skills / need to go public cloud - STOP! You missed the boat. Focus now on going serverless in 5yrs.
    • @jbeda: Nordstrom is running multitenant Kubernetes cluster with namespace per team. Using RBAC for security.
    • Tim Harford: What Brailsford says is, he is not interested in team harmony. What he wants is goal harmony. He wants everyone to be focused on the same goal. He doesn’t care if they like each other and indeed there are some pretty famous examples of people absolutely hating each other. 
    • @brianhatfield: SUB. MILLISECOND. PAUSE. TIME. ON. AN. 18. GIG. HEAP. (Trying out Go 1.8 beta 1!)
    • haberman: If you can make your system lock-free, it will have a bunch of nice properties: - deadlock-free - obstruction-free (one thread getting scheduled out in the middle of a critical section doesn't block the whole system) - OS-independent, so the same code can run in kernel space or user space, regardless of OS or lack thereof 
    • Neil Gunther: The world of performance is curved, just like the real world, even though we may not always be aware of it. What you see depends on where your window is positioned relative to the rest of the world. Often, the performance world looks flat to people who always tend to work with clocked (i.e., deterministic) systems, e.g., packet networks or deep-space networks.
    • @yoz: I liked Westworld, but if I wanted hours of watching tech debt and no automated QA destroy a virtual world, I’d go back to Linden Lab
    • @adrianco: I think we are seeing the usual evolution to utility services, and new higher order (open source) functionality emerges /cc @swardley
    • Neil Gunther: a buffer is just a queue and queues grow nonlinearly with increasing load. It's queueing that causes the throughput (X) and latency (R) profiles to be nonlinear.
    • Juho Snellman: I think [QUIC] encrypting the L4 headers is a step too far. If these protocols get deployed widely enough (a distinct possibility with standardization), the operational pain will be significant.
    • @Tobarja: "anyone who is doing microservices is spending about 25% of their engineering effort on their platform" @jedberg 
    • @cdixon: 2016 League of Legends finals: 43M viewers 2016 NBA finals: 30.8M viewers 
    • @mikeolson: 7 billion people on earth; 3 billion images shared on social media every day. @setlinger at #StrataHadoop
    • @swardley: When you think about AWS Lambda, AWS Step Functions et al then you need to view this through the lens of automating basic doctrine i.e. not just saying it and codifying in maps and related systems but embedding it everywhere. At scale and at the speed of competition that I expect us to reach then this is going to be essential.
    • Jakob Engblom: hardware accelerators for particular  common expensive tasks seems to be the right way to add performance at the smallest cost in silicon area and power consumption.
    • Joe Duffy: The future for our industry is a massively distributed one, however, where you want simple individual components composed into a larger fabric. In this world, individual nodes are less “precious”, and arguably the correctness of the overall orchestration will become far more important. I do think this points to a more Go-like approach, with a focus on the RPC mechanisms connecting disparate pieces
    • @cmeik: AWS Lambda is cool if you never had to worry about consistency, availability and basically all of the tradeoffs of distributed systems.
    • prions: As a Civil Engineer myself, I feel like people don't realize the amount of underlying stuff that goes into even basic infrastructure projects. There's layers of planning, design, permitting, regulations and bidding involved. It usually takes years to finally get to construction and even then there's a whole host of issues that arise that can delay even a simple project. 
    • Netflix: If you can cache everything in a very efficient way, you can often change the game. 
    • The Attention Merchants: One [school] board in Florida cut a deal to put the McDonald’s logo on its report cards (good grades qualified you for a free Happy Meal). In recent years, many have installed large screens in their hallways that pair school announcements with commercials. “Take your school to the digital age” is the motto of one screen provider: “everyone benefits.” What is perhaps most shocking about the introduction of advertising into public schools is just how uncontroversial and indeed logical it has seemed to those involved.

  • Just how big is Netflix? The story of the tape is told in Another Day in the Life of a Netflix Engineer. Netflix runs way more than 100K EC2 instances and more than 80,000 CPU cores. They use both predictive and reactive autoscaling, aiming for not too much or too little, just the right amount. Of those 100K+ instances they will autoscale up and down 20% of that capacity everyday. More than 50Gbps ELB traffic per region. More than 25Ggps is telemetry data from devices sending back customer experience data. At peak Netflix is responsible over 37% of Internet traffic. The monthly billing file for Netflix is hundreds of megabytes with over 800 million lines of information. There's a hadoop cluster at Amazon whose only purpose is to load Netflix's bill. Netflix considers speed of innovation to be a strategic advantage. About 4K code changes are put into production per day. At peak over 125 million hours of video were streamed in a day. Support for 130 countries was added in one day. That last one is the kicker. Reading about Netflix over all these years you may have got the idea Netflix was over engineered, but going global in one day was what it was all about. Try that if you are racking and stacking. 

  • Oh how I miss stories that began Once upon a time. The start of so many stories these days is The attack sequence begins with a simple phishing scheme. This particular cautionary tale is from Technical Analysis of Pegasus Spyware, a very, almost lovingly, detailed account of the total ownage of the "secure" iPhone. The exploit made use of three zero-day vulnerabilities: CVE-2016-4657: Memory Corruption in WebKit, CVE-2016-4655: Kernel Information Leak, CVE-2016-4656: Kernel Memory corruption leads to Jailbreak. Do not read if you would like to keep your Security Illusion cherry intact. 

  • Composing RPC calls gets harder has the graph of calls and dependencies explodes. Here's how Twitter handles it. Simplify Service Dependencies with Nodes. Here's their library on GitHub. It's basically just a way to setup a dependency graph in code and have all the RPCs executed to the plan. It's interesting how parallel this is to setting up distributed services in the first place. They like it: We have saved thousands of lines of code, improved our test coverage and ended up with code that’s more readable and friendly for newcomers. Also, AWS Step Functions.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...

Categories: Architecture