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

The Difference Between a Persona and an Actor

Actors playing different roles.

Actors playing different roles.

Classic requirements definition techniques, such as use cases, use roles and actors show interactions and movement of data between systems. An actor is defined as an entity that plays a specific role within a system. Conceptually, actors in systems and products are not very different from actors in a theater. In both cases, an actor can play one role in one situation and another role in another. For example, David Tennant played the role of Dr. Who and then later played the role of Alec Hardy in Broadchurch. An auto mechanic (actor) might play one role when using a piece of diagnostic software and quite a different role when entering your bill into the cash register. Actors play roles to accomplish some outcome which make them valuable for defining and documenting use cases. Actors are less useful if they are used for eliciting and documenting user stories.

Agile requirements (typically documented as user stories) use the concept of personas to identify interaction with an application or product. Personas and actors, though related concepts, are not the same and should not be used interchangeably. Use cases focus on defining a specific process and how that process will be accomplished in a step-by-step process. A user story defines an outcome, who needs the outcome and the benefit they will received. Actors and persona can be easily confused. When confused practitioners can easily fall into the habit of substituting actors for personas or vice versa, which reduces the effectiveness of which ever process is used.

Two related differences are helpful to understanding why actors and personas are very different. The first is definition granularity. Actors can be a person, group or external system, and are generally defined in very broad terms, either as a name or a short title tied to an explicit role. For example, I recently reviewed a use case for entering a purchase order that included actors for a “purchasing department clerk”, “general ledger system” and “accounting supervisor.” The purchasing clerk enters the purchase order, a feed sent to the general ledger and the accounting supervisor reviews the data entered. A persona represents one of the archetypical users that interacts with the system or product. Personas can play multiple roles depending on their current needs and motivation. A related difference is the documentation granularity in Personas: Nuts and Bolts we defined a template that included name, picture, motivation, backstory and needs. Persona are far more detailed and structured to connection between the team and the persona. Actors are typically defined as a title (note some methods add annotations however these never rise the level seen when defining a persona hence the occasional whining about persona being heavy weight).

Persona are used in user stories and generally are more robust than actors. A persona is designed to help the team understand who they are developing a system or product. The detail allows the team to “get into the archetypical users head” as user stories and functionality is developed. Actors are primarily used in use cases which are used as a tool to develop flow or process based requirements. Use cases are also often used to validate designs and as tool to drive testing activities. In these scenarios the focus is how the work will be performed and in what order rather than on why and what needs are being met. The way actors are used does not require the level of documentation to be effective.

Actors include far less detail than a persona and typically are identified at a significantly higher level of abstractions. Based on the higher level of abstraction of actors, many personas might be summarized into an actor. Both actors and personas have value however if you are using user stories, actors do not provide a deep enough understanding of the needs and motivations of the users and customers of the system. Alternately when using techniques like use cases, developing profiles archetypical users replete with their back story, needs, motivations and picture is overkill. I learned many years ago that the right tool for the right job makes the job easier.

Categories: Process Management

Power Great Gaming with New Analytics from Play Games

Android Developers Blog - 11 hours 15 min ago

By Ben Frenkel, Google Play Games team

A few weeks ago at the Game Developers Conference (GDC), we announced Play Games Player Analytics, a new set of free reports to help you manage your games business and understand in-game player behavior. Today, we’re excited to make these new tools available to you in the Google Play Developer Console.

Analytics is a key component of running a game as a service, which is increasingly becoming a necessity for running a successful mobile gaming business. When you take a closer look at large developers that do this successfully, you find that they do three things really well:

  • Manage their business to revenue targets
  • Identify hot spots in their business metrics so they can continuously focus on the game updates that will drive the most impact
  • Use analytics to understand how players are progressing, spending, and churning

“With player engagement and revenue data living under one roof, developers get a level of data quality that is simply not available to smaller teams without dedicated staff. As the tools evolve, I think Google Play Games Player Analytics will finally allow indie devs to confidently make data-driven changes that actually improve revenue.”

Kevin Pazirandeh
Developer of Zombie Highway 2

With Player Analytics, we wanted to make these capabilities available to the entire developer ecosystem on Google Play in a frictionless, easy-to-use way, freeing up your precious time to create great gaming experiences. Small studios, including the makers of Zombie Highway 2 and Bombsquad, have already started to see the benefits and impact of Player Analytics on their business.

Further, if you integrate with Google Play game services, you get this set of analytics with no incremental effort. But, for a little extra work, you can also unlock another set of high impact reports by integrating Google Play game services Events, starting with the Sources and Sinks report, a report to help you balance your in-game economy.

If you already have a game integrated with Google Play game services, go check out the new reports in the Google Play Developer Console today. For everyone else, enabling Player Analytics is as simple as adding a handful of lines of code to your game to integrate Google Play game services.

Manage your business to revenue targets

Set your spend target in Player Analytics by choosing a daily goal

To help assess the health of your games business, Player Analytics enables you to select a daily in-app purchase revenue target and then assess how you're doing against that goal through the Target vs Actual report depicted below. Learn more.

Identify hot spots using benchmarks with the Business Drivers report

Ever wonder how your game’s performance stacks up against other games? Player Analytics tells you exactly how well you are doing compared to similar games in your category.

Metrics highlighted in red are below the benchmark. Arrows indicate whether a metric is trending up or down, and any cell with the icon can be clicked to see more details about the underlying drivers of the change. Learn more.

Track player retention by new user cohort

In the Retention report, you can see the percentage of players that continued to play your game on the following seven days after installing your game.

Learn more.

See where players are spending their time, struggling, and churning with the Player Progression report

Measured by the number of achievements players have earned, the Player Progression funnel helps you identify where your players are struggling and churning to help you refine your game and, ultimately, improve retention. Add more achievements to make progression tracking more precise.

Learn more.

Manage your in-game economy with the Sources and Sinks report

The Sources and Sinks report helps you balance your in-game economy by showing the relationship between how quickly players are earning or buying and using resources.

For example, Eric Froemling, one man developer of BombSquad, used the Sources & Sinks report to help balance the rate at which players earned and spent tickets.

Read more about Eric’s experience with Player Analytics in his recent blog post.

To enable the Sources and Sinks report you will need to create and integrate Play game services Events that track sources of premium currency (e.g., gold coins earned), and sinks of premium currency (e.g., gold coins spent to buy in-app items).

