Car manufacturers have entire departments dedicated to finding better ways to do things. If a car company spent all its resources producing cars and no time finding better ways to produce cars, it would quickly go out of business.
http://codebetter.com/blogs/jeffrey.palermo/archiv...
With all the advantages that Agile provides, I think it can lead to teams spending all their time producing "cars". Afterall, what immediate business value does research time spent investigating how to do things better provide?
tags: agile, software
Alex has been playing with IronPython lately and it seems he's been hooked.
His posts have certainly peeked my interest. Hopefully I'll get some time to play around, but in the meantime I'll continue to checkout Alex's adventures!
tags: IronPython
Sounds cool! One of the most exciting things about Linq is the ability for alternate implementations to be created for processing Linq expression trees.
Microsoft is working on a parallel implementation of its Language Integrated Query technology that will help programs execute faster, said the creator of the LINQ technology.
Anders Hejlsberg, a Microsoft technical fellow and lead architect for the C# language, said Microsoft has an internal project known as PLinq, which is an effort to create a parallel implementation of LINQ.
http://www.eweek.com/article2/0,1895,2009167,00.asp
tags: linq, plinq
Joel has
started a series on how to find
great developers. I was always amazed by the….how do I say….consistency of the “not so good” candidates that we saw at my last gig (lucky for me I don’t have to do nearly as much interviewing these days). Finding great developers is one of the hardest things to do in our industry. Joel does a great job of making people want to work for Fog Creek. I’ll be interested in hearing some more nuggets of wisdom from Joel on the topic.
I was recently asked for some details about how we run our one week iterations so I figured I'd post some details to this here blog. We've been doing one week iterations for a while now with some pretty good success. While the nitty gritty details of every iteration varies we tend to keep the overall flow the same.
Of course everything starts off on Monday. With a nice weekend to relax and reflect on the previous weeks work we come in refreshed and ready to rock. We kick things off with a demo of the functionality added in the last week at 9:00 AM. The demo includes everyone from our office as well as our colleagues in our other offices around the world and a few interested clients. The demo is typically done by a member of the "business team" since they tend to have better presentation skills then us introverted anti-social developer types.
Once the demo is complete we go into a retrospective which is used to reflect upon the previous week and identify things that we can improve upon in the coming week. The retrospective usually runs for one hour. Once complete we begin discussing the stories slated for the week. Our story discussions involve an overview of the objective for the week, a high level discussion of what's entailed with each story, a discussion of the FIT that has been created for the stories, and finally a hodge podge of questions that the developers ask in order to figure out what exactly is being developed in the coming week. The discussions can last anywhere from 1-4 hours. Once the developers have a firm understanding for the work that needs to be done we breakdown the stories into tasks and estimate. The task breakdown and estimating varies A LOT, and largely depends on how familiar the team is with the work and its overall complexity. Task breakdown and estimation takes anywhere between 1-4 hours. As I'm sure you've figured out by now sometimes our entire first day is taken up story discussion, task breakdown and estimation. I'm not a big fan of taking the entire day but its important for everyone to have a firm understanding of what's being developed so at times its a necessary evil.
Monday
- 9:00 AM - Demo of the functionality added in the previous weeks iteration
- 9:30 AM - Retrospective
- 10:30 AM - Discuss this weeks stories
- 12:00 PM - Break for lunch
- 1:00 PM - Break down this weeks stories into tasks
- 3:00 PM - Start working on this weeks iterations
Tuesday-Thursday
- 9:00 AM-6:00 PM - Get shit done
Friday
- 9:00 AM-12:00 PM - Finish up the remaining work for the iteration
- 12:00 PM - Break for lunch
- 1:00 PM - 3:00 PM - Fix bugs, prepare for demo
- 3:00 PM-EOD - Research
After we get everything planned out for the week we get started on the tasks. From the time planning is complete until Friday morning we stay pretty focused on completing all the stories we've agreed to. We try to keep an eye on where we are throughout the week to ensure we're not in jeopardy of missing our commitments so we take a break every now and again to checkout our whiteboard and evaluate what work is remaining. We often set aside some time for design discussions and etudes as well during the week which we intermix throughout. On Friday we try and wrap everything up by noon, but...well...that rarely happens. If we do finish by noon we spend our afternoon fixing any bugs which have been uncovered and preparing for Monday's demo. In an ideal world we wouldn't have any bugs and would spend Friday afternoon doing minor polish and research. I'm still dreaming about that ideal world. 
tags: agile, xp, agileplanning, iteration
When working with XML data we inevitably have to concern ourselves with XML namespaces + XML namespace prefixes. The Linq to XML API has been designed to make dealing with namespaces and namespaces prefixes as direct and straightforward as possible. Rather than having to deal with XmlNamespaceManagers and the like we simple reference all of our elements and attributes using their fully expanded name (namespace + local name).
While the simplification provided by Linq to XML makes dealing with namespaces slightly more straightforward it doesn't go as far as I think it needs to. We still need to remember to include our namespaces in every query we perform. When working with XML trees that only contain one default namespace I'd like something simpler. Enter the XNamespaceScope class. The XNamespaceScope class would be used similar to how we make use of the TransactionScope class for managing transactions. When we're about to work with an XML tree that only contains one namespace which we're interested in we can new up a XNamespaceScope class, place it inside a using block that surrounds our query expressions, and have Linq to XML use the XNamespace that's passed to the XNamespaceScope in all queries within the block. So rather than this code where we have to repeatedly include our namespace (ns)
1 XNamespace ns = "http://webservices.amazon.com/AWSECommerceService/2005-10-05";
2 var booksToImport =
3 from amazonItem in amazonXml.Descendants(ns + "Item")
4 let attributes = amazonItem.Element(ns + "ItemAttributes")
5 select new Book {
6 Isbn=(string) attributes.Element(ns + "ISBN"),
7 Title=(string) attributes.Element(ns + "Title"),
8 PubDate=(DateTime) attributes.Element(ns + "PublicationDate"),
9 Price=ParsePrice(attributes.Element(ns + "ListPrice")),
10 BookAuthors=GetAuthors(attributes.Elements(ns + "Author"))
11 };
We instead do:
1 XNamespace ns = "http://webservices.amazon.com/AWSECommerceService/2005-10-05";
2 using(new XNamespaceScope(ns)) {
3 var booksToImport =
4 from amazonItem in amazonXml.Descendants("Item")
5 let attributes = amazonItem.Element("ItemAttributes")
6 select new Book {
7 Isbn=(string) attributes.Element("ISBN"),
8 Title=(string) attributes.Element("Title"),
9 PubDate=(DateTime) attributes.Element("PublicationDate"),
10 Price=ParsePrice(attributes.Element("ListPrice")),
11 BookAuthors=GetAuthors(attributes.Elements("Author"))
12 };
13 }
Thoughts?
tags: linq, xlinq, linqtoxml