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!
Software Development Blogs: Programming, Software Testing, Agile Project Management
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!
Hey, it's HighScalability time:
Everything is a network. Map showing the global genetic interaction network of a cell.
If you like this sort of Stuff then please support me on Patreon.
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)...
I saw a blog post about the Top 5 Reasons Your Project Fails recently. They were all good reasons, but those reasons were symptoms, not causes. We seem to always identify the symptoms, but until we fix the cause of failure, those symptoms will return.
The symptomsÂ were:
But these are simply missing practices and processes of the 5 Immutable PrinciplesÂ of project success
So let's look at the symptoms and the principle that could have addressed that symptom
So with the 5 symptoms assigned to the 5 Principles, corrective actions can be put in place to avoid the outcomes.Related articles Want To Learn How To Estimate? Capabilities Based Planning First Then Requirements Risk Management is How Adults Manage Projects Root Cause of Project Failure
At a recent Q&A session I was asked: where could a person get their project risks? I stifled a smart-alecky answer that would have included driving to the grocery store, and decided that the question that was being asked was really: how do I go about recognizing and capturing risks? Perhaps a more boring question, but far more important. If I answered the first question the answer would have been that risks are generated by the interaction of the project with other projects, applications, the business, technology and world (risk categories) â€“ pretty much the existence of a project could be considered a risk magnet. The answer to the second question is that once you have a risk magnet (a project) you will need to ask as many different people as is feasible to recognize the possible risks. The discussion of risk always appropriate, however the typical meeting/events and the types of people to consider in the conversation need to be planned. The discovery process typically follows the requirements/user story discovery process outlined below.
The baseline answer to the question of how can I recognize and capture risks is by involving all of the projects stakeholders in a discussion of potential risks. The process of collaborative discussion will help increase diversity of thought, reducing (but NOT eliminating) the potential number of unknowns â€“ unknowns that could impact the projects ability to deliver value.
Posted by Hoi Lam, Developer Advocate
Today weâ€™re launching the third developer preview of Android Wear 2.0 with a big new addition: Google Play on Android Wear. The Play Store app makes it easy for users to find and install apps directly on the watch, helping developers like you reach more users.
Play Store features
With Play Store for Android Wear, users can browse recommended apps in the home view and search for apps using voice, keyboard, handwriting, and recommended queries, so they can find apps more easily. Users can switch between multiple accounts, be part of alpha and beta tests, and update or uninstall apps in the â€śMy appsâ€ť view on their watch, so they can manage apps more easily. Perhaps the coolest feature: If users want an app on their watch but not on their phone, they can install only the watch app. In fact, in Android Wear 2.0, phone apps are no longer necessary. You can now build and publish watch-only apps for users to discover on Google Play.
Why an on-watch store?
We asked developers like you what you wanted most out of Android Wear, and you told us you wanted to make it easier for users to discover apps. So we ran studies with users to find out where they expected and wanted to discover appsâ€“â€“and they repeatedly looked for and asked for a way to discover apps right on the watch itself. Along with improvements to app discovery on the phone and web, the Play Store on the watch helps users find apps right where they need them.
Publish your apps
To make your apps available on Play Store for Android Wear, just follow these steps. Youâ€™ll need to make sure your Android Wear 2.0 apps set minSdkVersion to 24 or higher, use the runtime permissions model, and are uploaded via multi-APK using the Play Developer Console. If your app supports Android Wear 1.0, the developer guide also covers the use of product flavors in Gradle.
Download the New Android Wear companion app
To set up Developer Preview 3, youâ€™ll need to install a beta version of the Android Wear app on your phone, flash your watch to the latest preview release, and use the phone app to add a Google Account to your watch. These steps are detailed in Download and Test with a Device. If you donâ€™t have a watch to test on, you can use the emulator as well.Other additions in Developer Preview 3 Developer Preview 3 also includes:
NotificationCompat.Action replyAction = new NotificationCompat.Action.Builder(R.drawable.ic_message_white_24dp, "Reply", replyPendingIntent) .addRemoteInput(remoteInput) .extend(new NotificationCompat.Action.WearableExtender() .setHintDisplayActionInline(true)) .build();
Weâ€™ve gotten tons of great feedback from the developer community about Android Wear 2.0â€“â€“thank you! Weâ€™ve decided to continue the preview program into early 2017, at which point the first watches will receive Android Wear 2.0. Please keep the feedback coming by filing bugs or posting in our Android Wear Developers community, and stay tuned for Android Wear Developer Preview 4.
Never attribute to malevolence what is explicable by incompetence. - Robert J Halon
When we hear all the bad things that go Â wrong with projects. The misuse and abuse of data, people, tools, and processes, I get a smile when I remember Halon's quote.
Removing things, changing things, installing new things will not address the root cause of bad management and especially bad project management. Only replacing the people will fix the root cause when they areÂ willfully ignorantÂ of how to do it right.ÂRelated articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
There's a never-ending opportunityÂ to learn how to estimate in the presence of uncertainty. Here's some resources for informing that learning process.Â
When you hear that estimates are a waste (we'd rather be coding), estimates are fiction, we're bad at estimating, and the plethora of other excuses for not learning how to estimate, ask if that person has done the minimal homework to learn how to estimate needed to make decisions in the presence of uncertainty found on all software development projects. Â Don'tÂ need estimates? - the project is de minimisÂ Related articles Want To Learn How To Estimate? How We Make Decisions is as Important as What We Decide. Herding Cats: Where Are We Going, Doesn't Much Matter It Seems Herding Cats: Estimating on Non-Trivial Software Projects Taxonomy of Logical Fallacies
Posted by Arudea Mahartianto, Google AMP Specialist
From conception, the open source Accelerated Mobile Pages Project has had a clear goal --- to make the mobile web experience better and faster for users. This extends beyond content to creating a user-first approach to advertising as well.
To realize this vision, the AMP team created an advertising solution that follows four core principles:
Ads in AMP are delivered using the amp-ad component. Using this component you can configure your ads in a number of ways such as the width, length, layout mode and ad loading strategy. Different ad networks might allow even more options.
Here is an example of an DoubleClick responsive ad implementation in AMP:
The type attribute informs the amp-ad component which ad platform to use. In this case we want DoubleClick and therefore the type value is doubleclick. For above the fold responsive ad implementation please use layout="fixed-height" instead and limit the ad height so users will get a fast loading content-focused experience from the very start.
Any attributes starting with data- in amp-ad are ad platform-specific attributes, including the data-slot attribute in the snippet above. Each ad platform will have different attributes available to configure. For example, compare the above DoubleClick example with another AMP ad example that uses the Rubicon platform:
<amp-ad width=320 height=50
For more amp-ad implementation examples, please check out AMP By Example. You can also check out the amp-ad documentation for the complete list of supported ad networks and their configuration semantics.
The team is also developing newer, better ways to bring the benefits of AMP to the ads ecosystem with initiatives like AMP for Ads and AMP Ad Landing Pages. These solutions will enable advertisers to design creatives and ad landing pages that are more consistent with the AMP experience publishers are bringing to users. We believe this will bring us closer to the goal of making the entire mobile web experience faster and better for everybody.
If you are Uber and you need to store the location data that is sent out every 30 seconds by both driver and rider apps, what do you do? That’s a lot of real-time data that needs to be used in real-time.
Uber’s solution is comprehensive. They built their own system that runs Cassandra on top of Mesos. It’s all explained in a good talk by Abhishek Verma, Software Engineer at Uber: Cassandra on Mesos Across Multiple Datacenters at Uber (slides).
Is this something you should do too? That’s an interesting thought that comes to mind when listening to Abhishek’s talk.
Developers have a lot of difficult choices to make these days. Should we go all in on the cloud? Which one? Isn’t it too expensive? Do we worry about lock-in? Or should we try to have it both ways and craft brew a hybrid architecture? Or should we just do it all ourselves for fear of being cloud shamed by our board for not reaching 50 percent gross margins?
Uber decided to build their own. Or rather they decided to weld together their own system by fusing together two very capable open source components. What was needed was a way to make Cassandra and Mesos work together, and that’s what Uber built.
For Uber the decision is not all that hard. They are very well financed and have access to the top talent and resources needed to create, maintain, and update these kind of complex systems.
Since Uber’s goal is for transportation to have 99.99% availability for everyone, everywhere, it really makes sense to want to be able to control your costs as you scale to infinity and beyond.
But as you listen to the talk you realize the staggering effort that goes into making these kind of systems. Is this really something your average shop can do? No, not really. Keep this in mind if you are one of those cloud deniers who want everyone to build all their own code on top of the barest of bare metals.
Trading money for time is often a good deal. Trading money for skill is often absolutely necessary.
Given Uber’s goal of reliability, where out of 10,000 requests only one can fail, they need to run out of multiple datacenters. Since Cassandra is proven to handle huge loads and works across datacenters, it makes sense as the database choice.
And if you want to make transportation reliable for everyone, everywhere, you need to use your resources efficiently. That’s the idea behind using a datacenter OS like Mesos. By statistically multiplexing services on the same machines you need 30% fewer machines, which saves money. Mesos was chosen because at the time Mesos was the only product proven to work with cluster sizes of 10s of thousands of machines, which was an Uber requirement. Uber does things in the large.
What were some of the more interesting findings?
You can run stateful services in containers. Uber found there was hardly any difference, 5-10% overhead, between running Cassandra on bare metal versus running Cassandra in a container managed by Mesos.
Performance is good: mean read latency: 13 ms and write latency: 25 ms, and P99s look good.
For their largest clusters they are able to support more than a million writes/sec and ~100k reads/sec.
Agility is more important than performance. With this kind of architecture what Uber gets is agility. It’s very easy to create and run workloads across clusters.
Here’s my gloss of the talk:In the Beginning
Risk tolerance can be visualized as a curve. Above theÂ curve represents a combination of high probability and aÂ potential negative impact that will prevent theÂ team fromÂ accepting the risk, and below the curve, the risk isÂ deemed acceptable. Â Outside of a few psychologically damaged individuals, everyone has a risk curve whether they know it or not. On a team, everyoneâ€™s natural risk tolerance differs. Â Complicating the discussion is that risk tolerance changes depending on context the person or team faces. Â For example, at one point in my life riding my bike down a hill at top speed to see if I could slalom stop at the bottom was an acceptable risk. Â I have the scars to prove I was that silly. Thinking back, I am not sure why I am alive today. Â My risk tolerance is different now. While reminiscing about my unsafe days as a seven-year-oldÂ is fun what is more important is to recognize that the same lesson can be seen on teams and in organizations. This leads us to the conclusion that we must talk about risk tolerance. Â
Knowing and being able to predict a team’s risk tolerance is important. Â For example, a few years ago I was asked to assess a team that had operated like clockwork for several years delivering superb value and quality work, however recently their quality had been questionable (their clients were finding significant defects in production). Â There had been no significant personnel changes nor was the type of work that they were doing significantly different. In the end, we determined that someone up the hierarchy had decided to remove quality from the team’s objectives (therefore how raises and promotions would be assessed) and doubled down on making dates and meeting budgets. Â The change had the unintended consequence of changing the team’s risk tolerance curve. Â On the surface at least, taking chances that might impact quality became less risky to the team, therefore more easy to change. Â
Two relatively simple ways to approach a discussion of risk tolerance are:
Both of these approaches represent a mechanism to have an explicit and structured discussion of risk tolerance. Â Both approaches have an advantage over less structured approaches because they generate group knowledge and memory andÂ artifacts that can be used to aid in using the teamâ€™s consensus and as a tool to reinforce that memory. Â
Posted by Nathan Martz, Product Manager, Google VR
With Google Cardboard and Daydream, our Google VR team is working to bring virtual reality to everyone. In addition to making VR more accessible by using the smartphone in your pocket, we recently launched the Google VR SDK out of beta, with native integration for Unity and UE4, to help make it easier for more developers to join the fold.
To further support and encourage new developers to build VR experiences, weâ€™ve partnered with Udacity to create the VR Developer Nanodegree. Students will learn how to create 3D environments, define behaviors, and make VR experiences comfortable, immersive, and performant.
Even with more than 50 million installs of Google Cardboard apps on Google Play, these are still the early days of VR. Students who complete the VR Developer Nanodegree learn by doing, and will graduate having completed a portfolio of VR experiences.
Learn more and sign up to receive VR Developer Nanodegree program updates at https://www.udacity.com/vr
Posted by Jamil Moledina, Google Play, Games Strategic Lead
Last Saturday, we hosted the first Google Play Indie Games Festival in North America, where we showcased 30 amazing games that celebrate the passion, innovation, and art of indies. After a competitive round of voting from fans and on-stage presentations to a jury of industry experts, we recognized seven finalists nominees and three winners.bit bit blocks Presented by Greg Batha Bit Bit Blocks is a cute and action-packed competitive puzzle game. Play with your friends on a single screen, or challenge yourself in single player mode. Head-to-head puzzle play anytime, anywhere. Numbo Jumbo Presented by Kaveh Daryabeygi, Wombo Combo Numbo Jumbo is a casual mobile puzzle number game for iOS and Android. Players group numbers that add together: for example, [3, 5, 8] works because 3+5=8. Orbit - Playing with Gravity Presented by Chetan Surpur & Eric Rahman, Highkey Games ORBIT puts a gravity simulator at the heart of a puzzle game. Launch planets with a flick of your finger, and try to get them into orbit around black holes. ORBIT also features a sandbox where you can create your own universes, control time, and paint with gravity.
Finalists nominees and winners also received a range of prizes, including Google I/O 2017 tickets, a Tango Development kit, Google Cloud credits, an NVIDIA Android TV & K1 tablet, and a Razer Forge TV bundle.
Indie Games Contest coming to Europe
Weâ€™re continuing our effort to help indie game developers thrive by highlighting innovative and fun games for fans around the world. Today, we are announcing the Indie Games Contest for developers based in European countries (specific list of countries coming soon!). This is a great opportunity for indie games developers to win prizes that will help you showcase your art to industry experts and grow your business and your community of players worldwide. Make sure you donâ€™t miss out on hearing the details by signing up here for updates.
As we shared at the festival, itâ€™s rewarding to see how Google Play has evolved over the years. Weâ€™re now reaching over 1 billion users every month and thereâ€™s literally something for everyone. From virtual reality to family indie games, developers like you continue to inspire, provoke, and innovate through beautiful, artistic games.
Posted by Sophie Miller, Tango Business Development
Window shopping and showrooms let us imagine what that couch might look like in our living room or if that stool is the right height, but Tango can help take out the guesswork using augmented reality. Place virtual furniture in your real room, walk around, and try different colors.
Tango-enabled apps like WayfairView make it easy to visualize and rearrange new furniture in your home. We sat down with the Wayfair team to learn more about their app and see how Tango helps power new AR shopping experiences:
Google: Please tell us about your Tango app.
Mike: Wayfair offers a massive selection of products online. We believe that the ability for customers to visualize products in their living space augments our online experience, and solves real customer problems such as: Will this product fit in my space? and Will this match the rest of my environment?
Why are you excited for your customers to start using WayfairView?
One of the biggest barriers that online shopping poses is the inability for a customer to get a good sense of how a product would fit in their room, and what it would look like in their living space. With WayfairView, we aim to help our customers better visualize our products - going above and beyond a flat, 2D image and providing them with an accurate 3D rendering of what the full-size item could look like in their home. Not only is this a great extension of the customer experience, itâ€™s also a practical approach to figure out how the product fits into the userâ€™s space before ordering it.
How did you get started developing for Tango?
I signed up to buy a dev kit in 2014 because he was personally interested in scanning 3D objects and environments. I ended up using it for a hackathon to build the first prototype of what is now WayfairView. One of my teammates, Shrenik Sadalgi, has always been interested in AR technology and had participated in Tango hackathons in years prior. He thought this particular flavor of AR, i.e Markerless in the form factor of a mobile device, had the potential of providing a seamless, easy user experience for Wayfair customers.
Was there something unique to the Tango platform that made it particularly appealing?
AR technology has been around for a while, but Tango is making it accessible by providing the technology in a way that is user friendly. Specifically, the Tango platform excels in accurate tracking, which allowed Wayfairâ€™s R&D team to focus on building a great experience for our customers. No markers, no HMDs, no cords that can get tangled, but still powerful.
What were some of the challenges you faced building for Tango?
The biggest challenge Wayfair faces with AR technology is more about the experience than the device, which is in big part thanks to Tango. Our goal was to introduce an entirely new way of shopping for furniture in a way that is user friendly. Not having to worry about the inner workings of Tango helped us focus on making the furniture look as real as possible, scaling the app with our massive catalog, and getting to market in a short period of time.
What surprised you during the Tango development process?
The learning curve for Tango was minimal. We were able to get started very quickly using example code. It was pretty remarkable how the stability of the platform (primarily the tracking) kept improving over the period of time that we worked on the app.
Which platform did you build your Tango app on, and why?
We wrote the core of the app using Unity in C# - we wanted all the 2D UI to be in native Android to match the Wayfair native Android experience. This also gave us the opportunity to re-use code from the existing Wayfair Android app. We saw significant performance improvements by using native Android to create the 2D UI as well, which also makes the UI easier to update when the next UI theme of Android comes along.
What features can customers look forward to in a future WayfairView update?
We would love to add the ability to search for products by space: imagine drawing a cube in your real space and finding all products that fit the space. We also want to allow users to stack virtual products on top of each other to help them visualize how a virtual table lamp would look on top of a virtual table. Of course, we also want to make the products look even more real and add more products that can be visualized on WayfairView.
How do you think that this will change the way people shop for household goods?
WayfairView makes it easier than ever for customers to visualize online goods in their home at full scale, giving them an extra level of confidence when making an online purchase. We believe Tango has the potential to become a ubiquitous technology, just like smartphone cameras and mobile GPS. Ultimately, we anticipate that this will further accelerate the shift from brick and mortar to online.
We also imagine that WayfairView will be a very useful tool for our designers as they share their design proposal and vision with their customers.
Spotify is looking for individuals passionate in infrastructure to join our Site Reliability Engineering organization. Spotify SREs design, code, and operate tools and systems to reduce the amount of time and effort necessary for our engineers to scale the world’s best music streaming product to 40 million users. We are strong believers in engineering teams taking operational responsibility for their products and work hard to support them in this. We work closely with engineers to advocate sensible, scalable, systems design and share responsibility with them in diagnosing, resolving, and preventing production issues. We are looking for an SRE Engineering Manager in NYC and SREs in Boston and NYC.
IT Security Engineering. At Gusto we are on a mission to create a world where work empowers a better life. As Gusto's IT Security Engineer you'll shape the future of IT security and compliance. We're looking for a strong IT technical lead to manage security audits and write and implement controls. You'll also focus on our employee, network, and endpoint posture. As Gusto's first IT Security Engineer, you will be able to build the security organization with direct impact to protecting PII and ePHI. Read more and apply here.
If any of these items interest you there's a full description of each sponsor below...
Some teams use the sprint review as a time for product owners or key stakeholders to formally approve the product backlog items completed during the sprint. Is this a good idea?
In general, a sprint review should not be used by a team to get formal sign-off on their work from their product owner. The team and product owner should be working so closely during a sprint that the team knows what the product owner thinks of what they’ve built.
No surprises is my No. 1 rule for the sprint review.
It is absolutely acceptable for a product owner to reject the work of a team on a product backlog item. But the team should know that’s coming.
Team members should not walk into a sprint review expecting glowing praise from the product owner but then be blindsided by a litany of complaints about a feature.
But what about acceptance by a client? Can a sprint review be used for formal sign-off or acceptance in those cases?
Ideally, in cases in which a client hires a vendor to develop a product, someone at the the client company would act as the product owner. And in those cases, it can be OK for formal sign-off on features to occur during the sprint review. But I’d still stick with the advice that there should be no surprises during the review.
Even though the client product owner is providing feedback to the team during the sprint, it’s possible that the product owner needs to wait to fully accept something until other stakeholders have a chance to comment on the work.
As a simple example, my daughter recently asked me if she could go on a school trip. I said it was fine with me, but--guess what--we needed to check that it was OK with her mother. That is, my wife might have had plans for our family during that time that I didn’t yet know about.
This will be a common situation for client product owners in contract development situations. The product owner interacting with the team daily may like how a feature has been built, but may need to confirm that the stakeholders he or she represents agree. Sure, we can say that the product owner should simply go ask. But that can be impractical and might best be done in a sprint review.
But in outsourced, contract development, the client doesn’t always provide the product owner. Many times, the client hires the vendor to take care of everything.
The client is, of course, the true product owner. The client will ultimately accept or reject what is developed. But, on a day-to-day basis, the client doesn’t want to be “bothered.” And so the typical solution in this case is for the vendor to appoint a product owner from someone within its own organization.
And in this case, true acceptance (or “sign off”) on product backlog items cannot happen before the sprint review. The true product owner (from the client) is not sufficiently available and engaged to accept things any more frequently.
Sure, the team may have a preliminary sign-off from their own product owner representative during the sprint. But the true, client product owner may completely reverse that decision in the actual sprint review.
So the ultimate answer depends, like so many things, upon the context in which you’re operating. And so I’ll say that I’m not too concerned by actual, formal sign-off occurring during a sprint review. But I always want to stick with a policy of no surprises during the review.
Sign off or not, as needed. But the team should always have a good idea of what’s coming before they get to the review.
What Do You Do?
What does your team do in sprint reviews? Has the product owner largely seen everything before then? Are product backlog items formally accepted during the review? Please share your thoughts in the comments below.
The presentationÂ "Quantifying the Impact of Agile Practices," Larry MacCherone at the RallyOn 2013 Conference, presents some results on estimating impacts. The chart below shows 4 estimating types, including No Estimates, the sample sizes for each type and the components that make up the estimating types.
TheÂ Software Development Performance Index (SDPI)Â scale on the left ranges - by eyeball measurement - from 46 to 55.
The Higher the number theÂ better the performance of the process. The presentation speaks to the components of the index further.
But first another piece of information ...
Teams doing Full Scrum have 250% better Quality than teams doing NoÂ Estimating
But are these differences meaningful statistically?
Let's start with several reading assignments, before answering
Let's start with theÂ numbersÂ from the chart
Since the raw underlying data is not available, we can't do any p-Factor assessment from the population samples, but there is a simple question that can be asked.
Are there any statisticalÂ differences between the 4 SDPI's? If you look below at theÂ quick and dirty assessment of the only data available, it looks like all 4 approachesÂ are within a single digit variancesÂ of each other. Not that useful actually.Â
So the criticalÂ question still remains
How can you make a decision in the presence of uncertaintyÂ without estimatingÂ the impact of that decision?
ÂRelated articles The Actual Science in Management Science Carl Sagan's BS Detector How to Estimate Software Development Statistical Significance Monte Carlo Simulation of Project Performance Managing by (mis)quoting Deming Mr. Franklin's Advice Mike Cohn's Agile Quotes Flaw of Averages
Originally posted on Google Analytics blogPosted by Arudea Mahartianto, Google AMP Specialist
In the digital world, whether youâ€™re writing stories for your loyal readers, creating creative content that your fans love, helping the digital community, or providing items and services for your customer, understanding your audience is at the heart of it all. Key to unlocking that information is access to tools for measuring your audience and understanding their behavior. In addition to making your page load faster, Accelerated Mobile Pages (AMP) provides multiple analytics options without compromising on performance.
You can choose to use a solution like amp-pixel that behaves like a simple tracking pixel. It uses a single URL that allows variable substitutions, so itâ€™s very customizable. See the amp-pixel documentation for more detail.
The amp-analytics component, on the other hand, is a powerful solution that recognizes many types of event triggers to help you collect specific metrics. Since amp-analytics is supported by multiple analytics providers, this means you can use amp-analytics to configure multiple endpoints and data sets. AMP then manages all of the instrumentation to come up with the data specified and shares it with these analytics solution providers.
To use amp-analytics, include the component library in your document's <head>:
<script async custom-element="amp-analytics"
And then include the component as follows (for these examples, make sure to specify your own account number instead of the placeholder):
"title": "Name of the Article"
Expanding the above example, we can add another trigger, clickOnHeader:
"title": "Name of the Article"
For a detailed description of data sets you can request, as well as the complete list of analytics providers supporting amp-analytics, check out the amp-analytics documentation. You can also see more implementation examples in the Amp By Example site.
If you want to conduct a user experience experiment on your AMP pages, such as an A/B test, you can use the amp-experimentelement. Any configurations done in this element will also be exposed to amp-analytics and amp-pixel, so you can easily do a statistical analysis of your experiment.
There are still plenty of ongoing developments for AMP analytics to help you gain insights as you AMPlify the user experience on your site. Visit the AMP Project roadmap to see a summary of what the team is cooking up. If you see some features missing, please file a request on GitHub.
The essence of mathematics is to not make simple things complicated, but to make complicated things simple - Stan GudderÂ
This notion that estimating is hard, estimates are a waste because they are always wrong, willfully ignores the basic mathematics of making decisions of in presence of uncertainty. The foundation of all decision-making, Probability and Statistics. Without this understanding there can be no credible information provided to the decision makers.Â