Categories: Programming

Sponsored Post: MongoDB, Aerospike, Nervana, SignalFx, InMemory.Net, Couchbase, VividCortex, Transversal, MemSQL, Scalyr, AiScaler, AppDynamics, ManageEngine, Site24x7

Who's Hiring?
  • At Scalyr, we're analyzing multi-gigabyte server logs in a fraction of a second. That requires serious innovation in every part of the technology stack, from frontend to backend. Help us push the envelope on low-latency browser applications, high-speed data processing, and reliable distributed systems. Help extract meaningful data from live servers and present it to users in meaningful ways. At Scalyr, you’ll learn new things, and invent a few of your own. Learn more and apply.

  • Nervana Systems is hiring several engineers for cloud positions. Nervana is a startup based in Mountain View and San Diego working on building a highly scalable deep learning platform on CPUs, GPUs and custom hardware. Deep Learning is an AI/ML technique breaking all the records by a wide-margin in state of the art benchmarks across domains such as image & video analysis, speech recognition and natural language processing. Please apply here and mention “” in your message.

  • Linux Web Server Systems EngineerTransversal. We are seeking an experienced and motivated Linux System Engineer to join our Engineering team. This new role is to design, test, install, and provide ongoing daily support of our information technology systems infrastructure. As an experienced Engineer you will have comprehensive capabilities for understanding hardware/software configurations that comprise system, security, and library management, backup/recovery, operating computer systems in different operating environments, sizing, performance tuning, hardware/software troubleshooting and resource allocation. Apply here.

  • UI EngineerAppDynamics, founded in 2008 and lead by proven innovators, is looking for a passionate UI Engineer to design, architect, and develop our their user interface using the latest web and mobile technologies. Make the impossible possible and the hard easy. Apply here.

  • Software Engineer - Infrastructure & Big DataAppDynamics, leader in next generation solutions for managing modern, distributed, and extremely complex applications residing in both the cloud and the data center, is looking for a Software Engineers (All-Levels) to design and develop scalable software written in Java and MySQL for backend component of software that manages application architectures. Apply here.
Fun and Informative Events
  • MongoDB World brings together over 2,000 developers, sysadmins, and DBAs in New York City on June 1-2 to get inspired, share ideas and get the latest insights on using MongoDB. Organizations like Salesforce, Bosch, the Knot, Chico’s, and more are taking advantage of MongoDB for a variety of ground-breaking use cases. Find out more at but hurry! Super Early Bird pricing ends on April 3.
Cool Products and Services
  • Looking for a scalable NoSQL database alternative? Aerospike is validating the future of ACID compliant NoSQL with our open source Key-Value Store database for real-time transactions. Download our free Community Edition or check out the Trade-In program to get started. Learn more.

  • SignalFx: just launched an advanced monitoring platform for modern applications that's already processing 10s of billions of data points per day. SignalFx lets you create custom analytics pipelines on metrics data collected from thousands or more sources to create meaningful aggregations--such as percentiles, moving averages and growth rates--within seconds of receiving data. Start a free 30-day trial!

  • InMemory.Net provides a Dot Net native in memory database for analysing large amounts of data. It runs natively on .Net, and provides a native .Net, COM & ODBC apis for integration. It also has an easy to use language for importing data, and supports standard SQL for querying data. http://InMemory.Net

  • Top Enterprise Use Cases for NoSQL. Discover how the largest enterprises in the world are leveraging NoSQL in mission-critical applications with real-world success stories. Get the Guide.

  • VividCortex goes beyond monitoring and measures the system's work on your MySQL and PostgreSQL servers, providing unparalleled insight and query-level analysis. This unique approach ultimately enables your team to work more effectively, ship more often, and delight more customers.

  • MemSQL provides a distributed in-memory database for high value data. It's designed to handle extreme data ingest and store the data for real-time, streaming and historical analysis using SQL. MemSQL also cost effectively supports both application and ad-hoc queries concurrently across all data. Start a free 30 day trial here:

  • aiScaler, aiProtect, aiMobile Application Delivery Controller with integrated Dynamic Site Acceleration, Denial of Service Protection and Mobile Content Management. Also available on Amazon Web Services. Free instant trial, 2 hours of FREE deployment support, no sign-up required.

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • : Monitor End User Experience from a global monitoring network.

If any of these items interest you there's a full description of each sponsor below. Please click to read more...

Categories: Architecture

Trends for 2015

It’s time to blow your mind with the amazing things going on around the world.

Each year, I try to create a bird’s-eye view of key trends.   It’s a mash up of all the changes in technology, consumerism, and ideas that seem to be taking off.

Here are my trends for 2015:

Trends for 2015:  The Year of Digital Transformation

I call it the year of Digital Transformation because of the encroachment of technology into all things business, work, and life.

Technology is everywhere (and it’s on more wrists than I’ve ever seen before.)

What’s different now is how the combination of Cloud + Mobile + Social + Big Data + Internet-of-Things are really changing how business gets done.  Businesses around the world are using Cloud, Mobile, Social, Big Data, and Internet-of-Things to leap frog ahead of their competitors and to differentiate in new and exciting ways.

Businesses around the world are using technology to gains insights and to shape their customer experience, transform their workforce, and streamline their back-office operations.

It’s a new race for leadership positions in the Digital Economy.   With infinite compute and capacity, along with new ways to connect around the world, business leaders and IT leaders are re-imagining the art of the possible for their businesses.

While Cloud, Mobile, Social, Big Data, and Internet-of-Things might be the backbone of the changes all around us, it’s business model innovation that is bringing these changes to the market and helping them take hold.

Here is a preview of 10 key trends from Trends for 2015:  The Year of Digital Transformation:

  1. The Age of Instant Gratification.
  2. It’s a Mobile Everything World.
  3. Businesses Look to the Cloud.
  4. Internet of Things (IoT)
  5. Design is everywhere.
  6. Economy Re-Imagined (“The Circular Economy”)
  7. Culture of Health.
  8. Money is Reimagined (“The Future of Payments and Currency”)
  9. Digital Personal Assistants are Everywhere.
  10. Renegades and Rebels Rule the World

As a tip, when you read the post, try to scan it first, all the way down, so you can see the full collection of ideas.  Then circle back and slow down to really absorb the full insight.   You’ll find that you’ll start to see more patterns across the trends, and you’ll start to connect more dots.

