Distributed Development

A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development.  The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India.  (No mention if all of the workers in India were in the same place.)  I’m not picking on this individual.  I’ve heard similar stories many times.

It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture.  On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects.  In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines.  Why do it this way? (Continued)

Getting your money’s worth

Everybody wants to get full value for their money.  I can pinch a penny as hard as the next guy, maybe harder.  But I’ve learned in many ways and many contexts, the very things I do to get more for my money, often result in actually getting less.  How can this happen? (Continued)

Testing in depth

In the late 1970s, in the Co-Evolution Quarterly, the magazine successor to The Whole Earth Catalog, Peter Warshall stated that geodesic dome houses always leak.  This was a bold and surprising statement at the time, coming from a man who was considered one of the finest builders of dome houses–ones that didn’t leak.

Why did he make this statement? (Continued)

More on Automated Acceptance Testing

Jim Shore has posted a response to the reactions about his previous post on Acceptance Testing in which he defends the way he and the teams he coaches are working.  About the same time, Lisa Crispin posted her thoughts on the topic.

As Lisa says,

I can’t tell you the one right way to test and develop software….  The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.

This is an incredibly important point!  There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.”  So I’m happy that Jim and his teams are able to achieve the results they want.  I’m not saying they’re doing it wrong. (Continued)

The Reality of Automated Acceptance Testing

Recently, Jim Shore wrote about The Problems With Acceptance Testing.  I like Jim, and respect him a lot.  Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.”  Gojko Adzic has posted his response to Jim.  This is mine.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit. (Continued)