Day 30 - The end of January

Pretty good day - we had a successful demo, though all I did was bring Timbits.  Something that our company adopted and I feel is an excellent part of the software lifecycle, is the demonstration of the completed feature.  This probably doesn't happen often enough, but whenever it does occur, I think it helps bridge the gap between the line-items that managers and higher-ups have spent so long talking about and what the ultimate user will see.

Something Agile-related that I heard this week, but less positive than demos, were questions from a status meeting.  The question centered around whether we (as a company) should mark a particular feature done or "at risk".  The reason for the question is the trouble - a defect in third-party software.  To make the issue more accessible, let me pose a question: Alice and Bob are writing software that must be combined to form a final product.  Alice's portion requires Bob's to work.  Is Alice done only when the final product works?

I'll let you think about that.  That was probably long enough, or you're impatient and don't want to think about it.  Either way, if Alice isn't finished until the final, combined product is working properly, then Alice is responsible for Bob's piece as well.  Not directly of course, but if Bill wants to buy the final product from Alice, then Alice is responsible for the whole product working correctly.  If Bill combines the piece from Alice and the piece from Bob, but Alice says her part isn't finished until the combination works, Alice is assuming responsibility for ensuring Bob's piece works, even if Alice has no influence over Bob.

That explanation isn't really any better than the original description, but what I'm trying to say is that the questions in my workplace tell me that there are some people that feel that our company can't be finished until the end product works.  I have a big problem with this because we are in the middle of a software sandwich, with one company building hardware and the first layer of software, us, and then another company builds the portion that sits on top of everything else.  If we can't say we're done until everyone else is, we've failed if any of the other two companies has a problem.  But our company can't alter the software from the other two or even influence them.  We'd be taking responsibility for things we can't change, like being responsible for bad weather.  Sure it makes things less nice, but we can't alter the weather - how can we be responsible for it?

After that rambling description of the problem, I'd like to state that I understand the motivation behind the statement.  It is motivated by a desire to make the best possible product.  However, being part of a compound product means that all we can do is our part as good as possible and help identify areas that need help in the other portions.

Had a pretty nice evening - brought some pizza over to my sister's place where the kids were having a good time, but not in the same room as the adults.  Makes life so much better when there is an appropriate amount of distance between the two groups - too close and you drive each other insane, too far and you wonder what's going on (or get lonely - haven't run into that yet).