I designed the post to make it easy to scan, as well as to read it end-to-end in depth.  I think it’s more valuable to be able to quickly take the balcony view, before diving in.   This way, you get more of a full picture view of what’s happening around the world.  Even if you don’t master all the trends, a little bit of awareness can actually go a long way. 

In fact, you might surprise yourself as some of the trends pop into your mind, while you’re working on something completely different.   By having the trends at my fingertips, I’m finding myself seeing new patterns in business, along with new ways that technology can enhance our work and life.

Trends actually become a vocabulary for generating and shaping new ideas.   There are so many ways to arrange and re-arrange the constellation of ideas.  You’ll find that I paid a lot of attention to the naming of each trend.  I tried to share what was already pervasive and sticky, or if it was complicated, I tried to turn it into something more memorable.

Use the trends as fodder and insight as you pave your way through your own Digital Transformation.

Categories: Architecture, Programming

Software Development Conferences Forecast March 2015

From the Editor of Methods & Tools - 14 hours 46 min ago
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine. Mini XP Day Benelux, April 3 2015, Mechelen, Belgium Agile ME Summit, April 12 2015, Dubai, UAE Mobile Dev + Test Conference, April 12-17 2015, San Diego, USA ProgSCon London, April 17 2015, London, UK O’Reilly Fluent Conference, ...

Should You Share Details from the Retrospective?

Mike Cohn's Blog - 15 hours 47 min ago

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

During a sprint retrospective, team members gather and discuss ways in which they can improve. This should include the ScrumMaster and product owner, as each is part of the team. The team is not limited to finding improvements only within their process. They may, for example, decide they need to improve their skills with a given technology and to seek out training in that area.

A concern many teams have around the retrospectives is whether the improvements they identify should be shared with others or kept within the team.

I think it’s ideal when all retrospective results from all teams can always be shared. Transparency is, after all, a pillar on which the Scrum process is built. But as much as I would love a culture of openness to exist such that everything can always be shared with everyone, that is often not the case.

In my experience, most teams will have no issue making public most of the improvements they identify. The items will be predictable things often similar to those being done by other agile teams in the organization: get better at this, learn how to do that, figure out how to do more of this and how to do the other thing earlier each sprint.

Occasionally, however, a team may have something they don’t want to share. Some examples I’ve seen include:

  • Learn this new technology that is a bit astray from a stated corporate direction, but which the team thinks may have enough promise that they’d want to use it anyway
  • Clean up the code in this part of the system, which the product owner is aware of, but for some reason, they don’t want to advertise is bad enough that it needs significant refactoring
  • Find ways to work better with that other group, who if they read this would want to know why they were being singled out for a better relationship

I want to repeat that while transparency is a virtue for agile teams, not all agile teams may be there yet. While perhaps keeping the results of their next few retrospectives private, those teams can work on feeling more comfortable opening up in the future.

Similarly, sometimes making a planned improvement known can impact the ability to make that improvement. I think that’s the case with the last example above.

Posting that you want to work better with the marketing group may make the marketing group either resist the change, or want to know what’s wrong with them that you need to change.

(Of course, they could also be quite open to changing to improving the relationship, so I would always discuss the situation with someone in the other group.)

Making this very practical, at the end of each sprint, the team has a list of changes they have agreed to make. I like to ask the team if there are any objections to making the list public. If there are not, I will hang the list in the team room or add it to the team’s home page.

When there are objections, I will see if we can leave perhaps one item off the publicly displayed list—usually that’s sufficient.

In the end, Scrum teams should have the courage to be transparent about their planned improvements whenever possible. But, occasionally there is more to be gained by keeping a retrospective item or two private.

Do You Know How to Say No?

Some of my coaching clients have way more to do than they can manage. Some of my project portfolio clients are struggling with how to say no.

My most recent Pragmatic Manager newsletter is all about what to do when you have too much to do. Read it at Do You Have Too Much to Do?

Categories: Project Management

Components vs classes

When discussing my C4 model for describing software architecture, I often get asked what the difference is between components and classes. In a nutshell, I like to think of a component as being a grouping of related functionality behind a nice clean interface. Of course, you could say the same about services, microservices or classes. So, let me show an example.

The Spring PetClinic application is a sample codebase used to illustrate how to use the Spring framework for building web applications in Java. If you download a copy of the GitHub repository and open it in your IDE of choice, you'll see the code looks like this.

Spring Petclinic code

Let's visualise this by drawing a class diagram of the code.

Spring Petclinic

This diagram shows all of the classes/interfaces and all of the relationships between them. The properties and methods are hidden from view because that adds too much noise into the picture. This isn't a complex codebase by any stretch of the imagination, but the diagram is showing too much detail. Let's remove those classes which aren't relevant to having an "architecture" discussion about the system. In other words, let's only try to show those classes that have some structural significance. In concrete terms, this means excluding the model (domain) and util classes.

Spring Petclinic

This diagram is much better, but in order to show the true picture of the dependencies, we've needed to show the interface and implementation classes for the service and repositories. Now that we have a much simpler diagram with which to reason about the software architecture, perhaps we can now show the methods.

Spring Petclinic

Then again, perhaps not! And this is a shame. Although I like the simpler diagram we saw before, it doesn't really tell me anything about the responsibilities of the classes. And having the interfaces and classes shown separately on the diagram seems a little like a workaround. Instead, let's treat the ClinicService and each of the *Repository things as a "component" by collapsing the interface and implementation classes. This is exactly what I'm trying to achieve with Structurizr.

Spring Petclinic

As this nicely illustrates, for me anyway, a component is simply a collection of implementation classes behind an interface. And rather than diagramming the component internals, I want to be able to zoom out slightly to see these components and how they are related to one another. This still leaves me with the ability to zoom in to see the internals of a component if I need to, but I don't want that view by default. It's too detailed and, besides, I can find that in the code myself if I know where to look. Thankfully the diagram you see above does have a relationship with the code. Try double-clicking on a component in the live version of the Spring PetClinic diagram. The diagram reflects the code.

Categories: Architecture

Python: Creating a skewed random discrete distribution

Mark Needham - Mon, 03/30/2015 - 23:28

I’m planning to write a variant of the TF/IDF algorithm over the HIMYM corpus which weights in favour of term that appear in a medium number of documents and as a prerequisite needed a function that when given a number of documents would return a weighting.

