Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

Flaky Tests at Google and How We Mitigate Them

Google Testing Blog - Sat, 05/28/2016 - 01:34
by John Micco

At Google, we run a very large corpus of tests continuously to validate our code submissions. Everyone from developers to project managers rely on the results of these tests to make decisions about whether the system is ready for deployment or whether code changes are OK to submit. Productivity for developers at Google relies on the ability of the tests to find real problems with the code being changed or developed in a timely and reliable fashion.

Tests are run before submission (pre-submit testing) which gates submission and verifies that changes are acceptable, and again after submission (post-submit testing) to decide whether the project is ready to be released. In both cases, all of the tests for a particular project must report a passing result before submitting code or releasing a project.

Unfortunately, across our entire corpus of tests, we see a continual rate of about 1.5% of all test runs reporting a "flaky" result. We define a "flaky" test result as a test that exhibits both a passing and a failing result with the same code. There are many root causes why tests return flaky results, including concurrency, relying on non-deterministic or undefined behaviors, flaky third party code, infrastructure problems, etc. We have invested a lot of effort in removing flakiness from tests, but overall the insertion rate is about the same as the fix rate, meaning we are stuck with a certain rate of tests that provide value, but occasionally produce a flaky result. Almost 16% of our tests have some level of flakiness associated with them! This is a staggering number; it means that more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests.

When doing post-submit testing, our Continuous Integration (CI) system identifies when a passing test transitions to failing, so that we can investigate the code submission that caused the failure. What we find in practice is that about 84% of the transitions we observe from pass to fail involve a flaky test! This causes extra repetitive work to determine whether a new failure is a flaky result or a legitimate failure. It is quite common to ignore legitimate failures in flaky tests due to the high number of false-positives. At the very least, build monitors typically wait for additional CI cycles to run this test again to determine whether or not the test has been broken by a submission adding to the delay of identifying real problems and increasing the pool of changes that could contribute.

In addition to the cost of build monitoring, consider that the average project contains 1000 or so individual tests. To release a project, we require that all these tests pass with the latest code changes. If 1.5% of test results are flaky, 15 tests will likely fail, requiring expensive investigation by a build cop or developer. In some cases, developers dismiss a failing result as flaky only to later realize that it was a legitimate failure caused by the code. It is human nature to ignore alarms when there is a history of false signals coming from a system. For example, see this article about airline pilots ignoring an alarm on 737s. The same phenomenon occurs with pre-submit testing. The same 15 or so failing tests block submission and introduce costly delays into the core development process. Ignoring legitimate failures at this stage results in the submission of broken code.

We have several mitigation strategies for flaky tests during presubmit testing, including the ability to re-run only failing tests, and an option to re-run tests automatically when they fail. We even have a way to denote a test as flaky - causing it to report a failure only if it fails 3 times in a row. This reduces false positives, but encourages developers to ignore flakiness in their own tests unless their tests start failing 3 times in a row, which is hardly a perfect solution.
Imagine a 15 minute integration test marked as flaky that is broken by my code submission. The breakage will not be discovered until 3 executions of the test complete, or 45 minutes, after which it will need to be determined if the test is broken (and needs to be fixed) or if the test just flaked three times in a row.

Other mitigation strategies include:
  • A tool that monitors the flakiness of tests and if the flakiness is too high, it automatically quarantines the test. Quarantining removes the test from the critical path and files a bug for developers to reduce the flakiness. This prevents it from becoming a problem for developers, but could easily mask a real race condition or some other bug in the code being tested.
  • Another tool detects changes in the flakiness level of tests and works to identify the change that caused the test to change the level of flakiness.

In summary, test flakiness is an important problem, and Google is continuing to invest in detecting, mitigating, tracking, and fixing test flakiness throughout our code base. For example:
  • We have a new team dedicated to providing accurate and timely information about test flakiness to help developers and build monitors so that they know whether they are being harmed by test flakiness.
  • As we analyze the data from flaky test executions, we are seeing promising correlations with features that should enable us to identify a flaky result accurately without re-running the test.


By continually advancing the state of the art for teams at Google, we aim to remove the friction caused by test flakiness from the core developer workflows.

Categories: Testing & QA

The Fallacy of Beneficial Ignorance

Herding Cats - Glen Alleman - Sat, 05/28/2016 - 01:01

The basis of #Noestimates is that decisions can be made in the presence of uncertainty without having to estimate the impact of those decisions

No Estimates

Here's a research paper that hopefully will put an end to the nonsensical idea of #NoEstimates.

All project work is uncertain. And has been stated here endless times, uncertainty comes in two forms - Reducible (Epistemic) and Irreducible (Aleatory).

Add to that the biases found on all projects - confirmation and optimism are two we encounter all the time. The conjecture - and it is pure conjecture- that decisions can be made when spending other people's money in the presence of uncertainty without estimating the consequences of those decisions is not only conjecture, it's factually false - a Fallacy.

Here's the paper at SSRN. You'll need to create a free account. This version is the pre-publication version, but it's the same paper I downloaded from my account. Read the paper, discover how to reject the notion of #NoEstimates, not only by its ignorance of managerial finance, probabilistic decision making, business governance violations, but foundational mathematics.

So time to learn why estimates are needed to make decisions in the presence of uncertanty, how to make those estimates, and start behaving as adults in the presence of the risk created by this uncertainty as Tim Lister tells us Risk Management is how Adults Manage Projects.

Screen Shot 2016-05-27 at 5.50.13 PM

Related articles What's the Smell of Dysfunction? Making Decisions in the Presence of Uncertainty Making Choices in the Absence of Information Making Conjectures Without Testable Outcomes Estimating and Making Decisions in Presence of Uncertainty Making Decisions In The Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Bringing virtual cats to your world with Project Tango

Google Code Blog - Fri, 05/27/2016 - 23:44

Posted by Jason Guo, Developer Programs Engineer, Project Tango

