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

Clean Up

3-29 2013 poop

Why do death march (gruelingly overworked and therefore high risk) projects still occur? While poor processes, poor estimation and out of control changes are all still factors, I am seeing more that reflect poor choices based on business pressure.  How often have you heard someone say that the end justifies the means?  It is easier to say yes to everything and avoid hard discussions about trade-off and just admonish the troops to work harder and smarter.

In Agile, we would expect backlogs and release plans to help enforce those sorts of discussions. Unless, of course, you stop doing them.  I recently talked to a group that had identified the need to do a better job of breaking accepted backlog items down into tasks during sprint planning (identified during a retrospective), only to fall prey to an admonition to spend less time planning and more time “working” leading to rework and disappointing sprint results.

As you discover messes, whether in the code you are working on or in the processes you are using to guide your work, you are obligated to clean up after yourself.  If you don’t, sooner or later no one will want to play in your park  . . . and  probably neither will you.

Categories: Process Management

Stuff The Internet Says On Scalability For October 10th, 2014

Hey, it's HighScalability time:

Social climber: Instagram explorer scales to new heights in New York.


  • 11 billion: world population in 2100; 10 petabytes: Size of Netflix data warehouse on S3; $600 Billion: the loss when a trader can't type; 3.2: 0-60 mph time of probably not my next car.
  • Quotable Quotes:
    • @kahrens_atl: Last week #NewRelic Insights wrote 618 billion events and ran 237 trillion queries with 9 millisecond response time #FS14
    • @sustrik: Imagine debugging on a quantum computer: Looking at the value of a variable changes its value. I hope I'll be out of business by then.
    • Arrival of the Fittest: Solving Evolution's Greatest Puzzle: Every cell contains thousands of such nanomachines, each of them dedicated to a different chemical reaction. And all their complex activities take place in a tiny space where the molecular building blocks of life are packed more tightly than a Tokyo subway at rush hour. Amazing.
    • Eric Schmidt: The simplest outcome is we're going to end up breaking the Internet," said Google's Schmidt. Foreign governments, he said, are "eventually going to say, we want our own Internet in our country because we want it to work our way, and we don't want the NSA and these other people in it.
    • Antirez: Basically it is neither a CP nor an AP system. In other words, Redis Cluster does not achieve the theoretical limits of what is possible with distributed systems, in order to gain certain real world properties.
    • @aliimam: Just so we can fathom the scale of 1B vs 1M: 1,000,000 seconds is 11.5 days. 1,000,000,000 seconds is 31.6 YEARS
    • @kayousterhout: 92% of catastrophic failures in distributed data-intensive systems caused by incorrect error handling … #osdi14
    • @DrQz: 'The purpose of computing is insight, not numbers.' (Hamming) Sometimes numbers ARE the insight so, make them accesible too. (Me)

  • Robert Scoble on the Gillmor Gang said that because of the crush of signups, ello had to throttle invites. Their single PostgreSQL server couldn't handle it captain.

  • Containers are getting much larger with new composite materials. Not that kind of container. Shipping containers. High oil costs have driven ships carrying 5000 containers to evolve. Now they can carry 18,000 and soon 19,000 containers!

  • If you've wanted to make a network game then this is a great start. Making Fast-Paced Multiplayer Networked Games is Hard: Fast-paced multiplayer games over the Internet are hard, but possible. First understanding your constraints then building within them is essential. I hope I have shed some light on what those constraints are and some of the techniques you can use to build within them. No doubt there are other ways out there and ways yet to be used. Each game is different and has its own set of priorities. Learning from what has been done before could help a great deal.

  • Arrival of the Fittest: Solving Evolution's Greatest Puzzle: Environmental change requires complexity, which begets robustness, which begets genotype networks, which enable innovations, the very kind that allow life to cope with environmental change, increase its complexity, and so on, in an ascending spiral of ever-increasing the hidden architecture of life.

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

Categories: Architecture

New daily stand up questions

Xebia Blog - Fri, 10/10/2014 - 15:51

This post provides some alternate standup questions to let your standup be: aimed forward, goal focused, team focused.

The questions are:

  1. What have I achieved since our last SUM?
  2. What is my goal for today?
  3. What things keep me from reaching my goal?
  4. What is our team goal for the end of our sprint day?

The daily stand up runs on a few standard questions. The traditional questions are:

  • What did I accomplish yesterday?
  • What will I be doing today?
  • What obstacles are impeding my progress?

A couple of effects I see when using the above list are:

  • A lot of emphasis is placed on past activities rather than getting the most out of the day at hand.
  • Team members tell what they will be busy with, but not what they aim to complete.
  • Impediments are not related to daily goals.
  • There is no summary for the team relating to the sprint goal.

If you are experiencing the same issues you could try the alternate questions. They worked for me, but any feedback is appreciated of course. Are you using other questions? Let me know your experience. You could use the PDF below to print out the questions for your scrum board.




What Informs My Project Management View

Herding Cats - Glen Alleman - Fri, 10/10/2014 - 15:44

In recent discussion (of sorts) about estimating - Not Estimating actually - I realized something that should have been obvious. I travel in a world not shared by the staunch advocates of #NoEstimates. They appear to be sole contributors. I came top this after reading Peter Kretzman's 3rd installment, where he re-quoted a statement by Ron Jeffries,

Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before.