It should return a higher value when a term appears in a medium number of documents i.e. if I pass in 10 I should get back a higher value than 200 as a term that appears in 10 episodes is likely to be more interesting than one which appears in almost every episode.

I went through a few different scipy distributions but none of them did exactly what I want so I ended up writing a sampling function which chooses random numbers in a range with different probabilities:

import math
import numpy as np
values = range(1, 209)
probs = [1.0 / 208] * 208
for idx, prob in enumerate(probs):
    if idx > 3 and idx < 20:
        probs[idx] = probs[idx] * (1 + math.log(idx + 1))
    if idx > 20 and idx < 40:
        probs[idx] = probs[idx] * (1 + math.log((40 - idx) + 1))
probs = [p / sum(probs) for p in probs]
sample =  np.random.choice(values, 1000, p=probs)
>>> print sample[:10]
[ 33   9  22 126  54   4  20  17  45  56]

Now let’s visualise the distribution of this sample by plotting a histogram:

import matplotlib
import matplotlib.pyplot as plt
binwidth = 2
plt.hist(sample, bins=np.arange(min(sample), max(sample) + binwidth, binwidth))
plt.xlim([0, max(sample)])

2015 03 30 23 25 05

It’s a bit hacky but it does seem to work in terms of weighting the values correctly. It would be nice if it I could smooth it off a bit better but I’m not sure how at the moment.

One final thing we can do is get the count of any one of the values by using the bincount function:

>>> print np.bincount(sample)[1]
>>> print np.bincount(sample)[10]
>>> print np.bincount(sample)[206]

Now I need to plug this into the rest of my code and see if it actually works!

Categories: Programming

How to Be More Productive: The Chunking Technique

NOOP.NL - Jurgen Appelo - Mon, 03/30/2015 - 21:42

“You’re so productive!”
“You’re so disciplined!”
“You’re so handsome!”

OK, I may have misremembered that last one. But I did receive the first two compliments more than once. I usually accept this positive feedback reluctantly, given my ongoing frustrations about “never getting anything done around here!”

The post How to Be More Productive: The Chunking Technique appeared first on NOOP.NL.

Categories: Project Management

Open Google Maps from your iOS app

Google Code Blog - Mon, 03/30/2015 - 20:00
Originally posted on the Google Geo Developers Blog
Posted by Todd Kerpelman, Developer Advocate