Project Tango brings augmented reality (AR) experiences to life. From the practical to the whimsical, Project Tango apps help place virtual objects -- anything from new living room furniture to a full-sized dinosaur -- into your physical world.

Last month we showed you how to quickly and easily make a simple solar system in AR. But if you are ready for something more advanced, the tutorial below describes how to use Project Tango’s depth APIs to associate virtual objects with real world objects. It also shows you how to use a Tango Support Library function to find the planar surface in an environment.

So what’s our new tutorial project? We figured that since cats rule the Internet, we’d place a virtual cat in AR! The developer experience is designed to be simple -- when you tap on the screen, the app creates a virtual cat based on real-world geometry. You then use the depth camera to locate the surface you tapped on, and register (place) the cat in the right 3D position.

Bring on the cats!

Before you start, you’ll need to download the Project Tango Unity SDK. Then you can follow the steps below to create your own cats.

Step 1: Create a new Unity project and import the Tango SDK package into the project.

Step 2: Create a new scene. If you don’t know how to do this, look back at the solar system tutorial. Just like the solar system project, you’ll use the Tango Manager and Tango AR Camera in the scene and remove the default Main Camera gameobject. After doing this, you should see the scene hierarchy like this:

Step 3: Build and run once, making sure sure the application shows the video feed from Tango’s camera.

Step 4: Enable the Depth checkbox on the Tango Manager gameobject.

Step 5: Drag and drop the Tango Point Cloud prefab to the scene from the TangoPrefab folder.

Tango Point Cloud includes a bunch of useful functions related to point cloud, including finding the floor, transforming pointcloud to unity global space, and rendering debug points. In this case, you’ll use the FindPlane function to find a plane based on the touch event.

Step 6: Create a UI Controller gameobject in the scene. To do this, click the ‚ÄúCreate‚ÄĚ button under the Hierarchy tab, then click ‚ÄúCreate Empty.‚ÄĚ The UI Controller will be the hosting gameobject to run your UIController.cs script (which you‚Äôll create in the next step).

Step 7: Click on ‚ÄúUIController gameobject‚ÄĚ in the inspector window, then click ‚ÄúAdd Component‚ÄĚ to add a C# script named KittyUIController.cs. KittyUIController.cs will handle the touch event, call the FindPlane function, and place your kitty into the scene.

Step 8: Double click on the KittyUIController.cs file and replace the script with the following code

using UnityEngine;
using System.Collections;

public class KittyUIController : MonoBehaviour
{
public GameObject m_kitten;
private TangoPointCloud m_pointCloud;

void Start()
{
m_pointCloud = FindObjectOfType();
}

void Update ()
{
if (Input.touchCount == 1)
{
// Trigger place kitten function when single touch ended.
Touch t = Input.GetTouch(0);
if (t.phase == TouchPhase.Ended)
{
PlaceKitten(t.position);
}
}
}

void PlaceKitten(Vector2 touchPosition)
{
// Find the plane.
Camera cam = Camera.main;
Vector3 planeCenter;
Plane plane;
if (!m_pointCloud.FindPlane(cam, touchPosition, out planeCenter, out plane))
{
Debug.Log("cannot find plane.");
return;
}

// Place kitten on the surface, and make it always face the camera.
if (Vector3.Angle(plane.normal, Vector3.up) < 30.0f)
{
Vector3 up = plane.normal;
Vector3 right = Vector3.Cross(plane.normal, cam.transform.forward).normalized;
Vector3 forward = Vector3.Cross(right, plane.normal).normalized;
Instantiate(m_kitten, planeCenter, Quaternion.LookRotation(forward, up));
}
else
{
Debug.Log("surface is too steep for kitten to stand on.");
}
}
}
Notes on the code
Here are some notes on the code above:
  • m_kitten is a reference to the Kitten gameobject (we‚Äôll add the model in the following steps)
  • m_pointCloud is a reference to the TangoPointCloud script on the Tango Point Cloud gameobject. We need this reference to call the FindPlane method on it
  • We assign the m_pointcloud reference in the Start() function
  • We check the touch count and its state in the Update() function when the single touch has ended
  • We invoke the PlaceKitten(Vector2 touchPosition) function to place the cat into 3D space. It queries the main camera‚Äôs location (in this case, the AR camera), then calls the FindPlane function based on the camera‚Äôs position and touch position. FindPlane returns an estimated plane from the touch point, then places the cat on a plane if it‚Äôs not too steep. As a note, the FindPlane function is provided in the Tango Support Library. You can visit TangoSDK/TangoSupport/Scripts/TangoSupport.cs to see all of its functionalities.
Step 9: Put everything together by downloading the kitty.unitypackage, which includes a cat model with some simple animations. Double click on the package to import it into your project. In the project folder you will find a Kitty prefab, which you can drag and drop to the Kitten field on the KittyUIController.
Step 10:
Compile and run the application again. You should able to tap the screen and place kittens everywhere!We hope you enjoyed this tutorial combining the joy of cats with the magic of AR. Stay tuned to this blog for more AR updates and tutorials!

A final note on this tutorial
So you’ve just created virtual cats that live in AR. That’s great, but from a coding perspective, you’ll need to follow some additional steps to make a truly performant AR application. Check out our Unity example code on Github (especially the Augmented Reality example) to learn more about building a good AR application. Also, if you need a refresher, check out this talk from I/O around building 6DOF games with Project Tango.
Categories: Programming

Learn about building for Google Maps over Coffee with Ankur Kotwal

Google Code Blog - Fri, 05/27/2016 - 21:59

Posted by Laurence Moroney, Developer Advocate

If you’ve ever used any of the Google Maps or Geo APIs, you’ll likely have watched a video, read a doc, or explored some code written by Ankur Kotwal. We sat down with him to discuss his experience with these APIs, from the past, to the present and through to the future. We discuss how to get started in building mapping apps, and how to consume many of Google’s web services that support them.