This is a sole contributor or small team paradigm.

So let's pretend we work at Price/Waterhouse/Cooper and we’re playing our roles  - Peter as CIO advisor, me as Program Performance Management adviser. We've been asked by our new customer to develop a product from scratch, estimate the cost and schedule, and provide some confidence level that the needed business capabilities will be available on or before a date and at or below a cost. Why you ask, because that's in the business plan for this new product and if they're late or overrun the planned cost that will be a balance sheet problem.

What would we do? Well, we'd start with PWC resource management database – held by HR – and ask for “past performance experience” people in the business domain and the problem domain. Our new customer did not “invent” a new business domain, so it's likely we'll find people who know what our new customer does for money. We’d look to see where in the 195,433 people in the database that work for PWC world wide there is someone, somewhere, that knows what the customer does for money and what kinds of business capabilities this new system needs to provide. If there is no one, then we'd look in our 10,000 or so partner relationships database to find someone.

If we found no one who knows the business and the needed capabilities, we’d no bid.

This notion of “I've been asked to do something that’s never been done before, so how can I possibly estimate it” really means “I'm doing something I’ve never done before.” And since “I’m a sole contributor, the population of experience in doing this new thing for the new customer is ONE – me." So since I don't know how the problem has been solved in the past, I can't possibly know how to estimate the cost, schedule, and needed capabilities. And of course I'm absolutely correct to say - new development with unknown requirements can't be estimated. Because those unknown requirements are actually Unknown to me, but may be known to another. But in the population of 195,000 other people in our firm, I'm no longer alone in my quest to come up with an estimate.

So the answer to the question, “what if we encounter new and unknown needs, how can we estimate?” is actually a core problem for the sole contributor, or small team. It'd be rare that the sole contributor or small team would have encountered the broad spectrum of domains and technologies needed to establish the necessary Reference Classes to address this open ended question. This is not the fault of the sole contributor. It is simply the situation of small numbers versus large numbers.

This is the reason the PWC’s of the world exist. They get asked to do things the sole contributors never have an opportunity to see.

Related articles Software Requirements Are Vague
Categories: Project Management

The Last Assignment

Phil Trelford's Array - Fri, 10/10/2014 - 08:53

Back in November last year, my eldest son and I popped over to the Insomnia Gaming Festival in Telford to take part in a game jam organised by Global GameCraft. (Today I  bumped into the source again on a USB stick).

The theme for the day was “The Last Assignment”. We decided to go with a text based adventure game loosely based on the Dirty Harry movie.

With just 7 hours on the clock we managed to put together quite a fun adventure game with ambient sound and graphics:

The Last Assignment - Start Screen

and picked up the prize for best storyline!

The Last Assignment - Insomnia Telford

Given the time constraints I decided to build the dialogue as a simple state machine using coroutines. In this scenario C# was my go to language as it provides basic iterator block support and a first class goto statement.

By building the game dialogue as a simple state machine I was able test it from the start as a console app and later easily integrate it into a graphical environment.

Here’s the state machine for the rookie scene:

public static IEnumerable<State> Rookie()
   yield return new State(
         "One way or another this will be your last assignment.\r\n" +
         "Just 2 weeks left on the force before you retire.\r\n" +
         "Back at the police station",
         "You get a black coffee and a donut",
         "A chai latte and a cup cake") { Theme="70s reflective;bullpen"};
   if (Choice.Taken == 2) goto imposter;
   yield return new State(
         "Your new partner introduces himself.",
         "You give him a stern look",
         "Ignore him") { Theme = "70s reflective;bullpen" };
   yield return new State(
         "\"Why do they call ya 'Dirty Harry'?\"",
         "Make up your own mind kid",
         "Turn up your eye brow"
         ) { Theme = "70s reflective;bullpen" };
   yield break;
   Game.Ended = true;
   yield return new State(
         "You have been exposed as an imposter.\r\n" +
         "Cops don't chai latte, keep it real!")
         { Theme = "end game mp3;bullpen" };


which looked like this:

Rookie Scene

If you fancy having a play, the source for the game as a console app is available here:

Have fun!

Categories: Programming

The LGPL on Android

Xebia Blog - Fri, 10/10/2014 - 08:11

My client had me code review an Android app built for them by a third party. As part of my review, I checked the licensing terms of the open source libraries that it used. Most were using Apache 2.0 without a NOTICE file. One was using the GNU Lesser General Public License (LGPL).

My client has commercial reasons to avoid Copyleft-style licenses and so I flagged the library as unusable. The supplier understandably was not thrilled about the rework that implied and asked for an explanation and ideally some way to make it work within the license. Looking into it in more detail, I'm convinced that if you share my client's concerns, then there is no way to use LGPL licensed code on Android. Here's why I believe this to be the case.


When I first encountered the LGPL years ago, it was explained to me as “the GPL, without the requirement to publish your source code”. The actual license terms turn out to be a bit more restrictive. The LGPL is an add-on to the full GPL that weakens (only) the restrictions to how you license and distribute your work. These weaker restrictions are in section 4.

Here's how I read that section:

You may convey a Combined Work under terms of your choice that […] if you also
do each of the following:
  a) [full attribution]
  b) [include a copy of the license]
  c) [if you display any copyright notices, you must mention the licensed Library]
  d) Do one of the following:
    0) [provide means for the user to rebuild or re-link your application against
       a modified version of the Library]
    1) [use runtime linking against a copy already present on the system, and allow
       the user to replace that copy]
  e) [provide clear instructions how to rebuild or re-link your application in light
     of the previous point]

The LGPL on Android

An Android app can use two kinds of libraries: Java libraries and native libraries. Both run into the same problem with the LGPL.

The APK file format for Android apps is a single, digitally signed package. It contains native libraries directly, while Java libraries are packaged along with your own bytecode into the dex file. Android has no means of installing shared libraries into the system outside of your APK, ruling out out (d)(1) as an option. That leaves (d)(0). Making the library replaceable is not the issue. It may not be the simplest thing, but I'm sure there is some way to make it work for both kinds of libraries.

That leaves the digital signature, and here's where it breaks down. Any user who replaces the LGPL licensed library in your app will have to digitally sign their modified APK file. You can't publish your code signing key, so they have to sign with a different key. This breaks signature compatibility, which breaks updates and custom permissions and makes shared preferences and expansion files inaccessible. It can therefore be argued that such an APK file is not usable in lieu of the original app, thus violating the license.

In short

The GNU Lesser General Public License ensures that a user has freedom to modify a so licensed library used by your application, even if your application is itself closed source. Android's app packaging and signature requirements are such that I believe it is impossible to comply with the license when using an LGPL licensed library in a closed source Android app.

Team Backlogs

If it isn't on the list, it won't get done.

If it isn’t on the list, it won’t get done.

The team backlog is comprised of everything a team might get done because if it is not on the list, it can’t be prioritized and taken into a sprint. Simply put, if it isn’t on the list there is no chance of it will get done. The attributes of the team backlog are:

  1. The backlog includes all potential work items of the team. Work items will include user stories, non-functional requirements, technical items, architectural requirements, issues and risks. Note: All of these can use the user story construct for communication and presentation.
  2. Backlog items represent possibilities. Until the team’s product owner prioritizes an item and the team accepts the item into a sprint, it is merely an opportunity that may get done.
  3. Backlog items should be estimated. An estimate reflects the level of effort required to complete the work item based the definition of done and the work items acceptance criteria. Until it si accepted into the sprint, having an estimate is not a sign that the work item has been committed to be delivered.
  4. The product owner owns the backlog. The product owner prioritizes that backlog therefore controls what the team works on (product owner is a member of the team). In programs, the product owner helps to channel the programs priorities.
  5. The backlog is groomed. Grooming includes ensuring that backlog items are:
    • Well formed,
    • Understood,
    • Estimated,
    • Prioritized, and
    • When necessary removed.

Disclaimer: I am a list person. I have lots of them. I have not descended into lists of lists, albeit I do have a folder in Evernote of lists. Backlogs are the queue of work that a team will draw from. Backlogs, like any list, can feel like they are the end in their own right; almost a form of tyranny. I heard it said, “What is the reward for completing a user story? Another user story.” The backlog can seem relentless. However grooming, prioritization and sprint planning ensures that the team works on what is important and valuable. The backlog is merely a tool to make sure nothing is inadvertently forgotten or ignored.

Categories: Process Management

Level One: The Intro Stage

Coding Horror - Jeff Atwood - Thu, 10/09/2014 - 23:21

Way back in 2007, before Stack Overflow was a glint in anyone's eye, I called software development a collaborative game. And perhaps Stack Overflow was the natural outcome of that initial thought – recasting online software development discussion into a collaborative game where the only way to "win" is to learn from each other.

That was before the word gamification existed. But gamification is no longer the cool, hip concept it was back in 2011. Still, whether you call yourself a "gamer" or not, whether you believe in "gamification" or not, five years later you're still playing the world's largest multiplayer game.

In fact, you're playing it right now.

One of the most timeless aspects of games is how egalitarian they are, how easy it is for anyone to get started. Men, women, children — people love games because everyone can play along. You don't have to take classes or go to college or be certified: you just play. And this is, not so incidentally, how many of the programmers I know came to be programmers.

Do you know anyone that bought the video game Halo, or Myst, then proceeded to open the box and read the manual before playing the game? Whoa there guys, we can't play the game yet, we gotta read these instructions first! No, they stopped making manuals for games a long time ago, unless you count the thin sheet of paper that describes how to download / install the game on your device. Because they found out nobody reads the manual.

The project I’m working on is critical, but it has only about 3 to 4 users, most of whom are already familiar the application. One of the users even drives the design. The manual I’m writing, which is nearly 200 pages, is mostly a safety measure for business continuity planning. I don’t expect anyone will ever read it.

It’s a project I managed to procrastinate for months, working on other projects, even outside the scope of my regular assignments. The main deterrent, I believe, was my perception that no one needed the manual. The users seemed to be getting along fine without it.

And so as the year ticked to a close, instead of learning more about Mediawiki and screencasting and After Effects, I spent my time updating a 200-page manual that I don’t think anyone will ever read. It will be printed out, three-hole punched, and placed in a binder to collect dust on a shelf.

I guess that's not surprising for games. Games are supposed to be fun, and reading manuals isn't fun; it's pretty much the opposite of fun. But it is also true for software in general. Reading manuals isn't work, at least, it isn't whatever specific thing you set out to do when you fired up that bit of software on your phone, tablet, or laptop.