If you're an iOS developer, you're probably aware that you have the ability to open some apps directly by taking advantage of their custom URL schemes. (And if you're not aware of that fact, I have an excellent set of videos to recommend to you!)

Of course, we wouldn't be telling you all of this on the Google Geo Developers blog if it weren't for the fact that you can also use the comgooglemaps:// custom URL scheme to open up a map, Street View, or direction request directly in Google Maps on iOS.
Constructing these URLs, however, isn't always easy -- I don't know about you, but I don't spend a lot of my time memorizing key/value pairs for URL arguments. And adding x-callback-url support, while super useful for redirecting users back to your app, means adding even more URL arguments and escaping. And because not everybody has Google Maps installed on their iOS device, you may also want to build URLs to open up Apple Maps, which have their own similar-but-slightly different set of URL arguments.

It was one of those situations that made me say, "Hey, somebody should write a utility to make this easier." And that's how, a few months later, we ended up publishing the OpenInGoogleMapsController for iOS.

OpenInGoogleMapsController is a class that makes it easy to build links to open a map (or display Street View or directions) directly in Google Maps for iOS. Rather than creating URLs by hand, you can create map requests using Objective-C classes and types, so you can take advantage of all the type-checking and code hinting you've come to expect from Xcode.

For instance, if you needed biking directions from Sherlock Holmes' apartment on Baker Street to Scotland Yard, your request might look something like this:

GoogleDirectionsDefinition *defn = [[GoogleDirectionsDefinition alloc] init];
defn.startingPoint =
[GoogleDirectionsWaypoint waypointWithQuery:@"221B Baker Street, London"];
defn.destinationPoint = [GoogleDirectionsWaypoint
waypointWithLocation:CLLocationCoordinate2DMake(51.498511, -0.133091)];
defn.travelMode = kGoogleMapsTravelModeBiking;
[[OpenInGoogleMapsController sharedInstance] openDirections:defn];

My favorite feature about this utility is that it supports a number of fallback strategies. If, for instance, you want to open up your map request in Google Maps, but then fallback to Apple Maps if the user doesn't have Google Maps installed, our library can do that for you. On the other hand, if it's important that your map location uses Google's data set, you can open up the map request in Google Maps in Safari or Chrome as a fallback strategy. And, of course, it fully supports the x-callback-url standard, so you can make sure Google Maps (or Google Chrome) has a button that points back to your app.

Sound interesting? Give it a try. Just add a couple of files to your Xcode project, and you're ready to go. Feel free to add issues or enhancements requests you might encounter in the GitHub repository, and let us know if you use it in your app. We'd be excited to check it out.
Categories: Programming

How We Scale VividCortex's Backend Systems

This is guest post by Baron Schwartz, Founder & CEO of VividCortex, the first unified suite of performance management tools specifically designed for today's large-scale, polyglot persistence tier.

VividCortex is a cloud-hosted SaaS platform for database performance management. Our customers install agents that measure the work their servers perform (queries, processes, etc) and generate metrics and events from that at high frequency. The agents send the resulting data to our APIs, where we host our analysis backend. The backend system is a collection of databases, internal services (quasi-microservices), and web-facing APIs. These APIs also power our AngularJS frontend application.

We deal with a lot of data. We ingest metrics and events at high speed. We also perform analytics that touch large amounts of data interactively. We are not unique and I don't want to imply we are somehow impressive in the scheme of things. We don't yet operate at "web scale." Nevertheless, our workload has some relatively unusual characteristics, and we've been able to scale as far as we have, while remaining pretty efficient in terms of cost and infrastructure. And my career in consulting has taught me that building systems like this is usually a challenge for a company (as it has been for us). Our story might be useful to others. For that reason I will go into unnecessary detail on specific parts of our workload and the challenges it brings.

What We Do
Categories: Architecture

Why You Need to Speak at Your Next Code Camp

Making the Complex Simple - John Sonmez - Mon, 03/30/2015 - 16:00

I just came back from Orlando Code camp, so I thought I’d do a post talking about why speaking at a code camp is a great opportunity and why—even if you think you have nothing to talk about or teach—you should be speaking at a code camp near you. Now, just in case you aren’t […]

The post Why You Need to Speak at Your Next Code Camp appeared first on Simple Programmer.

Categories: Programming

Most Prolific Bloggers on .Net

Phil Trelford's Array - Mon, 03/30/2015 - 08:15

On Saturday I headed down to Thoughtworks in Soho, London for an F# Open Data Hackathon organized by Thoughtworker Sean Newham. We started up with questions we’d like to answer using open data. I was interested in finding the most prolific bloggers in .Net, and formed a team with Adam Kosiński, Emmet Cassidy and my son Sean. We had from around 11am to 3pm to answer the question and present the results.

Dew Drop

We used data mined from Alvin Ashcraft’s Morning Dew site, which provides a labelled list of top links almost every week day since 2008.

Here’s Alvin’s activity since 2008:

Dew Drop Calendar 2008-2015

Alvin’s links covers many topics including .Net, Web, Mobile and XAML:

Dew Drop Tags 2008-2015

Top 100 .Net Bloggers

For this analysis we’re looking only at links labelled as “Top Links” or “.NET”. Between 2008 and 2015 there were over 20,000 links from over 3000 unique author names.

Interestingly the top 100 bloggers account for roughly half of all posts, and here’s the table of top 100 .Net bloggers based on data extracted from the Morning Dew:

Rank Name 2008 2009 2010 2011 2012 2013 2014 2015 Total 1 Greg Duncan 2 16 74 142 116 86 74 14 524 2 Oren Eini 31 71 76 42 94 49 32 12 407 3 Sean Sexton 0 0 0 0 0 193 195 0 388 4 Zain Naboulsi 0 0 236 56 17 37 3 0 349 5 Richard Carr 6 13 78 77 90 58 12 0 334 6 Eric Lippert 7 48 47 46 37 68 44 0 297 7 Raymond Chen 0 0 0 20 75 92 86 17 290 8 Scott Hanselman 28 16 38 39 44 37 50 7 259 9 MS Downloads 27 35 42 48 46 23 13 0 234 10 CodePlex 36 12 34 70 49 13 10 0 224 11 Sasha Goldshtein 4 16 30 31 22 25 19 7 154 12 Brian Harry 0 0 0 0 35 58 46 8 147 13 Julie Lerman 19 45 15 16 19 16 7 2 139 14 Scott Guthrie 3 12 47 18 19 24 12 2 137 15 Martin Hinshelwood 3 12 12 20 27 32 25 5 136 16 Mike Hadlow 6 16 30 21 25 22 4 0 124 17 Dhananjay Kumar 0 0 0 60 26 7 25 1 119 18 Derik Whittaker 24 21 21 21 18 8 6 0 119 19 Gunnar Peipman 1 40 36 9 9 15 4 1 115 20 Abhijit Jana 0 0 18 87 0 3 2 3 113 21 Ricardo Peres 0 0 0 6 15 31 38 13 103 22 Jimmy Bogard 19 18 14 12 7 5 18 6 99 23 Dennis Delimarsky 0 0 50 28 16 5 0 0 99 24 Peter Vogel 0 0 0 0 13 27 44 12 96 25 Jonathan Allen 0 0 11 19 25 15 17 9 96 26 Matthew Podwysocki 27 45 21 1 1 0 0 0 95 27 Rockford Lhotka 8 19 17 20 20 5 3 0 92 28 K. Scott Allen 11 8 14 15 19 11 8 3 89 29 Shai Raiten 0 0 18 40 22 9 0 0 89 30 Charles Sterling 3 8 4 6 25 24 15 1 86 31 Deborah Kurata 0 24 36 2 9 3 8 1 83 32 Phil Haack 3 5 10 31 13 11 6 0 79 33 James Michael Hare 0 0 8 38 24 3 0 3 76 34 Peter Kellner 2 18 10 8 22 9 3 3 75 35 Sacha Barber 7 4 5 9 4 8 31 7 75 36 Kunal Chowdhury 0 0 14 13 20 20 6 2 75 37 Pete Brown 3 6 28 17 16 3 2 0 75 38 Mike Taulty 7 9 9 10 13 4 21 1 74 39 Glenn Block 12 9 18 11 9 5 6 2 72 40 Miguel de Icaza 0 0 25 19 8 5 12 3 72 41 Davy Brion 7 30 26 9 0 0 0 0 72 42 Mary Jo Foley 0 3 1 20 17 16 12 2 71 43 Rick Strahl 9 13 1 11 15 8 7 7 71 44 Alex Skorkin 0 0 11 51 9 0 0 0 71 45 Jesse Liberty 3 0 10 13 19 4 15 1 65 46 Tatworth 0 0 0 14 30 7 14 0 65 47 Daniel Moth 17 23 0 12 6 3 4 0 65 48 Abhishek Sur 0 1 20 35 2 3 1 2 64 49 Clemens Reijnen 11 12 19 5 8 3 5 1 64 50 Justin Etheredge 25 20 16 3 0 0 0 0 64 51 Jeremy Likness 0 0 18 12 21 3 5 3 62 52 Iris Classon 0 0 0 0 37 16 6 3 62 53 Bill Wagner 0 7 2 21 11 7 11 3 62 54 Mark Needham 0 31 31 0 0 0 0 0 62 55 Harry Pierson 17 37 0 2 3 0 1 0 60 56 Rob Eisenberg 4 1 14 5 3 12 13 7 59 57 Steven Sinofsky 0 0 1 22 31 3 1 0 58 58 John Papa 8 3 7 3 13 15 7 0 56 59 Patrick Smacchia 9 8 11 12 10 4 2 0 56 60 Jon Skeet 6 1 0 15 9 5 16 3 55 61 Steve Smith 0 1 3 22 8 6 15 0 55 62 Bnaya Eshet 0 0 0 12 18 9 5 9 53 63 Carl Franklin & Richard Campbell 0 0 3 0 7 17 16 10 53 64 Shawn Wildermuth 7 13 8 6 10 1 6 2 53 65 Rory Primrose 0 0 19 18 7 7 2 0 53 66 Willy-P. Schaub 0 0 0 3 17 9 19 4 52 67 Kirill Osenkov 1 18 12 5 9 4 3 0 52 68 S.Somasegar 0 0 0 0 15 16 17 3 51 69 Bart de Smet 21 24 5 1 0 0 0 0 51 70 Laurent Bugnion 0 0 7 17 13 4 6 3 50 71 Eric Battalio 0 0 0 0 6 15 27 2 50 72 Maarten Balliauw 2 0 6 16 7 15 3 1 50 73 Don Syme 1 2 4 15 13 14 1 0 50 74 Gil Fink 1 4 24 20 1 0 0 0 50 75 Cameron Skinner 11 11 21 6 1 0 0 0 50 76 Dave M. Bush 7 25 5 0 0 3 7 2 49 77 Stephen Forte 4 21 21 3 0 0 0 0 49 78 Michael Crump 0 0 2 11 13 4 13 5 48 79 Kim Spilker 0 0 2 16 7 9 14 0 48 80 Jura Gorohovsky 0 0 5 12 15 12 4 0 48 81 Wally McClure 0 4 11 17 15 0 1 0 48 82 Jason Zander 0 10 13 5 18 0 1 0 47 83 Chris Sells 2 22 10 4 9 0 0 0 47 84 Marcelo Lopez Ruiz 1 2 37 5 1 0 0 0 46 85 Nicholas Blumhardt 0 4 6 6 1 7 18 3 45 86 Rob Reynolds 0 12 11 9 6 3 4 0 45 87 Dmitri Nesteruk 0 1 1 1 14 20 2 5 44 88 Rory Becker 0 0 13 11 1 1 18 0 44 89 Filip Ekberg 0 0 0 0 11 21 11 0 43 90 G. Andrew Duthie 2 12 4 4 20 1 0 0 43 91 Grigori Melnik 0 0 8 13 8 8 4 1 42 92 Jonathan Wood 0 0 6 21 4 0 8 3 42 93 Peter Ritchie 3 1 14 6 13 2 3 0 42 94 Rob Conery 10 2 4 15 5 1 5 0 42 95 Gian Maria Ricci 0 0 1 37 4 0 0 0 42 96 Anoop Madhusudanan 0 0 14 8 11 8 0 0 41 97 Jeff Blankenburg 0 1 15 6 19 0 0 0 41 98 Rowan Miller 0 0 5 4 4 10 15 2 40 99 Hadi Hariri 0 1 4 21 11 2 0 0 39 100 Yochay Kiriaty 3 15 15 6 0 0 0 0 39


You can download the data from

I’d be interested in hearing about what you find :)

