Study: Young, Single, Childless Women Earn More Than Men – TIME

…according to a new analysis of 2,000 communities by a market research company, in 147 out of 150 of the biggest cities in the U.S., the median full-time salaries of young women are 8% higher than those of the guys in their peer group. In two cities, Atlanta and Memphis, those women are making about 20% more. This squares with earlier research from Queens College, New York, that had suggested that this was happening in major metropolises. But the new study suggests that the gap is bigger than previously thought, with young women in New York City, Los Angeles and San Diego making 17%, 12% and 15% more than their male peers, respectively. And it also holds true even in reasonably small areas like the Raleigh-Durham region and Charlotte in North Carolina (both 14% more), and Jacksonville, Fla. (6%).

via time.com

Wow — I remember working booths with my wife representing the Business and Professional Women just ten years ago where we charged men a dollar for lemonade, but women just 75 cents (to call out the wage disparity). Now I have to ask: where’s my 85 cent lemonade?

The whole thing comes down to education apparently: for every two men to graduate college, three women will graduate.

What happens when it’s all glass? – (37signals)

Apple’s design dominance over the past decade has been due to industrial design first, software design second. Their hardware designs have inspired a generation. Over those last 10 years their software has gotten better and better too (it’s really damn good now), but it’s been their industrial design that has made the first impression on the market.

However, I wonder if Apple will soon lose their perceived industrial design edge. It’s not that they aren’t incredibly good at it — they are the best in the business — it’s that industrial design is trending towards transparency. It’s all going glass. Everything is turning into a screen, from edge to edge. Once it’s all about glass, it’s all about software.

via 37signals.com

This is completely backwards. Apple’s advantage (greater at times, less at others) has always been more about software than hardware. Go to any Best Buy and look at the PC laptops vs. the Apple laptops. The PCs have fingerprint scanners, card readers, special buttons and other bits. The Apples have simplicity of hardware, in service to the software.

This has never been truer than in the case of the iPhone, where the “slab of glass” model makes the software the center of the experience. Whatever advantage Apple has had/has/will have is based on the software. If they continue to lead there, they will succeed. If they don’t, you get Windows 95 vs. Mac OS 7/8/9, and that’s not a winner for Apple.

Multi-burndown charts

I work with exceptionally compressed project timelines. Generally the whole project comes in at about two weeks, debugging and all. In this context Jira’s burndown charts are less than ideal. Here’s an example:

There are a few things wrong here:

• The burndown chart looks increasingly bad for the first few days of the project, then takes a sudden plunge (which is good, but it’s not clear what changed).
• The last several days all look odd because nothing seems to be happening (it looks like the project is done).

The start of the burndown looks the way it does because of the compressed time frame of the project. Some of the tickets are 5 or even 8 points (more than a day) so of course progress is uneven.

Nothing appears to be happening for the last half of the project because that’s when we test the final product; numerous small issues are reported and corrected, and often they don’t get points assigned to them. 

To improve the situation I wrote a tool to generate my own burndown charts.  Compare the above to this:

It’s a stacked area chart that includes a separate line for each possible status a ticket can have. There are several improvements here:

• The weekends are shown, marked in gray. Note how some work is done on the 15th, even though it’s a Sunday. We don’t (often) expect developers to work on weekends, but they sometimes do.
• Burndowns are shown for each possible status of a ticket. The beginning of the project is much clearer: Obviously the developers tackled some larger tickets early on (the quick drop in the “Open” graph) which slowed the progress of tickets to “Closed.” There was a buildup of tickets waiting for peer review as well.
• I show the “Closed” tickets as well as the rest of the statuses. This helps especially when projects grow, either because tickets are burned up or just added. Note the increase of the scope on the 12th and 13th.
• For all tickets with no points assigned, I assume 1 point. That’s where the bug tickets at the end of the project come in. Note how the project grows steadily from the 18th on as bugs are reported. The developers mostly keep up with the reported bugs, although they fall a bit behind on the 20th, and catch up on the 23rd.

It’s also important to note that over eighty bugs were found between the 16th and the 24th. That’s too many, and we need to work on that.

The tool I wrote gathers data retroactively, so I can run it at any time. It has a method for getting all the tickets in a particular sprint, but it will work on any set of tickets. If anyone wants a copy I can tidy it up for distribution. It’s written in Revolution.