Games have another clever trick up their sleeve, though. Have you ever noticed that in most of today's games, the first level is kind of easy. Like… suspiciously easy?

That's because level one, the intro stage, isn't really part of the game. It's the manual.

As MegaMan X illustrates, manuals are pointless when we can learn about the game in the best and most natural way imaginable: by playing the actual game. You learn by doing, provided you have a well designed sandbox that lets you safely experiment as you're starting out in the game.

(The above video does contain some slightly NSFW language, but it is utterly brilliant, applies to every app, software and website anyone has ever built, and I strongly recommend watching it all.)

This same philosophy applies to today's software and websites. Don't bother with all the manuals, video introductions, tutorials, and pop-up help dialogs. Nobody's going to read that stuff, at least, not the people who need it.

Instead, follow the lesson of MegaMan: if you want to teach people about your software, consider how you can build a great intro stage and let them start playing with it immediately.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.
Categories: Programming

Software Requirements Are Vague

Herding Cats - Glen Alleman - Thu, 10/09/2014 - 22:23

Peter Kretzman has a nice post in his series on #NoEstimates. Peter and I share a skepticism of "making decisions in the absence of estimating the cost and impact" of those decisions. In Peter's current post there is a quote that is telling.

Let’s use Ron Jeffries’ statement as an example of this stance:

“Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. “

One of my 3 half time jobs is working in the space and defense program performance management domain, both embedded systems and enterprise IT systems. DOD is the largest buyer of ERP on the planet. In this domain we have a formal process for determining what went wrong. The department looking after this is called Performance Assessment and Root Cause Analysis (PARCA). PARCA provides Root Cause Analysis for programs that have gone Nunn McCurdy as we would say. 

When you read the reports from Rand and Institute for Defense Analyses on N-M breaches, requirements instability is in the top 5 as root causes

It seems to me - in my narrow minded program performance management view of the world - that unstable requirements being used as the reason for vague estimates is so obvious a problem that has been completely ignored by the #NoEstimates advocates. It's like the olde saw

Doctor, Doctor it hurts when I do this (make estimates in the presence of vague requirements). Then stop doing that!

The notion of Capabilities Based Planning is missing in many software organizations. So having vague requirements is a natural outcome of not having definitive understanding of what Capabilities the system must provide, in units of measure meanigful to the decision makers. These units are:

  • Measures of Effectiveness  - are the 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. MOE's are stated in units meaningful to the buyer, focus on capabilities independent of any technical implementation, are connected to the mission success.
  • Measures of Performance - characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. Measures of Performance are attributes that assure the system has the capability and capacity to perform, and assess the system to assure it meets design requirements to satisfy the MoE.

Without these requirements have not home, are vague, and therefore create the root cause of bad estimates.

So what would a logical person do when working on a project that spends other peoples money, sometimes lots of other peoples money? Not Estimate? Does that sound like the corrective action to the root cause of the problems with software project success shortfall?

Not to me. It's the doctor, doctor this hurts paradigm. So until the root cause is determined, the corrective actions identified and applied, there can be no credible solution to the estimating problem. And there is a huge estimating problem in our domain, just read the N-M reports at RAND and IDA (Goggle nunn-mcurdy Rand or IDA to find them). Similar assessments of root causes can be found for enterprise IT from many sources. 

The #NoEstimates advocates are attempting to solve the wrong problem with the wrong approach. They've yet to connect with the core process of writing software for money - MicroEconomics of software development. Here's a starting point to address the root casue rather than the symptom. Fixing the symptoms does nothing in the end. It just spends money, with no actonable outcomes. And that woudl be very counter to the principles of Agile.

Capabilities based planning (v2) from Glen Alleman


Related articles Who pays? No Estimates Needs to Come In Contact With Those Providing the Money #NoEstimates? #NoProjects? #NoManagers? #NoJustNo
Categories: Project Management

Waterfall and Agile- An Engineer’s Perspective

Software Requirements Blog - - Thu, 10/09/2014 - 17:00
Last time I talked about validation and verification and how they apply to both software requirements and engineering. Today, I’d like to cover another topic we talk about in our training and how it relates to engineering; software development lifecycles (SDLC) for Waterfall and Agile. Again, to begin, I’d like to start with the definition […]
Categories: Requirements

How I Plan My Week

Making the Complex Simple - John Sonmez - Thu, 10/09/2014 - 15:00

Want to know how I plan my week to get as much done as possible? Here it is. I use a tool called Kanbanflow to plan out my week based on Pomodoros. Using this technique I am able to be extremely productive, avoid distractions and know exactly what I’ll be able to get done each […]

The post How I Plan My Week appeared first on Simple Programmer.

Categories: Programming

Function references in Swift and retain cycles

Xebia Blog - Thu, 10/09/2014 - 14:49

The Swift programming language comes with some nice features. One of those features are closures, which are similar to blocks in objective-c. As mentioned in the Apple guides, functions are special types of closures and they too can be passed around to other functions and set as property values. In this post I will go through some sample uses and especially explain the dangers of retain cycles that you can quickly run into when retaining function pointers.

Let's first have a look at a fairly simple objective-c sample before we write something similar in Swift.


We will create a button that executes a block statement when tapped.

In the header file we define a property for the block:

@interface BlockButton : UIButton