Categories: Programming

SPaMCAST 335 – Critical Agile Definitions, Communication Content, Microservices and Granularity

Listen Now

Subscribe on iTunes

In this episode of the Software Process and Measurement Cast we feature three columns!  The first is our essay on the definitions of four critical words.  What do the words effectiveness, efficiency, frameworks and methodologies really mean?  These words get used ALL the time, however they really do have fairly specific meanings.  Meanings that, once understood and used to guide how we work, can help everyone to deliver more value and make our customers more satisfied!  The second column is from Jo Ann Sweeney with another of her stellar, Explaining Change columns.  In this segment, Jo Ann talks about content and a framework to guide the development of content.  Anchoring the Cast this week is Gene Hughson with another of his Forms Follows Function columns.  Gene extends his mini-series on microservices with a discussion of whether granularity is irrelevant.  Lots of content in this installment of the Software Process and Measurement Cast!

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

Categories: Process Management

SPaMCAST 335 – Critical Agile Definitions, Communication Content, Microservices and Granularity

Software Process and Measurement Cast - Sun, 03/29/2015 - 22:00

In this episode of the Software Process and Measurement Cast we feature three columns!  The first is our essay on the definitions of four critical words.  What do the words effectiveness, efficiency, frameworks and methodologies really mean?  These words get used ALL the time, however they really do have fairly specific meanings.  Meanings that, once understood and used to guide how we work, can help everyone to deliver more value and make our customers more satisfied!  The second column is from Jo Ann Sweeney with another of her stellar, Explaining Change columns.  In this segment, Jo Ann talks about content and a framework to guide the development of content.  Anchoring the Cast this week is Gene Hughson with another of his Forms Follows Function columns.  Gene extends his mini-series on microservices with a discussion of whether granularity is irrelevant.  Lots of content in this installment of the Software Process and Measurement Cast!

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

Categories: Process Management

InetAddressImpl#lookupAllHostAddr slow/hangs

Mark Needham - Sun, 03/29/2015 - 01:31

Since I upgraded to Yosemite I’ve noticed that attempts to resolve localhost on my home network have been taking ages (sometimes over a minute) so I thought I’d try and work out why.

This is what my initial /etc/hosts file looked like based on the assumption that my machine’s hostname was teetotal:

$ cat /etc/hosts
# Host Database
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##	localhost	broadcasthost
::1             localhost
#fe80::1%lo0	localhost	wuqour.local       teetotal

I setup a little test which replicated the problem:

public class LocalhostResolution
    public static void main( String[] args ) throws UnknownHostException
        long start = System.currentTimeMillis();
        InetAddress localHost = InetAddress.getLocalHost();
        System.out.println(System.currentTimeMillis() - start);

which has the following output:

