| Profilo di BryanBryan Hinton's spaceFotoBlogElenchi | Guida |
|
11/11/2008 Gay Marriage and Polygamy – Where do you draw the line?I have watched with interest the post election protests that have occurred over the passage of Prop 8 in California. I continue to find it amazing that the LDS Church has been targeted specifically (although others have also had to deal with the protests as well). Members of the LDS Church accounted for approximately 2 to 4% of the 52% majority for Prop 8 … 2 to 4%!! I am grateful for the good people who have stood up and stood with the Church decrying the religious attacks that have occurred (in particular the Catholic officials in California). As I have thought on the events that are transpiring I wished for the opportunity to ask someone who was against Prop 8 if they felt like polygamy should be allowed. Now let me qualify the polygamy statement because I am sure many would initially say that they just don’t think it is right for old men to marry young girls. I am not talking about those scenarios. What of those who at the appropriate ages wish to enter into polygamous marriages? I wonder what those who are against Prop 8 would say. For those who would be against polygamy - why? If you are so outraged at society defining marriage as between one man and one woman and limiting your rights why are you willing to limit others? May I submit that for many it would be because there is a moral line they have drawn in their life that categorizes polygamy as inappropriate. Whatever the reason for that moral line whether it be religious beliefs, the belief that society is better off without that practice being permitted, or some other reason that line is established. With that context perhaps you can better understand those who voted in favor of Prop 8. They simply drew the line in a different place – for whatever reason (and again there are many) – those who were in favor of Prop 8 felt that our nation, our society was better off defining marriage as between a man and a woman. For most, it had nothing to do with hate and everything to do with doing what they thought best for society, for their children, for the future. Morality is a key part of society – morals underpin our laws. As such there will always be disagreements about what our society’s morals are and what laws are enacted around them. As such I simply ask that the accusations of hate and bigotry stop – yes we disagree and yes those disagreements are over sensitive, emotional topics that leave many hurt feelings, but we can and should move beyond this to continue working together to build a better America. This issue will undoubtedly come up again as issues with such strong, passionate followings do. People will again vote according to their conscience formed by their personal moral beliefs. Perhaps the outcome will be the same and perhaps it will be different, but let us not fall prey to hate. 05/11/2008 Insightful quote from Elder Maxwell about the times we live inMy dad and I were talking about Prop 8 passing today and we couldn’t help but reflect on how quickly it seems the moral tides of our country have changed (although thankfully Prop 8 should stem it to some extent for a little while). In the 13 years between high school and now I am amazed at what is now considered acceptable in our society. We couldn’t help but wonder what that meant for the next 13 years. It is scary to consider honestly. As I reflected back on what I have heard as I have followed the arguments from both sides for Prop 8 and how nasty it got (the missionary ad and the constant rhetoric about hate and bigotry) made me wonder what would it be like when we revisit this issue in the years to come (because I have no doubt that this issue will continue to surface). My Dad shared the quote below from Elder Maxwell that was given in 1979 amazingly enough. It was absolutely what I needed to hear. The Lord knows what is ahead and stated as such through Elder Maxwell almost 30 years ago and did so again with the Proclamation on the Family that came out 13 years ago. Time to tighten the seat belt I think.
A Suggestion for Windows Live and Windows 7In playing around with the Windows 7 bits I got at PDC I had a small idea that I submitted through the feedback link for Windows 7. The feedback is more related to how Windows Live works with Windows 7, but I thought I would submit it through that avenue as well as post it here. The note I sent through the feedback link was I installed the Windows Live suite of products. One of the immediate things that came to mind is I would rather have one deskbar icon rather than one for each product. It would be nice to have one Windows Live icon on the bar and use the little arrow to go select which one to launch - I like having quicker access to them and grouping access under a Windows Live icon would make the experience of the Windows Live Suite feel more unified I think. Thanks, I used the unlock method documented here to get access to the incomplete deskbar feature. I like it - although I would like it more with the Aero Peek feature. As I used it I realized it would be nice if there was a Windows Live icon on the deskbar that I could click the little arrow on to boot up an instance of Writer or Mail or Messenger etc… I think it would connect the Windows Live Suite (make it feel more like a suite) and reduce the clutter on the Superbar (that seems to be what people are calling it) by having all the different Windows Live apps pinned there.
Windows Live Tags: Windows Live, Windows Live Wave 3, Windows 7, clubhouse, Live Mail, Live Messenger, Live Writer, feedback 04/11/2008 Requirements Definition : The Danger of Failing Before You Have Really StartedRequirements, Stories, Use Cases, or whatever a team wants to call them form a key part of the execution plan for a development team. It should tell them what a customer wants. The artifacts in whatever form they are tend to have varying degrees of detail. Getting the right amount of detail at the right time is critical to the process of producing successful software. My thoughts on Requirements definition form around a process with three key elements.
Development is first because you have to develop or brainstorm something to start with. This generally is initially tied to a vision of what the software is supposed to do. Over time as a product matures this phase often happens through user trials, surveys, feedback, and telemetry from the app that describes its usage and provides insight into where the app needs to evolve. This also happens as analysts evaluate the market the product fits in and based on the market’s evolution or the assumptions about where it will evolve. In evaluating they determine what features needs to be added in order to allow the software to continue to be competitive in the marketplace. With internal software this phase is often underappreciated and underutilized. This is unfortunate because mistakes here whether in internal or commercial products can cause teams to miss the target market tremendously. A mistake of one degree in a flight plan early in a flight plan causes a much greater deviation than a mistake relatively close to the target. The Agilist in me openly admits that it is impossible to know everything upfront. The development effort isn’t about deep detail, but broad strokes of strategy that guide the more detailed planning that occurs later. Prioritization comes second as the ideas developed get prioritized. This act pares down the list of items that need to be defined in detail. I like Scrum’s backlog analogy but I think the Product and Sprint backlogs might not be enough. To use a baseball analogy I think you have an At-Bat Backlog, an On-Deck Backlog, and an In the Hole Backlog. At bat would be your Sprint Backlog representing what is in play now. On Deck represents perhaps a release backlog or something of that sorts. These are items that are going to be in play and will need to be defined fairly soon. In fact during a Sprint it wouldn’t be uncommon for the PM, Business Analyst, etc… to be very active in defining those items near the top of the On-Deck list. The On-Deck list becomes a focal point in the prioritization process. The Sprint is work committed to and while some teams might want to have a relative priority there I don’t have a firm opinion on it. The On-Deck list is key – what will the team work on next is the question that needs to be answered by the prioritization process. Once we have a prioritization there we can move forward with the third step in the process – Definition Definition in this context is providing the detail necessary to move the concept forward in the planning process and ultimately moving it successfully into the implementation phase. Steps 2 and 3 in the process end up being a rinse and repeat type of deal. Items will be prioritized onto a list and will need to be defined to some degree. For example when an item is prioritized onto the On-Deck list it is likely that definition needs to happen in order for some estimates to be provided as to how long the items on the On-Deck list will take to complete (thinking of the On-Deck list as representing the functionality in a release). As On-Deck items in the list move up – more definition is added so that the customer needs can be clearly identified and the developer can have in hand as much detail as possible when that item pops onto the At Bat Backlog. It is here that we get to the crux of the matter that caused this post to be written. I have seen two common behaviors that cause teams to fail relative to requirements definition. The first is that requirements are defined too early in too much detail and not revisited effectively and as time goes on customer needs shift or change and the requirement as it was written months ago no longer accurately reflects their needs. The second behavior is too little detail. A story is defined with a title (which I think the whole story card/post-it thing encourages) and little else and exists like that all the way to the developer. He has in his mind what the title means, the customer has another thing in mind, and program management has yet another. Agile methodologies advocate the definition happen through consistent customer interaction and if that happens that can work. All to often in practice it doesn’t work that way. The takeaway is don’t under value the requirements process it is perhaps the most difficult thing to get right in the whole software process. Too much detail, too soon or too little detail, too late – what is too soon and what is too late and how much is too much or little – not easy questions – the process above has worked well for me in addressing the challenges with getting requirements right. 03/11/2008 Halloween is almost here
I meant to get this posted before I left for my work trip to LA for Microsoft’s Professional Developer Conference, but I didn’t so I am trying to get this out while here. We had a party with family and friends at our house last Friday. This is a take off of the Arrington Family tradition that has gone on for years. We had the Hubers, Goodfellows, Trammells (or part of their family at least), and Cardons – we missed out on the Stohls (they got sick) and we were bummed about that because we haven’t met anyone so in love with Halloween as Megan is, but we still managed to have some fun. Here are some pics from the party including from our donut eating contest!
|
|
|