@property (nonatomic, strong) void (^action)();


Keep in mind that this is a strong reference and the block and references in the block will be retained.

And then the implementation will execute the block when tapped:

#import "BlockButton.h"

@implementation BlockButton

-(void)setAction:(void (^)())action
    _action = action;
    [self addTarget:self action:@selector(performAction) forControlEvents:UIControlEventTouchUpInside];

-(void)performAction {


We can now use this button in one of our view controllers as following:

self.button.action = ^{
    NSLog(@"Button Tapped");

We will now see the message "Button Tapped" logged to the console each time we tap the button. And since we don't reference self within our block, we won't get into trouble with retain cycles.

In many cases however it's likely that you will reference self because you might want to call a function that you also need to call from other places. Let's look as such an example:

-(void)viewDidLoad {
    self.button.action = ^{
        [self buttonTapped];

-(void)buttonTapped {
    NSLog(@"Button Tapped");

Because our view controller (or it's view) retains our button, and the button retains the block, we're creating a retain cycle here because the block will create a strong reference to self. That means that our view controller will never be deallocated and we'll have a memory leak.

This can easily be solved by using a weak reference to self:

__weak typeof(self) weakSelf = self;
self.button.action = ^{
    [weakSelf buttonTapped];

Nothing new so far, so let's continue with creating something similar in Swift.


In Swift we can create a similar Button that executes a closure instead of a block:

class ClosureButton: UIButton {

    var action: (() -> ())? {
        didSet {
            addTarget(self, action: "callClosure", forControlEvents: .TouchUpInside)

    func callClosure() {
        if let action = action {

It doing the same as the objective-c version (and in fact you could use it from objective-c with the same block as before). We can assign it an action from our view controller as following:

button.action = {
    println("Button Tapped")

Since this closure doesn't capture self, we won't be running into problems with retain cycles here.

As mentioned earlier, functions are just a special type of closures. Which is pretty nice, because it lets us reference functions immediately like this:

override func viewDidLoad() {
    button.action = buttonTapped

func buttonTapped() {
    println("Button Tapped")

Nice and easy syntax and good for functional programming. If only it wouldn't give us problems. Without it being immediately obvious, the above sample does create a retain cycle. Why? We're not referencing self anywhere? Or are we? The problem is that the buttonTapped function is part of our view controller instance. So when the button.action references to that function, it creates a strong reference to the view controller as well. In this case we could fix it by making buttonTapped a class function. But since in most cases you'll want to do something with self in such a function, for example accessing variables, this is not an option.

The only thing we can do to fix this is to make sure that the button won't get a strong reference to the view controller. Just like in our last objective-c sample, we need to create a weak reference to self. Unfortunately there is no easy way to simply get a weak reference to our function. So we need a work around here.

Work around 1: wrapping in closure

We can create a weak reference by wrapping the function in a closure:

button.action = { [weak self] in

Here we first create a weak reference of self. And in Swift, weak references are always optional. That means self within this closure is now an optional and need to unwrap it first, which is what the exclamation mark is for. Since we know this code cannot be called when self is deallocated we can safely use the ! instead of ?.

A lot less elegant than immediately referencing our function immediately.

In theory, using an unowned reference to self should also work as following:

button.action = { [unowned self] in

Unfortunately (for reasons unknown to me) this crashes with a EXC_BAD_ACCESS upon deallocation of the ClosureButton. Probably a bug.

Work around 2: method pointer function

Thanks to a question on StackOverflow about this same problem and an answer provided by Rob Napier, there is a way to make the code a bit more elegant again. We can define a function that does the wrapping in a closure for us:

func methodPointer<T: AnyObject>(obj: T, method: (T) -> () -> Void) -> (() -> Void) {
    return { [weak obj] in

Now we can get a weak reference to our function a bit easier.

button.action = methodPointer(self, ViewController.buttonTapped)

The reason this works is because you can get a reference to any instance function by calling it as a class function with the instance (in this case self) as argument. For example, the following all does the same thing:

// normal call

// get reference through class
let myFunction = MyViewController.buttonTapped(self)

// directly through class

However, the downside of this is that it only works with functions that take no arguments and return Void. i.e. methods with a () -> () signature, like our buttonTapped.

For each signature we would have to create a separate function. For example for a function that takes a String parameter and returns an Int:

func methodPointer<T: AnyObject>(obj: T, method: (T) -> (String) -> Int) -> ((String) -> Int) {
    return { [weak obj] string in

We can then use it the same way:

func someFunction() {
    let myFunction = methodPointer(self, MyViewController.stringToInt)
    let myInt = myFunction("123")

func stringToInt(string: String) -> Int {
    return string.toInt()
Retain cycles within a single class instance

Retain cycles do not only happen when strong references are made between two instances of a class. It's also possible, and probably less obvious, to create a strong reference within the same instance. Let look an an example:

var print: ((String) -> ())?

override func viewDidLoad() {
    print = printToConsole

func printToConsole(message: String) {

Here we do pretty much the same as in our button examples. We define an optional closure variable and then assign a function reference to it. This creates a strong reference from the print variable to self and thus creating a retain cycle. We need to solve it by using the same tricks we used earlier.

Another example is when we define a lazy variable. Since lazy variables are assigned after initialisation, they are allowed to reference self directly. That means we can set them to a function reference as following:

lazy var print: ((String) -> ()) = self.printToConsole

Of course this also creates a retain cycle.


To avoid creating retain cycles in Swift you should always remember that a reference to an instance function means that you're referencing the instance as well. And thus when assigning to a variable, you're creating a strong reference. Always make sure to wrap such references in a closure with a weak reference to the instance or make sure to manually set the variables to nil once you're done with them.

Unfortunately Swift does not support weak closure variables, which is something that would solve the problem. Hopefully they will support it in the future or come up with a way to create a weak reference to a function much like we can use [weak self] now in closures.

Small Internal Releases Lead to Happy Customers

If you saw Large Program? Release More Often, you might have noted that I said,

You want to release all the time inside your building. You need the feedback, to watch the product grow.

Some of my clients have said, “But my customers don’t want the software that often.” That might be true.  You may have product constraints, also. If you are working on a hardware/software product, you can’t integrate the software with the hardware either until the hardware is ready or that often.

I’m not talking about releasing the product to the customers. I’m not talking about integrating the software with the hardware. I’m talking about small, frequent, fully functional releases that help you know that your software is actually done.

You don’t need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don’t believe in hardening sprints.

Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can’t finish the tests. Your testers might not be automating enough. Let’s not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn’t you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix.

Here’s an example. I have a number of clients who develop software for the education market.  One of them said to me, “We can’t release all the time.”

I said, “Sure, you can’t release the grading software in the middle of the semester. You don’t want to upset the teachers. I get that. What about the how-to-buy-books module? Can you update that module?”

“Of course. That’s independent. We’re not sure anyone uses that in the middle of the semester anyway.”

I was pretty sure I knew better. Teachers are always asking students to buy books. Students procrastinate. Why do you think they call it “Student syndrome”? But I decided to keep my mouth shut. Maybe I didn’t know better. The client decided to try just updating the buy-the-book module as they fixed things.

The client cleaned up the UI and fixed irritating defects. They released internally every two weeks for about six weeks. They finally had the courage to release mid-semester. A couple of schools sent emails, asking why they waited so long to install these fixes. “Please fix the rest of these problems, as soon as you can. Please don’t wait.”

The client had never released this often before. It scared them. It didn’t scare their customers. Their customers were quite happy. And, the customers didn’t have all the interim releases; they had the planned mini-releases that the Product Owner planned.

My client still doesn’t release every day. They still have an internal process where they review their fixes for a couple of weeks before the fixes go live. They like that. But, they have a schedule of internal releases that is much shorter than what they used to have. They also release more often to their customers. The customers feel as if they have a “tighter” relationship with my client. Everyone is happier.

My client no longer has big-bang external releases. They have many small internal releases. They have happier customers.

That is what I invite you to consider.

Release externally whenever you want. That is a business decision. Separate that business decision from your ability to release internally all the time.

Consider moving to a continuous delivery model internally, or as close as you can get to continuous delivery internally. Now, you can decide what you release externally. That is a business decision.

What do you need to do to your planning, your stories, your technical practices to do so?

Categories: Project Management

How to Estimate Software Development - Update

Herding Cats - Glen Alleman - Thu, 10/09/2014 - 02:49

There is a popular quote used by many in the #NoEstimates community, that is sadly misinformed.

Those who have knowledge, don’t predict. Those who predict, don’t have knowledge. − Lao Tseu

This of course was from a 6th Century BC Chinese philosopher, who was not likely familiar with the notion of probability and statistics developed some 900 years later. The quoting and re-quoting of Lao Tseu as an example of why estimates can't be made brings to light one of the more troublesome aspects of our modern age.

The lack of understanding of basic probability and statistics when applied to human endeavors.

Or possibly the intentional ignorance of probability and statistics as it is applied to the development of software systems. I can't really say if it is for lack of understanding, lack of exposure, or just a simple intent to ignore. 

But for any of those reasons and more, here's a starting point on how to actually become a member of the modern of statistical estimating community, once it is decided that is better than ignoring the basic knowledge needed to be a steward of other peoples money.

Here's some starting points in no particular order, other than that's how they came off the office book shelf.

These are just a small sample of the information readily available at your local book store or through the mail. If you google "software cost estimating," (all in quotes) there will be 100's of more articles, papers, and web sites. As well tools for estimating software are used every single day in a variety of domains. 

The Value at Risk is a starting point as well. Low value - this is defined by those providing the money, not by those doing the work, and low risk - this usually defined by those doing the work, not by those providing the money - at least in the domains we work. This Value at Risk, sets the tone. Low Value, Low Risk - and this is in absolutely no way an assessment of the relative value and risk - usually doesn't need much estimating.

Got a 6 week, 2 person database update project. Just do it. Got a 38 month, 400 person National Asset sofwtare project, probably so. Everything and anything in between needs to ask and answer that value at risk question before deciding. 

So poor Mr. Tzu was sadly informed when he made his quote. As are those repeating it. In the 21 century

Those who have knowledge of probability, statistics, and the processes described by them can predict their future behaviour. Those without this knowledge, skills, or experience cannot.

Related articles How to Estimate Software Development
Categories: Project Management

SAFe and the Release Planning Event

Step out of the chaos!

Step out of the chaos!

Information technology projects are typically a bit chaotic due to interaction of people, the environment and the inherent complexity of software and hardware. The bigger the project, the more complex and chaotic the project becomes. Unfortunately, all products and services can’t be delivered based on the output of a single small team or even a swarm of independent small teams. Coordination and group thinking is required to deliver large projects. Scaled Agile Framework Enterprise (SAFe) addresses this coordination and planning need with a period release planning event. Release planning is one the lightning rods in the discussion of scaled Agile frameworks overall and SAFe in particular.

In SAFe, release planning is done as a large-scale event for each program increment (a period of time typically spanning 8 – 12 weeks). The goal of the of the two-day release planning event is not only to synchronize and energize everyone that is working on the project, but also to assure a coordinated approach to delivering value. A few of the critical success factors for this group planning and coordination activity are:

  1. Release planning is a formal meeting with an agenda and roles. Preparation must occur before participants begin showing up the first day of the meeting. Typically the program’s vision and linkage to the business objectives and the top priorities of the initial program/feature backlog are used as inputs into the event. The release train engineer (who facilitates the event) will need ensure that the workspace and tools the teams will use are prepared.
  2. All members of the program should participate in the release planning event. Release planning is both a planning and coordination event. In the release planning event, teams develop and coordinate their plans for the next set of sprints in an environment that actively encourages communication and sharing. Everyone involved in the program brings different skills and experiences to the table; therefore they can provide unique insights into how the program can deliver maximum value. For example, if a program based in the US was leveraging offshore developers in the Ukraine and testers in India would planning be as effective if team members in India and the Ukraine were excluded and just told the plan? How many challenges and issues would be exposed later in as functionality was delivered that could have been solved by upfront communication?
  3. Release planning events are best when done in person. Programs need to ensure that release planning events are scheduled and that budget is available. Budgets for the events should include travel both travel and logistics.   When travel is not possible, the program leadership should make every effort to make the communication as intimate as possible (in-person being the most intimate and then in descending order: video, audio, test chats and smoke signals). Remember that if it is difficult to hear and participate, participants will get bored and stop paying attention.

A classic advertisement during in 2009 Super Bowl showed a cowboys herding cats. Large projects might not be quite as chaotic as that, however if teams don’t have a clear vision or don’t understand the interactions and relationships between what they are delivering and what others are delivering chaos could ensue. The Agile release planning event in SAFe is a mechanism for solving the planning and communication conundrum.

Categories: Process Management

Google Play Services 6.1

Android Developers Blog - Wed, 10/08/2014 - 19:05

Google Play services 6.1 is now rolled out to devices worldwide, bringing you the newest features from Google to help you optimize your apps. You can get started developing today by downloading the Google Play services SDK from the Android SDK Manager.

Google Play services 6.1 adds Enhanced Ecommerce analytics support from Google Tag Manager and offers new improvements to the Google Drive Android API. With the latest release, we’re also including a refresh of the Google Fit developer preview, so that you can test your fitness apps on any Android device.


Launched in Google Play services 5.0, Enhanced Ecommerce is an analytics extension designed to provide richer insights into pre-purchase shopping behavior and into product performance. It’s a great way to gain visibility into the full customer journey, helping you understand how different user acquisition campaigns are performing at a granular level. By including support for Enhanced Ecommerce in Google Tag Manager with the latest release of Google Play services, we are supercharging your ability to regularly update and manage tags on mobile apps more easily, so that you can consistently measure product impressions, shopping funnel events, and more.


To make it easier to use Drive, we added enhancements to the Google Drive Android API. With the new Completion Events feature, you can see when actions are committed to the server and improve the response time to conflicts. Material design elements have been incorporated into the File Picker UI, along with the addition of Recent and Starred views. A new setParents() method enables you to organize files and folders, while the previous Contents class has been replaced with a simpler DriveContents class.

Learn more about how to use these new features in this DevBytes video.

Google Fit

Initially introduced in August, the Google Fit Developer Preview has been refreshed to enable you to test your new fitness apps on any Android device. We expect to make additional changes to the APIs, so please check back with us on new developments.

Get Started

To get started developing, download the latest Google Play services SDK from the Android SDK Manager. For details on the new APIs, take a look at the New Features documentation. For setup information, see Set Up Google Play Services SDK.

To learn more about Google Play services and the APIs available to you through it, visit the Google Services section on the Android Developers site.

We hope you enjoy this release of Google Play services!

Join the discussion on
+Android Developers

Categories: Programming

That's Not My Problem - I'm Renting Them

Scott Hanselman gives a hilarious and insightful talk in Virtual Machines, JavaScript and Assembler, a keynote at Velocity Santa Clara 2014. The topic of his talk is an intuitive understanding of the cloud and why it's the best thing ever. 

At about 6:30 into the video Scott is at his standup comic best when he recounts a story of a talk Adrian Cockroft gave on Netflix’s move to SSDs. An audience member energetically questioned the move to SSDs saying they had high failure rates and how moving to SSDs was a stupid idea.

To which Mr. Cockroft replies:

That's not my problem, I'm renting them.

Scott selected the ideal illustration of the high level of abstraction the cloud provides. If you are new to the cloud that's a very hard idea to grasp. "That's not my problem, I'm renting them" is the perfect mantra when you find yourself worried about things you don't need to be worried about anymore.

Categories: Architecture

Emotional Intelligence is a Key Leadership Skill

You probably already know that emotional intelligence, or “EQ”, is a key to success in work and life.

Emotional intelligence is the ability to identify, assess, and control the emotions of yourself, others, and groups.

It’s the key to helping you respond vs. react.  When we react, it’s our lizard brain in action.  When we respond, we are aware of our emotions, but they are input, and they don’t rule our actions.  Instead, emotions inform our actions.

Emotional intelligence is how you avoid letting other people push your buttons.  And, at the same time, you can push your own buttons, because of your self-awareness.  

Emotional intelligence takes empathy.  Empathy, simply put, is the ability to understand and share the feelings of others. 

When somebody is intelligent, and has a high IQ, you would think that they would be successful.

But, if there is a lack of EQ (emotional intelligence), then their relationships suffer.

As a result, their effectiveness, their influence, and their impact are marginalized.

That’s what makes emotional intelligence such an important and powerful leadership skill.

And, it’s emotional intelligence that often sets leaders apart.

Truly exceptional leaders, not only demonstrate emotional intelligence, but within emotional intelligence, they stand out.

Outstanding leaders shine in the following 7 emotional intelligence competencies: Self-reliance, Assertiveness, Optimism, Self-Actualization, Self-Confidence, Relationship Skills, and Empathy.

I’ve summarized 10 Big Ideas from Emotional Capitalists: The Ultimate Guide to Developing Emotional Intelligence for Leaders.  It’s an insightful book by Martyn Newman, and it’s one of the best books I’ve read on the art and science of emotional intelligence.   What sets this book apart is that Newman focused on turning emotional intelligence into a skill you can practice, with measurable results (he has a scoring system.)

If there’s one take away, it’s really this.  The leaders that get the best results know how to get employees and customers emotionally invested in the business.  

Without emotional investment, people don’t bring out their best and you end up with a brand that’s blah.

You Might Also Like

10 Emotional Intelligence Articles for Effectiveness in Work and Life

Emotional Intelligence Quotes

Positive Intelligence at Microsoft

Categories: Architecture, Programming

Large Program? Release More Often

I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month.

Yes, have a real, honest-to-goodness release once a month.

I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?”

Okay, release every three weeks. I’m easy.

Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum.

Large programs magnify this problem.

If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly.

Here’s what you do:

  1. Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks.
  2. If you have three-week iterations, plan to release every three weeks.
  3. Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams complete one feature in one iteration or in flow.
  4. The teams integrate all the time. No staged integration.

Remember this picture, the potential for release frequency?

Potential Release Frequency

Potential for Release Frequency

That’s the release frequency outside your building.

I’m talking about your internal releasing right now. You want to release all the time inside your building. You need the feedback, to watch the product grow.

In agile, we’re fond of saying, “If it hurts, do it more often.” That might not be so helpful. Here’s a potential translation:  “Your stuff is too big. Make it smaller.”

Make your release planning smaller. Make your stories smaller. Integrate smaller chunks at one time. Move one story across the board at one time. Make your batches smaller for everything.

When you make everything smaller (remember Short is Beautiful?), you can go bigger.

Categories: Project Management

Unboxing FP

Phil Trelford's Array - Wed, 10/08/2014 - 07:39

How hard is it to get started in functional programming?

Let’s have a look at how quickly you can get started on a selection of simple expression-oriented programming languages.

Today let’s try Clojure, Elm, F#, Haskell and OCaml.

Online REPL

No install required just point your browser at a URL and you’re off:

Language Online REPL Clojure F# Elm Haskell OCaml


Each language has an easy to use online REPL with simple lessons to get you through the basics. Elm’s online offering lets you edit multi-line programs, as does Try F#, which also includes intellisense in the online editor.

Development environment

Now you’ve covered the basics you probably want to install a lightweight development environment and start building larger programs:


I found LightTable very quick to install and setup. The editor comes with psychedelic colours to help you track opening and closing parenthesis:

FizzBuzz Clojure

I’ve been using Stuart Holloway’s Programming Clojure book as a guide.


Elm has a very usable online editor, a simple installable REPL, and a wonderful playground feature with Elm Reactor:


If you’re on Windows and have Visual Studio installed then you’ve already got F#. From the file menu click New and select a new F# project or script file.

No Visual Studio, no problem, for Windows the Tsunami IDE is a fast 25MB download, which gives you the latest compiler and an editor with intellisense:

Tsunami IDE

On Mac I’d recommend Xamarin Studio and for Linux MonoDevelop or Emacs.

Functional Programming using F# and Dave Fancher’s recent Book of F# are both great introductory texts.


The Haskell platform gives you a compiler and REPL from a simple 100MB install. A combination of a text editor along with the REPL gets you going in no time:

Haskell FizzBuzz

As a guide I’ve been using the Real World Haskell book. Learn you an Erlang some Haskell for great good! looks like a fun read too.


Like Haskell, OCaml is bundled in a simple installer and includes the compiler and REPL. Choose your own editor and use the REPL to explore your programs.

I recently picked up OCaml from the Very Beginning and More OCaml, which are both nice concise introductions.

OCaml From The Very BeginningMore OCaml


Using an online REPL you can get started with any of these languages in seconds, and there are plenty of lightweight install options too. Combine that with a good selection of learning resources from books to online courses, and we can conclude that nowadays it’s really not that hard to get started with FP.

Categories: Programming