Exception in thread "main" teetotal-2: teetotal-2: nodename nor servname provided, or not known
	at LocalhostResolution.main(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at com.intellij.rt.execution.application.AppMain.main(
Caused by: teetotal-2: nodename nor servname provided, or not known
	at Method)
	... 6 more

Somehow my hostname has changed to teetotal-2 so I added the following entry to /etc/hosts:	teetotal-2

Now if we run the program we see this output instead:


It’s still taking 5 seconds to resolve which is much longer than I’d expect. After break pointing through the code it seems like it’s trying to do an IPv6 resolution rather than IPv4 so I added an /etc/hosts entry for that too:

::1             teetotal-2

Now resolution is much quicker:


Happy days!

Categories: Programming

Re-Read Saturday: The Goal: A Process of Ongoing Improvement. Part 6


The Goal: A Process of Ongoing Improvement, published in 1984, is a business novel. The Goal uses the story of Alex Rogo, plant manager, to illustrate the theory of constraints and how the wrong measurement focus can harm an organization. The focus of the re-read is less on the story, but rather on the ideas the book explores that have shaped lean thinking. Earlier entries in this re-read are:

Part 1                         Part 2                         Part 3                         Part 4                      Part 5

This week I attended the CMMI EMEA conference.  Kirk Botula, CEO of the CMMI institute delivered a great speech about developing and managing capability.  Capability is ability to do something.  Without capabilities, individuals, teams and organizations are powerless. Tools like the CMMI, Agile and lean provide frameworks to decide which capabilities are important and then to measure the level and impact of current capabilities. During Kirk’s talk he referenced two books.  The first was Out of the Crisis by Edwards Deming and The Goal: A Process of Ongoing Improvement by Jeff Cox and Eliyahu Goldratt.  Deming’s work defined the continuous process improvement movement, while Goldratt framed the lean movement.  Later during the week I asked a group of C-level executives if they were familiar with The Goal and the Theory of Constraints.  Unfortunately the answer was not a resounding yes.  The limited awareness is problematic because that leads to a focus on cost containment and efficiency as the most important goals over effectiveness and throughput. Over focusing on cost and efficiency leads sub-optimal performance and in the long run market failure. In this installment of Re-read Saturday we begin to encounter the nuts and bolts that make the Theory of Constraints an effective tool for structured process improvement.

Chapter 17

After dealing with the complications of a household in turmoil (Alex’s household is a reflection of a series of dependent events and statistical variability), Alex arrives at the plant to find an order for an important client is late. Alex explains how dependent events and statistical variability will lead to the sub-optimal performance of a system. Despite Alex’s revelations from observing the scout troop, his team believes they can deliver the parts in time to make the last truck at 5 PM. Alex places a ten dollar bet that the parts will not be ready ship that day due to variations in the production process.  The production of the parts requires two steps. The first step in the production process averages 25 parts per hour. In this case the production started slowly, however by the end of four hours 100 parts had been completed. Therefore the process had averaged 25 parts per hour. The production ranged from 19 parts to 32 parts. While the second step in the process had the same 25 parts per hour capacity, because of the variability of the first processes the capacity of the second process was exceeded on two occasions, therefore all 100 parts were not completed.

Chapter 18

Alex and his now attentive staff (the performance on late order has gotten their attention) attempt to determine how to control the flow of work thought the steps in the process (dependent events) as they are subject to statistical variability.They consider longer lead-time as a method to smooth the flow, because longer lead times would generate higher inventories to reduce efficiency. As a group they elect to call Johan, who introduces another new concept: bottleneck and non-bottleneck resources. A bottleneck resource is any resource that has a capacity that is equal to or less than the demand placed upon it. Any variability in the flow of work that is beyond the capacity of the bottlenecked resources will generate a backlog. While The Goal was written from the point of view of a manufacturing plant, bottlenecks can occur in any type of project. Any resource that is planned to 100% capacity is a bottlenecked resource. Through discussion with Johan the team discovers that like the scout troop the capacity of the plant is governed by the step with the least capacity. In the plant, the team needs to discover the bottlenecks that are blocking their ability to deliver effectively.

Bottlenecks are neither good or bad in their own right. A process with infinite capacity at all steps will not be efficient because resources would be under utilized. Bottlenecks can be used to generate a predictable process. This a reflection of how Alex used the slow scout in Chapter 15. Also understanding the capacity and variability of the bottleneck step will help make the process predictable.

When the staff discovers the bottleneck, it generates a process of discovery in which the team discovers that they really don’t know the process well and that the time accounting data is less than perfect. The big revelation is that looking for steps in the process with build-ups of work-in-process waiting to be addressed are an indication of a bottleneck. In this case the team finds two culprits. The first is the industrial robot that is darling of senior management and the second is the heat treatment step. The bottlenecks cannot be moved to the head of the column like Alex did to solve the problem with the boy scouts, nor can extra capacity be generated by increasing staff or buying machines. The workday ends with Alex searching for a solution.

The affect of the combination dependent events and statistical variability on the plant floor is obvious. In a manufacturing plant where processes are heavily automated variability might be low, however it still exists. In software or product development same interaction of process steps and variability exits although because the work tends to be more discovery-oriented, the variability is probably higher making the impact more substantial and less predictable. The variability in flow through the process exposes bottlenecks that limit our ability to catch up, making projects and products late or worse generating technical debt when corners are cut in order to make the date or budget.

Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Chapters 13 through 15 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version

Categories: Process Management

How to Avoid the "Yesterday's Weather" Estimating Problem

Herding Cats - Glen Alleman - Sat, 03/28/2015 - 23:39

One suggestion from the #NoEstimates community is the use of empirical data of past performance. This is many time called yesterdays weather. First let's make sure we're not using just the averages from yesterdays weather. And even adding the variance to that small sample of past performance can lead to very naive outcomes. 

We need to do some actual statistics on that time series. A simple R set of commands will produce the chart below from the time series of past performance data.


 But that doesn't really help without some more work.

  • Is the future Really like the past - are the work products and the actual work performed in the past replicated  in the future? If so, this sound like a simple project, just turn out features that all look alike.
  • Is there any interdependencies that grow  in complexity as the project move forward? This is the integration and test problem. Then the system of systems integration and test problem. Again simple project don't usually have this problem. More complex projects do.
  • What about those pesky emerging requirements. This is a favorite idea of agile (and correctly so), but simple past performance is not going to forecast the needed performance in the presence of emerging requirements
  • Then all the externalities of all project work, where are those captured in the sample of past performance?
  • All big projects have little projects inside them is a common phrase. Except that collection of little projects needs to be integrated, tuned, tested, verified and validated that all the parts when assembled actually do what the customer wants.

Getting Out of the Yesterday's Weather Dilemma

Let's use the chart below to speak about so sources of estimating NOT based on simple small samples of yesterdays weather. This is a Master Plan for a non-trivial project to integrate half dozen or so legacy enterprise systems with a new health insurance ERO system for an integrated payer/provider solution: 

Capabilities Flow

  • Reference Class Forecasting for each class of work product.
    • As the project moves left to right in time the classes of product and the related work likely change. 
    • Reference classes for each of this movements through increasing maturity, and increasing complexity from integration interactions needs to be used to estimate not only the current work but the next round of work
    • In the chart above work on the left is planned with some level of confiidence, because it's work in hand. Work in the right is in the future, so an courser estimate is all that is needed for the moment.
    • This is a planning package notion used in space and defense. Only plan in detail what yuo understand in detail.
  • Interdependencies Modeling in MCS
    • On any non-trivial project there are interdependencies
    • The notion of INVEST needs to be tested 
      • Independent - not usually the case on enterprise projects
      • Negotiable - usually not, since he ERP system provides the core capability to do business. Would be illogical to have half the procurement system.
      • We can issue purchase orders and receive goods. But we cant pay for then until we get the Accounts Payable system. We need both at the same time
      • Valuable - Yep, why we doing this if it's not valuable to the business. This is a strawman used by low business maturity projects.
      • Estimate - to a good approximation is what the advice tells us. The term good needs a unit of measure
      • Small - is a domain dependent measure. Small to an enterprise IT projects may be huge to a sole contributor game developer.
      • Testable - Yep, and verifiable, and validatable, and secure, and robust, and fault tolerant, and meets all performance requirements.
  • Margin - protects dates, cost, and technical performance from irreducible uncertainty. By irreductible it means nothing can be done about the uncertainties. It's not the lack of knowledged that is found in reducible uncertainty. Epistemic uncertainty. Irreducible uncertainty is Aleatory. It's the natural randomness in the underlying processes that creates the uncertainty. When we are estimating in the presence of aleatory uncertainty, we must account for this aleatory uncertainty. This is why using the average of a time series for making a decision about possible future outcomes will always lead to disappointment. 
    • First we should always use the Most Likely value of the time series, not Average of the time series.
    • The Most Likely - the Mode - is that number that occurs most often of all the possible values that have occurred in the past. This should make complete sense when we consider what value will appear next? Why the value that has appeared Most Often in the past.
    • The Average of two numbers 1 and 99 is 50. The average of two numbers 49 and 51 is 50. Be careful with averages in the absence of knowing the variance.
  • Risk retirement - Epistemic uncertainty creates risks that can be retired. This means spending money and time. So when we're looking at past performance in an attempt to estimate future performance (Yesterdays Weather), we must determine what kind of uncertainties there are in the future and what kind of uncertainties we encountered in the past.
    • Were the and are they reducible or irreducible?
    • Did the performance in the past contain irreducible uncertainties, baked into the numbers that we did not recognize? 

This bring up a critical issue with all estimates. Did the numbers produced from the past performance meet the expected values or were they just the numbers we observed? This notion of taking the observed numvers and using them for forecasting the future is an Open Loop control system. What SHOULD the numbers have been to meet our goals? What SHOULD the goal have been? Did know that, then there is no baseline to compare the past performance against to see if it will be able to meet the future goal. 

I'll say this again - THIS IS OPEN LOOP control, NOT CLOSED LOOP. No about of dancing around will get over this, it's a simple control systems principle found here. Open and Close Loop Project Controls

  • Measures of physical percent complete to forecast future performance with cost, schedule, and technical performance measures - once we have the notion of Closed Loop Control and have constructed a steering target, can capture actual against plan, we need to define measures that are meaningful to the decisions makers. Agile does a good jib of forcing working product to appear often. The assessment of Physical Percent Complete though needs to define what that working software is supposed to do in support of the business plan.
  • Measures of Effectiveness - one very good measure is of Effectiveness. Does the software provide and effective solution to the problem. This begs the question or questions. What is the problem and what does an effective solution looks like were it to show up. 
    • MOE's are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.
  • Key performance parameters - the companion of Measures of Effectiveness are Measures of Performance.
    • MOP's characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.
  • Along with these two measures are Technical Performance Measures
    • TPM's are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.
  • And finally there are Key Performance Parameters
    • KPPs represent the capabilities and characteristics so significant  that failure to meet them can be cause for reevaluation, reassessing, or termination of the program.

The connections between these measures are shown below.

Screen Shot 2015-03-28 at 4.37.51 PM

With these measures, tools for making estimates of the future - forecasts - using statistical tools, we can use yesterdays weather, tomorrow models and related reference classes, desired MOE's, MOP's, KPP's, and TPM's and construct a credible estimate of what needs to happen and then measure what is happening and close the loop with an error signal and take corrective action to stay on track toward our goal.

This all sounds simple in principle, but in practice of course it's not. It's hard work, but when you assess the value at risk to be outside the tolerance range where thj customer is unwilling to risk their investment, we need tools and processes wot actually control the project.

Categories: Project Management

Some More Background on Probability, Needed for Estimating

Herding Cats - Glen Alleman - Sat, 03/28/2015 - 15:05

Statistics and Probability copyThe continued lack of understanding of the underlying probability and statistics of making decisions in the presence of uncertainty  to plague the discussion of estimating software.

All elements of all projects are statistical in nature. This statistical behaviour - reducible or irreducible stochastic processes - creates uncertainty.

Event based uncertainties have a probability of occurrence and a probability of the impact once that uncertainty becomes a relaity. These are Epistemic uncertainties - epistemology is the studdy of knowledge. Espitemtic means knowing or not knowing in this case/ We can buy knowledge. This is the core concept of agile paradigm/ We are buying down risk by building software to test the uncertainties of the project deliverables. This is the basis of saying agile is about risk management. But I suspect those saying that without being able to do the math as we say in our domain, don't realize what they are actually saying.

The natural occurring variances are aleatory. They are always there, they are irreducible. That is they can't be fixed. Work effort and duration is aleatory. The ONLY fix for aleatory uncertainty and the resulting risk is margin. Cost margin, schedule margin, technical performance margin. You can't buy the fix to aleatory uncertainty. 

Found a book today Discover Probability: How to Use It, How to Avoid Misusing It, and How It Affects Every Aspect of Your Life: How to Use It, How to Avoid Misusing It, and How It Affects Every Aspect of Your Life, Arieh Ben-Naim. World Scientific. 

This is one of those must read book for anyone working in a domain where probability and statistics dominates the decision making process. Unlike other books How To Measure AnythingThe Flaw of Averages, How Not to Be Wrong: The Power of Mathematical Thinking, which is very good books - but populist in that they contain little in terms of actual mathematics. this books is in between. Lots of narrative, but math as well. Not like Probability Methods of Cost  Uncertainty Analysis: A Systems Engineering Perspective but in the middle.

In The End

you can't make decisions in the presence of uncertainty without estimating the outcome of your decision in the future. Using empirical data is preferred. But that empirical data MUST be adjusted for future uncertainty., past variances, sampling errors, poor representations of the actual process and the plethora of other drivers of uncertainty. Having small, simple samples without variances, and most of all confirming the past actually does represent the future - and doing that mathematically not just announcing it - is needed for any estimates of the future to have any credibility. Otherwise it's just an uninformed bad guess.

Categories: Project Management