Heather McLean

A post from Adam Martin inspired today’s deep thought. In his post, he refers to a form of product management strategy (or rather, anti-strategy) known as “pure, blind, Hope.” I’ve also heard this espoused more romantically as the “if you build it, they will come” approach, though that generally applies to an earlier point in the product lifecycle. It’s a form of hubris that appears frequently at executive-level product management, though people at all levels can be guilty of it.

Generally what happens is that someone comes up with the “killer product idea,” and then pitches it with lots of pizazz and hooplah (typically accompanied by flashy PowerPoint slides) that show how awesome it is and how people are just dying to use it… without actually doing any hard research or formulating an actual plan. They convince the people holding the purse strings to fork over unthinkable sums of money to bring the project to market. Even if it doesn’t flop outright, the lack of vision will eventually sent it into a death spiral, and all the while management will continue to shovel money into the sinking ship in the hopes that a miracle will occur. It’s a bizarre form of product management that I’ve never quite understood even though I see it all the time. To a degree, it contributes to a “muck flinging” approach as well: management will continue to throw products at the wall until one of them sticks.

All of this could be avoided with an actual strategy for building and sustaining the product. Unfortunately, that does require the expenditure of brainpower and legwork to do some research. Important things to know before you ever begin are:

• What is the product’s purpose? Why are we doing this? (“Because it’s cool” can sometimes be a valid answer, but it shouldn’t be the only one.)
• Who is going to use this product? How can we excite them about it and target those potential users specifically without necessarily spending gobs of money to blanket the market with advertising?
• How do we make money off the product at launch? Or, how do we position ourselves to turn a profit later (without relying on additional infusions of capital, preferably)?
• What happens after launch? Where is the product headed in 1 year? 5 years? 10 years?

If those in charge of product development would sit down and answer these basic questions about their products instead of focusing on glitz and glamor, it would go far to stop the habit of dumping money into something that will only wilt and die. Even then, the strategy you came up with at the beginning may not be applicable later; I recommend re-answering these questions from scratch periodically so that you can adjust as needed.

(To see where this started, go back to the first post.)

Mostly I just wanted to post a couple of articles from Bruce Byfield, specifically referencing sexism in the FOSS movement, but I think it applies to all of IT, or any technical field for that matter. I thought his arguments were presented in a very professional, non-confrontational manner. It’s not surprising that a lot of men take it as a personal attack, however.

• Sexism: Open Source Software’s Dirty Little Secret
• Writing about FOSS sexism

The second one is actually about the fallout from the first one, and what a fallout it was. I won’t even bother talking about the comments this time (specifcally I’m looking at Slashdot, here), since it would cause one to despair on the future of the human race. And I thought the comments over at the Register were bad! It should come as no surprise that the article itself got tagged “troll” by the mysoginistic members of the audience.

My new Code page is now online, where you can download some of my little project exercises. You’ll find the REST web services project I talked about a few weeks ago, as well as a lightweight inversion of control container. I’m releasing these projects as public domain since they were really just exercises and not full-fledged usable codebases.

I was recently re-reading Martin Fowler’s article The New Methodology when I came across a passage that stuck with me:

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.

One of my biggest pet peeves is when managers and planners refer to people as “resources.” I get this visual of a bunch of managers sitting around a table and trading little chits that represent people until everyone is happy with what they have, but all the chits are the same… just commodities to be pushed around from project to project.

When you treat people as interchangeable cogs in a machine, you miss several important factors about your team members:

• People are not equivalent pieces. I refer you of course to the ever-popular book The Mythical Man-Month by Frederick Brooks. If I have estimated¹ that two people can do the work in six months, increasing that to four people does not mean that we will get it done in three months. Team members all have differing levels of expertise and productivity, differing skills and motivations; you must know how to leverage these individual talents rather than lumping them together as a whole.
• People bring the greatest benefits and the biggest hindrances to the project. When you reduce them to a column on a spreadsheet, you are naïvely discounting their individual personalities and quirks. People can have breakthroughs that cut development time in half. They can also have a family emergency and lose you a week of production.²
• People are perceptive. They know when they’re being treated as faceless automatons rather than real human beings, and they will resent you for it. Don’t ever believe that your team members aren’t keenly aware of how you talk about them behind closed doors.
• People have preferences and motivations. Assigning people to tasks that they may be good at but hate is counter-intuitive. Yes, Bob may be a database whiz, but if he hates the reporting engine, assigning him to fixing the reports isn’t going to be the best utilization. Assign people to tasks that they enjoy, even if it’s not their strong suit; they’ll be more productive and learn a broader range of skills. Conversely, don’t let people pigeon hole themselves—ask them to branch out every once in a while and leave their comfort zones.
• People have lives beyond work. Don’t plan for people to have 100% attendance. Don’t even plan for them to work 40 hours per week. As I mentioned above, people are perceptive, and if they feel you are treating their personal lives as secondary to work, they will resent you for it, and morale and productivity will plummet.

