I’ve been checking out a number of teams and what their workloads look like. I’ve of course worked on more than few with completely disparate practices and policies. Some where really good at making great progress and others were absolutely horrendous. I’d argue one team actually went backwards in progress more than a few times. Suffice it to say, I’ve seen a whole lot of the bad and a fair amount of amazing teams. I’ve been fortunate in doing so as it really helps to have a solid perspective in both arenas.

To summarize, it’s nice to know when the ship is sinking and when the ship is sailing full steam toward the destination!

Quick context:  I’m generally referring to a Product Backlog and or a Sprint Backlog.

Work in Progress Versus Backlog

Today I got to thinking and I realized I need to keep things in perspective. Especially, when thinking from the CTO perspective, about what I need to do versus what the rest of the team needs to do. As I slowly build out a team the focus from code to vision comes into stark contrast.

I started to ponder a very tactical concern. When and how does one manage their backlog without it becoming waste within the team that’s actually doing the work? How does one manage team buy in without getting them burned out thinking about higher level, often changing problems? Does one force the backlog to just not change or does one actively prune the backlog at each work effort? Why not just keep things active, forget the backlog, and build up what needs done at the beginning of each work effort? But at the same time ensuring they have vested interest to the actual high level architectural and design of the software they’re building?

These don’t have immediate and straight forward answers, but here’s a few thoughts based on experience and a good idea about what may or may not work.

• Backlogs are great for brainstorming. But they shouldn’t be set in stone.
• Backlogs should be flexible, but they shouldn’t be so abstract and flexible as the work never gets tackled.
• Backlogs shouldn’t be used to store every single wish list item. A backlog should stay active from many perspectives, to maintain its relevancy but also not to damage morale.

But are these things achievable with a backlog?

Backlogs

Backlogs are great if they’re used for brainstorming and determining the way a product is moving. They can be used among the leadership to determine, mixed in with a good dose of marketing information and company mission, the direction of the efforts of the company. However, I have seen far to many times where the actual team of developers that is working to build the product just has their time wasted when leadership brings in a backlog and says “pull tasks from this” or “pull your stories from this”.

Why do I feel this might be a waste? Because most of the backlog, based on most development teams, never actually gets completed. Most of it never even begins to be worked on. I’ve seen it happen, heard complaints to no end, and seen teams spin out of control.

The backlog ends up being a list of things that will be circumvented until the next sprint or call to action. Then at the end the backlog will be reviewed, a bunch of things will change, a bunch of other things will be added to the backlog, and the list of things to work on for the next iteration or sprint is created while actually ignoring the original backlog. This happens far too often.

So my question is, where do you break out your backlog? How do you keep a backlog useful on your team? Do you even use a backlog? How do you encourage brain storming versus just tossing things in a backlog, only to just decide what to do next based on what was just done? How does one manage work in progress (WIP) of the backlog versus WIP of the day to day stories and tasks that need completed?

I’ve just been pondering this lately and would be very interested in seeing some other’s thoughts. -Cheers

Ah, part 2! If you’re looking for part 1, click this link.

Review: In the last blog entry I went through more than a few examples of using cURL to issue GET requests against various end points using Node.js & Restify. I also covered the basics on where to go to find cURL in case it isn’t installed. The last part I covered was a little bit of WebStorm info to boot. In this part of the series I’m now going to dive into the HTTP verbs beyond GET.

POST

The practice around issuing a command via http verb to save data is via a post. When you issue a post via cURL use the -X followed by POST to designate a post verb, then -H to assign the content type parameter. In this particular example I’ve set it to application/json since my payload of data will be JSON format. Then add the final data with a -d option, followed by the actual data.

curl -X POST -H "Content-Type: application/json" -d '{"uuid":"79E5591A-1E54-4562-A276-AFC266F54390","webid":"56E62C3A-D6BC-4F4F-B72A-E6CE081190B6"}' http://localhost:3000/ident%5B/sourcecode%5D

Other data types can be sent, which the content type can be appropriately set for including; html, json, script, text or html. One example of this same command, issued with jQuery on the client side would actually look like this.

[sourcecode language="javascript"]
var data = {"uuid":"79E5591A-1E54-4562-A276-AFC266F54390","webid":"56E62C3A-D6BC-4F4F-B72A-E6CE081190B6"};

$.post( "http://localhost:3000/ident", function( data ) {
  $( ".result" ).html( data );
});

When building post end points via express one of the things you may run into is the following message being displayed in the console.

/usr/local/bin/node app.js
connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0

The immediate fix for this, until the changes are made (which may or may not mean to just alwasy  is to replace this line

app.use(express.bodyParser());

with these lines

app.use(express.json());
app.use(express.urlencoded());

So here’s some common examples for use from a great write up on writing basic RESTful APIs with Node.js and Express from the Modulus blog.

var express = require('express');
var app = express();

app.use(express.json());
app.use(express.urlencoded());

var quotes = [
    { author : 'Audrey Hepburn', text : "Nothing is impossible, the word itself says 'I'm possible'!"},
    { author : 'Walt Disney', text : "You may not realize it when it happens, but a kick in the teeth may be the best thing in the world for you"},
    { author : 'Unknown', text : "Even the greatest was once a beginner. Don't be afraid to take that first step."},
    { author : 'Neale Donald Walsch', text : "You are afraid to die, and you're afraid to live. What a way to exist."}
];

app.get('/', function(req, res) {
    res.json(quotes);
});

app.get('/quote/random', function(req, res) {
    var id = Math.floor(Math.random() * quotes.length);
    var q = quotes[id];
    res.json(q);
});

app.get('/quote/:id', function(req, res) {
    if(quotes.length <= req.params.id || req.params.id < 0) {
        res.statusCode = 404;
        return res.send('Error 404: No quote found');
    }

    var q = quotes[req.params.id];
    res.json(q);
});

app.post('/quote', function(req, res) {
    if(!req.body.hasOwnProperty('author') ||
        !req.body.hasOwnProperty('text')) {
        res.statusCode = 400;
        return res.send('Error 400: Post syntax incorrect.');
    }

    var newQuote = {
        author : req.body.author,
        text : req.body.text
    };

    quotes.push(newQuote);
    res.json(true);
});

app.listen(process.env.PORT || 3412);

This is a great little snippet of code to use for testing your curling against just to check out.

References:

• I used the “Develop a RESTful API using Node.js with Express and Mongoose” for some key references. I’ve always found the Express.js Docs a little lacking when it comes to examples in building APIs.
• Another great entry is the Modulus entry on the topic of RESTful APIs.