We also discuss the Santa Tracker application, that Ankur was instrumental in delivering, including some fun behind the scenes stories of the hardes project manager he’s ever worked with!

Categories: Programming

Estimating on Agile Projects

Herding Cats - Glen Alleman - Fri, 05/27/2016 - 03:39

Here's a straightforward approach to estimating on agile projects. This is an example of the estimating profession found on many domains. 

Categories: Project Management

3 Requirements For Using Storytelling To Generate The Big Picture

A story helps you see the big picture

A story helps you see the big picture

At one point in my career, I gathered requirements on an almost¬†daily basis.¬† I got good at interviewing people to help them discover what they wanted a project to deliver.¬† In most cases I collected all sorts of ‚Äúshalls,‚ÄĚ ‚Äúmusts,‚ÄĚ ‚Äúwills‚ÄĚ and an occasional ‚Äúshould.‚ÄĚ The organization I worked for¬†detailed¬†the outcome of the process in a requirements document that included¬†technical, non-functional and functional requirements.¬† All of the requirements toed the line defined in IEEE standards. Once we had requirements, my teams would leap into action writing, coding and testing to their hearts content. Looking back the problem was that the cocktail napkin or cost-benefit analysis that spawned this orgy of action often did not capture the nuances of the business outcome. The failure to anchor the nuances of the business outcome in everyone‚Äôs mind meant that despite carefully crafted charters, projects were apt to wander off track. This caused all sorts of stress when they were winding down to done.¬† One solution to this problem is to have the sponsors, stakeholders and team capture an outcome-based big picture.¬† Storytelling as a tool to anchor an idea is not new. If you need proof that storytelling is part of human nature consider that some of the oldest human artifacts, the Lascaux Cave paintings reflect the history (story) of people from approximately 15,000 B.C. Stories help us remember and they help us connect.¬† In the workplace, the big picture acts both as an anchor for the team and as a container to shape or guide the outcome.¬† Effective storytelling to guide work requires the right participation, proper timing, and a process.

People are an important component. Building a narrative for the outcome that a piece of work wants to deliver is not a solitary endeavor.¬† Identify a cross-functional team of impacted subject matter experts, product owners, product managers and team members.¬† Keep the group to 5 ‚Äď 9 people.¬† In scenarios that involve larger groups, I typically suggest developing the story using a cascading hierarchy of smaller groups beginning with a group of the most visionary and then spreading out to more tactical groups (from a senior executive level to more of department level). As with any endeavor, size and degree of difficulty are positively correlated.

Timing matters!  In order to get the most benefit out constructing a big picture narrative story for a project or piece work, construct the story before teams begin building functionality.  For example, in Scrum before the development of functionality means before sprint one.  In SAFe, the big picture narrative needs to exist before planning for a PI occurs. This should be before a building or at least prioritizing the backlog that will drive the work.  That said, developing a big picture narrative for a piece of work is a very powerful tool to generate alignment.

The third requirement for using storytelling in the business environment is a process.  We will explore the process in detail in the next installment however the process outline is: 

  • Identity¬†participants and set a workshop date.¬† The story session is not an ad hoc meeting between a random group of participants.
  • Assign pre-work to set the context and to gather information so that the session is not focused on educating participants. When introducing a new group to generating a big picture narrative I always have them review story structures and story uses before the session.
  • Hold the story meeting (until the next installment visualizes a cloud that says a miracle happens here). The story session typically includes an iterative process of information sharing, story development, and consensus generation.¬†¬†
  • Communicate the consensus narrative to the organization and the whole team.¬† Use the narrative as a tool to identify features, epics, user stories, and the effort‚Äôs minimum viable product.¬†

Storytelling in the business environment is useful.  While the concept of storytelling is not new, it is definitely chic.  It can be tempting to wing it when it comes to generating a big picture narrative, but you will end up with a better result if you spend the time and effort to identify the right people, get them to prepare and then use a standard process.


Categories: Process Management

Setting up AWS CloudFront for Magento

Agile Testing - Grig Gheorghiu - Thu, 05/26/2016 - 19:00
Here are some steps I jotted down for setting up AWS CloudFront as a CDN for the 3 asset directories that are used by Magento installations. I am assuming your Magento application servers are behind an ELB.


SSL certificate upload to AWS
Install aws command line utilities.
$ pip install awscli
Configure AWS credentials
Create IAM user and associate it with the IAMFullAccess policy. Run ‚Äėaws configure‚Äô and specify the user‚Äôs keys and the region.

Bring SSL key, certificate and intermediate certificate in current directory:
-rw-r--r-- 1 root root 4795 Apr 11 20:34 gd_bundle-g2-g1.crt-rw-r--r-- 1 root root 1830 Apr 11 20:34 wildcard.mydomain.com.crt-rw------- 1 root root 1675 Apr 11 20:34 wildcard.mydomain.com.key
Run following script for installing wildcard SSL certificate to be used in staging CloudFront setup:
$ cat add_ssl_cert_to_iam_for_prod_cloudfront.sh#!/bin/bash
aws iam upload-server-certificate --server-certificate-name WILDCARD_MYDOMAIN_COM_FOR_PROD_CF --certificate-body file://wildcard.mydomain.com.crt --private-key file://wildcard.mydomain.com.key --certificate-chain file://gd_bundle-g2-g1.crt --path /cloudfront/prod/

After uploading the SSL certificates, they will be available in drop-downs when configuring CloudFront for SSL.
Apache Cache-Control headers setup
  • Add these directives (modifying max-age accordingly) in all Apache vhosts, both for port 80 and for port 443
 <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">        Header set Cache-Control "max-age=604800, public" </FilesMatch>