The next meeting of the Fort Worth chapter of the APLN is on Tuesday, October 13, 2009. The speakers will be Ken Howard and Barry Rogers of Improving Enterprises.

Abstract: This highly interactive and fun session takes a refreshing look at the human element with actionable techniques that targets individuals and their interactions. Many believe that Agile is less about specific processes and tools and more about effective teams and productive communication. The first value of the Agile Manifesto emphasizes individuals and interactions yet everywhere you look the focus seems to be on processes and tools. Topics range from enhancing interpersonal communication (Tango) to effectively leveraging the anatomy of your team (Square Dance).

For more information, contact Charles Seaman at fortworthapln@gmail.com.

After a while of putting it off, I finally upgraded my WordPress installation tonight to the latest version. Sadly, I had a moment of silliness and accidentally deleted my wp-content folder, which contains all of my uploaded images among other things. I’ve restored a couple of them, the rest are on a different computer that I’ll have to get later. Luckily my site doesn’t have many images.

Just further proof that even supposedly brilliant people can make really dumb mistakes from time to time.

Updated 9/11/09: Okay, looks like everything should be back in order now… at least until next time.

After a discussion of the merits of various web service technologies with a colleague of mine, I decided to do a little programming exercise. I felt I hadn’t really gotten to do any seriously complex programming in a while, so it was nice to exercise my brain a bit and learn some new things. I basically implemented a REST web service stack in .NET. It has both a server and client model. For the client, it’s as simple as decorating an interface:

[RestWebClient(Url = "http://local.yahooapis.com/MapsService/V1")]
public interface IYahooTrafficService : IRestWebService
{
    [RestNoun("trafficData", Method = RestHttpMethod.GET)]
    [return: RestReturnType(RestReturnType.Xml)]
    XmlDocument GetTrafficData(string appid, string street, string city, string state);
}

The example here uses the Yahoo Traffic Data API. Once the interface is created, I can get a concrete instance through the RestWebClient factory:

IYahooTrafficService svc = RestWebClient.Create<IYahooTrafficService>();
XmlDocument xdoc = svc.GetTrafficData("YdnDemo", "1771 LBJ Fwy", "Dallas", "TX");

And voila! Traffic data:

Example of output from the Yahoo! Traffic Data API.

Pretty simple, and it works with a variety of REST interfaces. It can also handle complex types through XML and binary serialization as well as straight binary streams, such as image files. The server piece works similar to the client; decorate a class with attributes to describe the service contract, and an HttpHandler does the rest.

This was particularly challenging on the client piece because I had to learn the System.Reflection.Emit namespace, which I had never used before, and it requires an in-depth knowledge of MSIL. So that was difficult at first, frustrating most of the time, and rewarding in the end.

At some point I would like to clean up the code and release it as open source. Some other folks might actually find it useful. It definitely needs some heavy refactoring first, though.

Just wanted to point out a new addition to my blogroll: Viva la Scrumvolucion!!

This is the brand new blog of a great colleague of mine, Harry Long, one of the best Scrum Masters and Project Managers I’ve ever worked with. The blog is presented in both Spanish and English, so any of you out there that prefer Spanish as a primary language will be pleased to see agile discussion in your native tongue.

“Waste”—it’s an ominous word by itself, and in the world of Lean principles, it’s the one thing you’re striving to eliminate. Waste can be defined as that which adds no value to a project; i.e., those things that you are spending time and money doing, but they don’t move the project forward. Software projects are often full of waste, and in such an imprecise discipline, it can be difficult to identify the sources of waste. In fact, a lot of times we end up running in circles, attempting to clean up the symptoms rather than the causes.

In my experience, the one largest source of waste that can be eliminated or reduced to add immediate benefit to a project is rework¹. Rework falls into two major categories:

• Technical debt
• Defects

Read the rest of this entry »

The next meeting of the Fort Worth APLN is on August 11, 2009 at 6:30 PM. The speaker will be Ben Gatzke:

Ben Gatzke has been delivering ecommerce software for a decade beginning with his time at Accenture where his teams delivered B2B netcentric solutions for major energy firms such as BP and Exxon Mobil.  Next, as the technology founder of PayDay One/ThinkCash, Ben’s success garnered the company the support of two of the largest VCs in the nation, Sequoia and Technology Crossover Ventures.  Ben is currently practicing agile consulting across the US for teams ready to take value-driven delivery to the next level.

As usual, if you want more information, contact Charles Seaman at fortworthapln@gmail.com.