CloudFront setup
  • Origin: prod ELB (mydomain-production-lb-9321962155.us-west-2.elb.amazonaws.com)
  • Alternate domain name: cdn.mydomain.com\
  • SSL certificate: ID_OF_CERTIFICATE_UPLOADED_ABOVE
  • Custom SSL client support: Only Clients that Support Server Name Indication (SNI)
  • Domain name: eg7ac9k0fa3qwc.cloudfront.net
  • Behaviors
    • /media/* /skin/* /js/*
    • Viewer protocol policy: HTTP and HTTPS
    • Allowed HTTP methods: GET, HEAD
    • Forward headers: None
    • Object caching: Use origin cache headers
    • Forward cookies: None
    • Forward query strings: Yes
    • Smooth streaming: No
    • Restrict viewer access: No
    • Compress objects automatically: No

DNS setup
  • cdn.mydomain.com is a CNAME pointing to the CloudFront domain name above eg7ac9k0fa3qwc.cloudfront.net

Magento setup
This depends on the version of Magento you are running (1.x or 2.x), but you want to look for settings for the Base Skin URL, Base Media URL and Base Javascript URL, which are usually under System->Configuration->General-Web. You need to set them to point to the domain name you set up as a CNAME to CloudFront.

Base Skin URL: http://cdn.mydomain.com/skin
Base Media URL: http://cdn.mydomain.com/media
Base Javascript URL: http://cdn.mydomain.com/js
More in-depth Magento-specific instructions for integrating with CloudFront are available here.

7 Agile Practices You Can Apply in a Controlled Environment

Xebia Blog - Thu, 05/26/2016 - 11:25
So your teams want to do Agile, perhaps have even started doing so. Now your project managers run around wondering what story points are and why any number of people seem to be attributing hours to their project code. So the question is: what can you adopt easily without turning the Governance of your organisation

Android Studio 2.2 Preview - New UI Designer & Constraint Layout

Android Developers Blog - Thu, 05/26/2016 - 00:50
By Jamal Eason, Product Manager, Android

This week at Google I/O 2016 we launched Android Studio 2.2 Preview. This release is a large update that builds upon our focus to create a fast and productive integrated development environment (IDE) for Android. Developed in sync with the Android platform, Android Studio allows you to develop with the latest Android APIs and features. Since launching Android Studio at Google I/O just 3 years ago, we received great feedback from on you on what features you want the most. Today 92% of the top 125 apps & game developers on Google Play, plus millions of developers worldwide, use Android Studio. We want to continue to build features that will continue to make you more efficient when developing for Android and more productive.
Android Studio 2.2 Preview includes a portfolio of new features along the spectrum of developments, ranging from designing user interfaces to building and debugging your app in new ways. This preview includes the following new categories of features:
Design 
  • Layout Editor: A new user interface designer that helps you visually design the layouts in your app. Features like blueprint mode and the new properties panel allow you to quickly edit layouts and widgets faster.
  • Constraint Layout: A new powerful and flexible Android layout that allows you to express complex UIs without nesting multiple layouts. 
  • Layout Inspector: Debug a snapshot of your app layout running on the Android Emulator or device. Inspect the view hierarchy and corresponding attributes.

Develop
  • Firebase Plugin: Explore and integrate the suite of services offered by Firebase inside of Android Studio. Adding services like Analytics, Authentication, Notifications, and AdMob are just a few clicks away.
  • Enhanced Code Analysis: Android Studio checks the quality of your Android app code. In addition to 260 Android lint and code inspections, this release includes new code quality checks for Java 8 language usage and a new inspection infrastructure for more cross-file analysis.
  • Samples Browser: Referencing Android sample code is now even easier. Within the code editor window, find occurrences of your app code snippets in Google Android sample code to help jump start your app development.
  • Improved C++ Support: Android Studio 2.2 improves C++ development with the ability to edit, build, and debug pre-existing Android projects that use ndk-build or CMake rather than Gradle. Additionally, the existing lldb C++ debugger is now even better with project type auto-detection and a Java language aware C++ mode that lets you use a single debugger process to inspect both Java language and C++ runtimes.
  • IntelliJ 2016.1: Android Studio 2.2 includes all the latest updates from the underlying JetBrains product platforms IntelliJ.

Build
  • Jack Compiler Improvements: For those using the new Jack compiler, Android Studio 2.2 adds support for annotation processing, as well as incremental builds for reduced build times.
  • Merged Manifest Viewer: Diagnose how your AndroidManifest.xml merges with your app dependences across your project build variants. 

Test
  • Espresso Test Recorder: Record Espresso UI tests simply by using your app as a normal user. As you click through your app UI, reusable and editable test code is then generated for you. You can run the generated tests locally, in your Continuous Integration environment, or in Firebase Test lab
  • APK Analyzer: Drill into your APK to help you reduce your APK size, debug 64K method limit issues, view contents of Dex files and more.


Google I/O ‚Äė16: What‚Äôs New in Android Development Tools

Deeper Dive into the New Features  Design
  • Layout Editor: Android Studio 2.2 features a new user interface designer. There are many enhancements but some of the highlights include: 
    • Drag-and-drop widgets from the palette to the design surface or the component tree view of your app.
    • Design surface has a blueprint mode to inspect the spacing and arrangement of your layout. 
    • Properties panel now shows a curated set of properties for quick widget edits with a full sheet of advanced properties one click away.
    • UI builder can edit menu and system preference files. 
The new Layout Editor in Android Studio 2.2 Preview Edit Menus in the new Layout Editor
  • Constraint Layout: This new layout is a flexible layout manager for your app that allows you to create dynamic user interfaces without nesting multiple layouts. It is distributed as a support library that is tightly coupled with Android Studio and backwards compatible to API Level 9. 
At first glance, Constraint Layout is similar to RelativeLayout. However, the Constraint Layout was designed to be used in Studio and it can efficiently express your app design so that you rely on fewer layouts like LinearLayout, FrameLayout, TableLayout, or GridLayout. Lastly, with the built-in automatic constraints inference engine. You can freely design your UI to your liking and let Android Studio do the hard work.

To help you get started, the built-in templates in the New Project Wizard in Android Studio 2.2 Preview now generate  a Constraint Layout. Alternately, you can right click on any layout in the new Layout Editor and select the Convert to ConstraintLayout option.

This is an early preview of the UI designer and Constraint Layout, and we will rapidly add enchantments in upcoming releases. Learn more on the Android Studio tools site.


    Constraint Layout

    Start Layout Inspector
    • Layout Inspector: For new and existing layouts, many times you may want to debug your app UI to determine if your layout is rendering as expected. With the new Layout Inspector, you can drill into the view hierarchy of your app and analyze the attributes of each component of UI on the screen. 
    To use the tool, just click on Layout Inspector Icon in the Android Monitor Window, and then Android Studio creates a snapshot of the current view hierarchy of your app for you to inspect.
    Layout Inspector
    Develop
    • Firebase Plugin: Firebase is the new suite of developers services that can help you develop high-quality apps, grow your user base, and earn more money. Inside of Android Studio, you can add Firebase to a new or existing Android app with the new Assistant window. To access the Firebase features click on the Tools menu and then select Firebase. You will want to first setup the brand new Firebase Analytics as the foundation as you explore other Firebase services like Firebase Cloud Messaging or Firease Crash Reporting to add your application. Learn more about the Firebase integration inside Android Studio here.


    Firebase Plugin for Android Studio
    • Code Sample Browser: In addition to importing Android Samples, the Code Sample Browser is a menu option inside Android Studio 2.2 Preview that allows you to find high-quality, Google-provided Android code samples based on the currently highlighted symbol in your project. To use the feature, highlight a Variables, Types and Methods in your code then Right Click to show a context menu for Find Sample Code. The results are displayed in a bottom output box.   
    Code Sample Browser Build
    • CMake and NDK-Build: For those of you using the Android NDK, Android Studio now supports building CMake and NDK-Build Android app projects by pointing Gradle at your existing build files. Once you‚Äôve added your cmake or ndk-build project to Gradle, Android Studio will automatically open your relevant Android code files for editing and debugging in Studio.

    For CMake users, just add the path to your CMList.txt file in the externalNativeBuild section of your Gradle file: CMake Build in Android Studio
    For NDK-Build Users, just add the path to your *.mk file in the section of your Gradle file: NDK-Build in Android Studio
    • Improved Jack Tools: The new Jack Toolchain compiles your Java language source into Android dex bytecode. The Jack compiler allows some Java 8 language features, like lambdas, to be used on all versions of Android. This release adds incremental build and full support for annotation processing, so you can explore using Java 8 language features in your existing projects.
    To use incremental build with Jack add the following to your build.gradle file:

    Enable Jack Incremental Compile Option
    Jack will automatically apply annotations processors in your classpath. To use an annotation processor at compile-time without bundling it in your apk, use the new annotationProcessor dependency scope:
    Enable Jack Annotation Processing
    • Merged Manifest Viewer: Figuring out how your AndroidManifest merges with your project dependencies based on build types, flavors and variants is now easier with Android Studio. Navigate to your AndroidManifest.xml and click on the new Merged Manifest bottom tab. Explore how each node of your AndroidManifest resolves with various project dependencies.  
    Merged Manifest Viewer Test

    • Espresso Test Recorder: Sometimes writing UI tests can be tedious. With the Record Espresso UI tests feature, creating tests is now as easy as just using your app. Android Studio will capture all your UI interactions  and convert them into a fully reusable Espresso Test that you can run locally or even on Firebase Test lab. To use the recorder, go to the Run menu and select Record Espresso Test.

    Espresso Test Recorder
    • APK Analyzer: The new APK Analyzer helps you understand the contents and the sizes of different components in your APK. You can also use it to avoid 64K referenced method limit issues with your Dex files, diagnose ProGuard configuration issues, view merged AndroidManifest.xml file, and inspect the compiled resources file (resources.arsc). This can help you reduce your APK size and ensure your APK contains exactly the things you expect.
    The APK Analyzer shows you both the raw file size as well as the download size of various components in your APK. The download size is the estimated size users need to download when the APK is served from Google Play. This information should help you prioritize where to focus in your size reduction efforts.
    To use this new feature, click on the Build menu and select Analyze APK… Then, select any APK that you want to analyze.

    APK Analyzer
    • Java-aware C++ Debugger:  When debugging C++ code on targets running N and above, you can now use a single, Java language aware lldb instance. This debugger continues to support great lldb features like fast steps and memory watchpoints while also allowing you to stop on Java language breakpoints and view your Java language memory contents.

    • Auto Debugger Selection: Android Studio apps can now use debugger type ‚ÄúAuto.‚ÄĚ This will automatically enable the appropriate debugger -- the Java language aware C++ debugger if enabled and otherwise the hybrid debugger for C++ projects.  Projects exclusively using the Java language will continue to use the Java language debugger.

    Enable Auto Debugger for C++ What's Next  Download

    If you are using a previous version of Android Studio, you can check for updates on the Canary channel from the navigation menu (Help ‚Üí Check for Update [Windows/Linux] , Android Studio ‚Üí Check for Updates [OS X]). This update will download a new version, and not patch your existing copy of Android Studio. You can also download Android Studio 2.2 Preview from canary release site.

    For the Android Studio 2.2 Preview, we recommend you run a stable version alongside the new canary. Check out the tools site on how to run two versions at the same time.

    We appreciate any feedback on things you like, issues or features you would like to see. Connect with us -- the Android Studio development team -- on our Google+ page or on Twitter
    Categories: Programming

    How to Make a Decision in the Presence of Uncertainty

    Herding Cats - Glen Alleman - Wed, 05/25/2016 - 23:28

    Uncertainty is all around us. In the project world, uncertanty comes in two forms:

    1. Aleatory Uncertainty - the naturally occurring variances due to the underlying statistical processes of the project. These can be schedule variances, cost variances, and technical variances - all driven by a stochastic process with a known or unknown statistical distribution. If you don't know what the distribution is, the Triangle Distribution is a good place to start. For example: The statistical processes of testing our code ranges from 2 to 4 days for a full cyber security scan. Planning on a specific duration has to consider this range and provide the needed margin. Aleatory uncertainty is irreducible. Only margin can protect the project from this uncertainty.
    2. Epistemic Uncertainty - the probability that something will happen in the future. The something we're interested in is usually unfavorable. For example: The probability that the server capacity we have selected will not meet the demands of the user when we go live. Epistemic uncertainty, being probabilistic, can be addressed with redundancy, extra capacity, experiments, surge capacity and other direction actions to buy down the risk that results from this uncertanty before the risk turns into an issue.

    When we hear you can make decisions without estimates, this is physically not possible if you accept the fundamental principle that uncertanty is present on all projects. If there is no uncertanty - no aleatory or epistemic uncertainties - then there will be no probabilistic or statistical processes driving the project's outcomes. If that is the case, then decision have no probabilistic or statistical impact and whatever decision you make with the information you have is Deterministic.

    So if you want to learn how and why estimating is needed to make decisions in the presence of uncertainty start here:

    And then when you hear about a conjecture that decisions can be made without estimating you'll know better, and consider anyone making that conjecture as uninformed about how probabilistic and stochastic processes in the project world actually work - especially when spending other people's money.

     

    Categories: Project Management

    Successes and Failures are Illusions

    NOOP.NL - Jurgen Appelo - Wed, 05/25/2016 - 09:19
    Successes and Failures.jpg

    In my talks around the world, I emphasize the need to run management experiments and I offer examples of interesting ideas that worked well for my team. Of course, with so many events per year, it was inevitable that someone would ask me, “What is your least successful experiment?”

    I had to think about that for a moment and I had difficulty coming up with examples. That was strange, I thought. According to information theory, we learn most when roughly half of our experiments fail. When I’m able to name a good number of ideas that work, and I’m not able to list ideas that don’t work, does that mean that my learning process is suboptimal? That would be a reason for concern!

    When I thought about it, I realized that, at least for me, success and failure are temporary statuses and I perceive them both with an optimistic mind. I have plenty of ideas that work for now, and I have a lot of ideas that don’t work yet. This means that, when you ask me about a successful experiment, I will happily share with you something that is successful now, knowing quite well that it may turn into a failure later. Likewise, when someone asks me about a failure, I have difficulty producing examples because I’m not considering the ideas that aren’t working yet as failures. They often just need more time, adaptation, and customization to make them work.

    In other words, for my long-term optimistic brain, half of the experiments succeed and the other half will succeed later. I’m sure there are people with a negative mindset who would turn it all around: Half of the experiments fail and the other half will fail tomorrow. (My short-term pessimistic brain often works like that: “Nothing works, and even if something works, it breaks when I start using it.”)

    Successes and failures are convenient illusions. They are judgement calls of the human mind, subjective evaluations of the consequences of our actions. Outcomes can be observed by anyone but successes and failures exist only in the eyes of the beholder.

    Photo: (C) 2010 Paul Keller, Creative Commons 2.0

    My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!

    Managing for Happiness cover (front)

    The post Successes and Failures are Illusions appeared first on NOOP.NL.

    Categories: Project Management

    So Mommy, Where Do Backlogs Come From?

    Onion

    Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos.  Storytelling is a powerful tool to elevate even the most diehard requirements analyst to a from a discussion individual requirements to a discussion of outcomes. The onion metaphor that is popularly used in agile planning (Cohn’s Planning Onion) can be used to describe the evolution of backlogs. Building an initial backlog is much like peeling through the layers of an onion to get to the core. There are many mechanisms for developing and maintaining the detailed backlogs, including: asking, observing, showing and all sorts of hybrids. Using the onion metaphor, the techniques we have explored in the past are the second layer of the onion. However, before getting to the center of the backlog evolution onion composed of features, epics, and user stories we need to understand the big picture.  Structured story telling is effective to tool to elicit a description of an outcome and nuances behinds that description, the outer layer in the backlog onion. The outside layer of the backlog evolution onion provides a strategic vision used for budgeting, change management and to provide context to guide the team or teams of teams as the development process progresses.

    Budgeting is a strategic form of estimation that most corporate and governmental entities perform.  In order to decide which piece of work to perform and to create a budget for, an organization must have an idea of what will be delivered and the value it will bring. Capturing a narrative story about the outcome and the impact on the organization is a useful tool in the budgeting process. The story replaces the classic back of the napkin description of what the users want often used for budgeting.

    Change requires a goal.  A goal is a definition of where you want to go; the outcome that is anticipated. A goal provides direction and a filter to understand the potential impact of constraints.  Generating a story provides the team and their stakeholders with the space to identify and explore what will be delivered, who will be involved and how the organization will need to adapt which is critical for building a change and communication plan to support the work.

    Somewhere in the middle of any sprint, it can be difficult to remember the ultimate goal of the work that is being done. While the story, the definition of done and the acceptance criteria define tactically what needs to happen the big picture often is more ethereal. One of the most colorful euphemisms that capture this sentiment is, ‚ÄúWhen you are up to your backside in alligators it‚Äôs difficult to remember that your initial objective was to drain the swamp.‚ÄĚ A story provides everyone focused on delivery with a tool that can be quickly referenced when making decisions.

    A story is a powerful tool for establishing the big picture while connecting with customers or team members. Stories establish a vision of where we want a journey to end and for how we want to make the journey. Stories provide a platform for making decisions about which work makes the most sense and helps us to predict who will be impacted along the way. Additionally, stories remind us of the context needed to help guide a team as they work through the process of writing, testing and demonstrating code.  All teams need to know the big picture story for the work they are doing.  The big picture is the container that the team will fill with epics, themes and user stories as the backlog evolves. 


    Categories: Process Management

    A study on scale: WhatsApp & Google Drive… the story of our integration

    Google Code Blog - Tue, 05/24/2016 - 21:14

    Posted by Mike Procopio, Engineering Manager, Google Drive and Wesley Chun, Developer Advocate, Google Apps

    WhatsApp is one of the most popular mobile apps in the world. Over a billion users send and receive over 42 billion messages, photos, and videos every day. It's fast, easy to use, and reliable.

    But what happens when people lose their phone or otherwise upgrade to a new one? All those messages and memories would be gone. So we worked with WhatsApp to give their users the ability to back up their data to Google Drive and restore it when they setup WhatsApp on a new phone. With messages and media safely stored in your Drive, there’s no more worry about losing any of those memories.

    Scaling for a billion users

    One of the biggest challenges for an integration of this scope is scaling. How do you back up data for a billion users? Many things were done to ensure the feature works as intended and is unnoticeable by users. Our approach? First, we relied on a proven infrastructure that can handle this kind of volume—Google Drive. Next, we optimized what to back up and when to do the backups—the key was to upload only incremental changes rather than transmit identical files.

    On the server side (backend), we focused on optimizing byte storage as well as the number of network calls between WhatsApp and Google. As far as deployment goes, we rolled out slowly over several months to minimize the size and impact of deployment.

    WhatsApp & Google Drive, a seamless integration

    If you have ever used WhatsApp, you know how it gets out of your way, and lets you get started quickly: no account creation, no passwords to manage, and no user IDs to remember or exchange. This sets a high bar for any integration with WhatsApp: for it to feel like a natural part of WhatsApp, it has to be as seamless, fast, and reliable as WhatsApp itself.

    By using the Google Drive API, we were able to achieve this: no need to type in any usernames or passwords, just a few taps in the app, and WhatsApp starts backing up. The best part is that all the tools used in the integration are available to all developers. With the Google Drive API, seamless and scalable integrations are as easy to use for the user as they are for developers.

    Are you ready to integrate your web and mobile apps with Google Drive? Get started today by checking out our intro video as well as the video demoing the newest API, then dig in with the developer docs found at developers.google.com/drive. We're excited to see what you build next with the Drive API—and we're ready to scale with you!

    Posted by Mike Procopio, Engineering Manager, Google Drive and Wesley Chun, Developer Advocate, Google Apps

    WhatsApp is one of the most popular mobile apps in the world. Over a billion users send and receive over 42 billion messages, photos, and videos every day. It's fast, easy to use, and reliable.

    But what happens when people lose their phone or otherwise upgrade to a new one? All those messages and memories would be gone. So we worked with WhatsApp to give their users the ability to back up their data to Google Drive and restore it when they setup WhatsApp on a new phone. With messages and media safely stored in your Drive, there’s no more worry about losing any of those memories.

    Scaling for a billion users

    One of the biggest challenges for an integration of this scope is scaling. How do you back up data for a billion users? Many things were done to ensure the feature works as intended and is unnoticeable by users. Our approach? First, we relied on a proven infrastructure that can handle this kind of volume—Google Drive. Next, we optimized what to back up and when to do the backups—the key was to upload only incremental changes rather than transmit identical files.

    On the server side (backend), we focused on optimizing byte storage as well as the number of network calls between WhatsApp and Google. As far as deployment goes, we rolled out slowly over several months to minimize the size and impact of deployment.

    WhatsApp & Google Drive, a seamless integration

    If you have ever used WhatsApp, you know how it gets out of your way, and lets you get started quickly: no account creation, no passwords to manage, and no user IDs to remember or exchange. This sets a high bar for any integration with WhatsApp: for it to feel like a natural part of WhatsApp, it has to be as seamless, fast, and reliable as WhatsApp itself.

    By using the Google Drive API, we were able to achieve this: no need to type in any usernames or passwords, just a few taps in the app, and WhatsApp starts backing up. The best part is that all the tools used in the integration are available to all developers. With the Google Drive API, seamless and scalable integrations are as easy to use for the user as they are for developers.

    Are you ready to integrate your web and mobile apps with Google Drive? Get started today by checking out our intro video as well as the video demoing the newest API, then dig in with the developer docs found at developers.google.com/drive. We're excited to see what you build next with the Drive API—and we're ready to scale with you!

    Categories: Programming

    SE-Radio Episode 258: Cody Voellinger on Recruiting Software Engineers

    Robert Blumen talks with Cody Voellinger, the founder of a recruiting firm that specializes in filling software engineer roles for San Francisco-area startups, about how jobs are created and how companies and engineers get matched up. Their discussion covers the entire job search process, from job descriptions to salary negotiations. They look at the job […]
    Categories: Programming

    Quote of the Day

    Herding Cats - Glen Alleman - Tue, 05/24/2016 - 16:47

    Wise men profit more from fools than fools from wise men; for the wise men shun the mistakes of fools, but fool do not imitate the success of the wise - Cato the Elder

    Any conjecture not based on testable principles, independent of personal opinion or anecdotes cannot stand up to the questioning of the wise.

    Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
    Categories: Project Management

    When is Agile Wrong for You?

    People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

    That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

    I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

    His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

    The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

    • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
    • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
    • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

    If you work in an agile organization, you know the problems with these assumptions.

    Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

    Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

    Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

    I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

    I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

    • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
    • Do a simulation with management to have them feel what agile is like.
    • Explain the system of agile and how the ideas that management have is not helpful.
    • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

    Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

    Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.

    Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

    Categories: Project Management

    When is Agile Wrong for You?

    People often ask me, “When is agile¬† right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile.

    That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You might not have a great environment to start. But a bad environment? That’s a horror show.

    I had a coaching conversation recently. My client¬†has a typical problem. He sees multiple ways to accomplish the work. He’s taking ideas from agile and lean, and smashing them together to create a project approach that works for them, at their company. It’s not quite agile. And, that’s the sticking point.

    His management wants to “go agile.” They have no idea what that means.They think agile is a way to get more good stuff faster with less cost. It’s possible that with agile approaches, they can achieve that as a by-product. To be honest, any approach that stops people from waiting for phases to finish will help. That’s not necessarily agile.

    The management team does know about one of the well-known approaches. They want everyone to go through that training. My client doesn’t think this will work. He has a number of concerns:

    • Management wants to control how people work at the project level. Management wants to define the iteration duration, what the standup questions will be, who will be on which team, and what the teams will do. (That’s enough right there, but there’s more. They are geographically dispersed across the globe. Going with an out-of-the-box solution does not make sense.)
    • Management wants to use team measurements for personal compensation. Specifically, they want to use personal velocity as a way to compensate people. (This is stupid, dangerous and wrong.)
    • Every manager my client has spoken with thinks that he or she does not need to change. Only the tech people need to change. (They could not be more mistaken.)

    If you work in an agile organization, you know the problems with these assumptions.

    Teams manage their own work: their intake is via the Product Owner. They decide how to work, flowing work through the team. Hopefully, the team focuses on their throughput, not who does what.

    Remember,¬†Velocity is Not Acceleration. When managers abuse velocity and use it to measure the team members (not even the entire team!), they create schedule games and a toxic team environment. At best, a manager’s abuse of velocity leads to people taking shortcuts and incurring technical debt. At worse, it destroys teamwork.

    Managers can create the environment in which people can succeed. Especially in agile and lean, managers do not have to “incent” people, or push people to do well. People will do a good job because they get feedback often and they want to. When managers attempt to manipulate an environment to deliver more with less work (what they think agile is), I’m not sure if anyone can succeed.

    I asked my client if the managers understood what agile might mean for them, as managers. He was sure the managers had no idea.

    I suggested that trying agile in this environment would give agile a bad name in the organization. I suggested these alternatives:

    • Ask about the three questions that might help the managers articulate their goals. See Define Your Agile Success.
    • Do a simulation with management to have them feel what agile is like.
    • Explain the system of agile and how the ideas that management have is not helpful.
    • Request a reasonable environment for a short-ish timebox (I was thinking about a month, maybe two months) to show management that their ideas are not the only ideas that could work. I suggested a number of measures my client could suggest to his management.

    Don’t start agile in a toxic environment. It’s not worth it. Agile is wrong for you. Remember that Agile is Not a Silver Bullet and Agile is Not for Everyone.

    Remember, agile is a cultural change, not merely a project management framework. Instead of agile, consider using all the ideas of agile to show steady progress and decide how to influence your managers.

    Instead of agile, consider using all the ideas of agile ( for example, teamwork to deliver small chunks of value) to show steady progress and decide how to influence your managers. Don’t ask teams to be collaborative when management wants to stay command-and-control.

    Categories: Project Management

    Book of the Month - IT Project Estimation: A Practical Guide to the Costing of Software

    Herding Cats - Glen Alleman - Tue, 05/24/2016 - 04:42

    IT Project EstimationEstimating is part of all decision making in the presence of uncertainty. Accuracy and precision are two primary attributes of all estimates.

    We all know estimates are hard. But there are lots of hard things in the development of enterprise software. We wouldn't be whining about how hard it is to construct a good First Normal Form database schema, or bullet proof our cyber security front end from attack by the Chinese would we.

    So why is estimating a topic that seems to be the whipping boy for software developers these days?

    My first inclination is that estimating is not taught very well in the software arts. In engineering schools it is. Estimating is part of all engineering disciplines. One undergraduate and one graduate degree is in physics. Estimating is at the very heart of that discipline. A second graduate degree is in Systems Management - which is a combination of Systems Engineering and Managerial Finance - how to manage the technical processes of engineering programs with the principles of managerial finance, contract law, and probabilistic decision making.

    This book comes with a spreadsheet for making the needed estimates to increase the probability of project success. It opens with an important quote that should be a poster on the wall of any shop spending other people's money

    For which of you, intending to build a tower, sitteth not down first, and counteth the cost, whether he have sufficient to finish it? Lest haply, after he hath laid the foundation, and is not able to finish it, all the behold it begin to mock him, saying, This man began to build, and was not able to finish - Luke 14:28-30

     

    Categories: Project Management

    Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics

    Herding Cats - Glen Alleman - Mon, 05/23/2016 - 21:26

    The on-going discussions that Decisions can be made in the absence of estimates reminds me of this concept.

     

    The conjecture that we can manage in the presence of uncertanty without estimating the impacts of our decisions, willfully ignores uncertainties in the present and future that will impact our outcomes, the external governance frameworks of managerial finance, probability and statistics of the processes under management, and regular governance processes and the decision rights of those governance frameworks.

    Those decision rights by the way belong to those paying, rarely to those spending. So the decision to estimate or not estimate rarely belongs to the developers spending the business's money.

    When the claim that #Noestimates critics say we're simply not being Opened Minded those advocates  want us to accept that everything can be challenged, without any basis for that conjecture. If that were the case, those proforring #Noestimates fit right into those believing the pseudoscience of spending other people's money in the presence of uncertanty.

    Thanks to Peter Kretzman for the link to the video.

    Related articles Intentional Disregard for Good Engineering Practices? Calculating Value from Software Projects - Estimating is a Risk Reduction Process How to Estimate Any Software Problem Quote of the Day - All Things Project Are Probabilistic Probability and Statistics of Project Work How We Make Decisions is as Important as What We Decide. An Example of Complete Misunderstanding of Project Work Intellectual Honesty of Managing in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Why Guessing is not Estimating and Estimating is not Guessing
    Categories: Project Management

    Quote of the Month May 2016

    From the Editor of Methods & Tools - Mon, 05/23/2016 - 08:59
    In other words, estimating is the key to unlocking the ability to commit. The ability to commit to near-term deliverables is the key to building a reliable, agile enterprise. So, there are good business reason why we need to take a harder look at this funny agile estimating thing. Source: Agile Software Requirements, Dean Leffingwell, […]