December 2004 - Posts
I’ve been slowly working my way through
Essential Skills for Agile Development over the Christmas holiday. So far I really like what I’ve read. The book has a lot of samples and offers some very good advice to anyone writing code, and especially to those that want to learn more about the skills necessary for agile development.
The application that I’m currently working on involves importing data from a couple external systems and databases. Initially I thought about querying one of the database using a FOR XML query, however, since the system has high usage I decided instead to do a simple query and do the conversion to Xml after retrieving the data and closing the connection to the external source. As I worked though different scenarios for converting the data to Xml I quickly jumped on the DataSet since I can easily bring my data into my application as a dataset and then convert it to Xml using the WriteXml() method.
After my application retrieves the set of data from the external system it needs to do a bunch of processing before triggering a number of events (such as sending alerts, and persisting information to the database). Since I’m going to be working with a couple different systems I decided to standardize on using an Xml data source and using XPath queries to do my evaluations and querying of the data to be imported.
The import definitions for each external system will have a MatchExpression property which will be used to define where the import should look in the retrieved Xml document for the data that is important. After playing around with the .SelectNodes property of the XmlNode class I decided to move the query logic to use an XPathNavigator since I’ve found the performance to be better. One of my the imports involves getting the current status of a system. I have a status object that includes a MatchExpression object. As I import the records I loop over all the defined status’ and run the MatchExpression (which is an XPath expression in this case) against the XPathNavigator to determine the status for the record.
// OuterXml of XPathNavigator might look like <Record Status=”foo.bar”/>
// Match Expression for the Status object would be //Record[@Status=’foo.bar’]
public class Status {
public bool IsMatch(XPathNavigator nav) {
XPathExpression ex = nav.Compile(this.MatchExpression);
return nav.Matches(ex);
}
// …
}
After going down this path I’ve had a nice realization. By standardizing on the XPathNavigator I’m opening up my import procedures to much more then just Xml. I now have the capability to use the DataSetNavigator to run my import procedures against datasets, as well as the ObjectXPathNavigator to run my import against custom objects. In addition to making my import processes runnable against additional types of objects I should also get increased performance.
At work a number of co-workers like a dark background with a light color font when they're coding. I've been giving it a shot the last week or so and can't decide if I like or dislike it. I'm just getting started on a new project that seems to be taking a little longer to get going. Maybe it's that damn black background? I think I'll have to switch back to my default for a while to see if things start picking up.
What color(s) do you use for your "coding environment"? What font? I typically use VS.NET default settings, except I bump the font-size down to 9pt and set keywords to be navy blue instead of the standard blue. Other then that I usually keep things pretty standard.
I was just talking with a co-worker who has a Toshiba Protege M200 and he recommended waiting for the next generation. The main reason he mentioned waiting was because the current version doesn't come with a CD/DVD drive. I'm usually installing a good bit of software from CD/DVD and I'm not sure I can go without a CD/DVD drive in a laptop. I haven't heard any other complaints about the lack of the CD/DVD drive. Perhaps it's something that sounds like more of a deal then it is. Thinking about it more I don't really use the drive that much but it just seems like a standard thing that everyone would include. For those of you who have the M200 do you find yourself missing the CD/DVD drive? If no, why?
I’m getting back into the TDD and C# swing of things here (I’ve been doing non-coding activities for a bit). As I’m writing my tests I’m finding that I want to create constructors for a couple of my objects that will never be used anywhere except in my test(s). Rather then pollute my object with these constructors I could create a helper method that servers as a factory just for my test. The “problem” then becomes that if I want to use this factory for creating objects of this particular type in another test I need to expose the factory to all my tests classes. Of course I could also just stop being lazy and create an instance of my class and set the particular value in code each time, however, this leads to test code that is a little harder to read then necessary. Why must their be so many options? What do you do when you find yourself in a situation where you need to initialize instances of objects in your test one way and initialize the same classes a totally different way within your application? Is polluting your objects with constructors just for your test a sacrifice your willing to take?
I’m thinking about replacing my 2+ year old laptop with a new sleeker model. I do a lot of development on my laptop so I need something with some juice. I’ve been eyeing the
Toshiba Protege M200 for a long time, and with the possibility of getting a new laptop I have to put it into consideration. For those Tablet users out there, why should I get a Tablet? Any programmers use their tablet as one of their primary development machines?
I was very pleased to see that MSN Desktop Search indexes C# files. That in itself makes it worth installing instead of Google Desktop Search (does GDS support indexing C# files yet?).
I just watched
CodeRoom, and although it was kinda interesting to see how the participants tackled the tasks, overall it was lame. I’m not sure if watching people use wizards is something that is going to keep too many people interested. Perhaps throwing in some gotch-ya’s like making people code in COBOL.NET, or having the “client” come in every hour to change the requirements would make it more life-like and more entertaining? Maybe throwing a monkey into the mix would liven things up as well?
As mentioned in my previous post I’m looking to bring a scrum-like process to my current project. During the various kickoff meetings for the project I’ve realized that the client will probably have a difficult time embracing a more agile process. The client is used to “conventional” development practices that start with large requirement documents, a big one time release at the end of the project, and a very detailed project plan defining “all” the tasks that will occur throughout the project. They think this is what is required to build software. This looks to be the biggest challenge yet. Smaller clients with less exposure to traditional processes seem to be more open to “different approaches” but the larger clients have the waterfall methodology so ingrained into their corporations that it will be difficult to show them the ways of agile.
What have you used to help your larger clients who have waterfall ingrained into all their processes and procedures move to a more agile methodology? Who did you have to sell on the ideas of agile to gain traction?
We’re working with a client that has pushed back a little in regards to a planned release for software that we are developing. As I’ve mentioned several times in previous posts my current employer uses a methodology that is closer to waterfall then agile. I’m slowly introducing things into our process that will help us become more agile such as TDD, continuous builds, and I’ve been trying to figure out how to start introducing agile approaches to the project managers and account managers. This client request to bump up the release is a perfect opportunity to “sell” a Scrum-like process for this potential project. I hope it works :-)
Roy has changed his mind regarding unit testing with a database. One of the things that many TDD zealots preach is the use of Mock objects for testing your application. The mock objects remove the dependency on the database and can help improve the efficiency of developing unit tests. However, there is a lot that can be gained from using the database in your tests. You test the data access logic, stored procedures (sql), as well as the integration between your application and the database. I still think there are lots of times when Mock objects can be beneficial but I agree with Roy that by using one of the many methods for rolling back data (most of which he developed) it is much easier to use a database as part of your unit testing process.
I've recently been working my way through Agile Software Development with Scrum. It's an excellent book that brings together a lot of pieces of the Agile puzzle that I've been searching for. I've always thought the practices that agile advocates did wonders for improving the software development process but I had a lot of outstanding questions for how an agile project is managed. Scrum answers many of those questions.
What I really love is reading about why waterfall methodologies cause problems and then seeing them in my own work environment. The waterfall method for developing software has been ingrained into a lot of people's minds. They want their project plan with every task estimated out in the fullest of detail....even though those details are wrong and based on assumptions that we all know aren't all that accurate. Their is a belief that if the project plan is detailed enough the project will be a success. The planning of the project will be taken care of, the budget for the project will be set, and all that will be left will be to cross off all the tasks within the plan. If only software was so easy.
Jimmy recently posted about his NWorkspace project. It sounds like a very interesting project. A while back I posted about how "Mock Objects help me get into the TDD Zone". In the post I talk about how the persistence layer I developed supported changing the "entity manager/provider" via a configuration setting. If your familiar with the "Provider" pattern imagine a "Provider" that handles the persistence of objects. Now image different versions of that provider for SQL Server, In Memory, and Xml. While developing tests we typically don't want to hit the database so the In Memory provider would be the way to go. In our test code we still deal with our objects just as we would in our real application that hits the database. Rather then creating a provider that persists objects to the database, the system creates a provider that persists objects into memory. When find methods are called on the objects the in memory provider searches the objects that have been stored in memory. This helps the TDD experience and as Jimmy points out allows you to make quick changes to objects without worrying about all the database changes.
Although Jimmy's project is probably pretty different it reminded me of some of the work I did way back when to accomplish a similar goal. It's been a while since I've really done much with my base framework and I think I'm missing it. Developing frameworks, O/R Mappers, and other reusable frameworks make you think about a lot of things that you otherwise don't have to consider. I'll look forward to more details on Jimmy's NWorkspace project!
I've been reading a lot of books, articles, and mailing lists "entries" by Ron Jeffries over the last year. I love the pragmatic approach approach he advocates. A lot of what he says goes against what we typically hear from those in the industry. I'm a fan and I really enjoyed his recent post on Frequent Releases. We hear a lot of arguments for why frequent builds can't or shouldn't happen. But as Ron points out the bottom line is that:
If we're not shipping our software when it's ready, it's poor business practice.
If we're not sure whether our software is ready, it's poor software practice.
My manager just recently dropped me an email asking if I would be interested in writing an article for the newsletter that we publish every month. Of course the first thing I thought was “What would I write about?”. I thought that writing some about agile development and/or Scrum could be interesting but I wasn’t sure how I’d write something for the audience that the newsletter targets (not real techy). Just yesterday I received an email from our Marketing manager saying that my manager told her that I would be writing a article on the “Benefits of Agile Software Development”. I have to give my boss credit for knowing what I’d want to write about and then putting me on the schedule to actually write it.
Now I have to figure out what the major talking point for my article is going to be. If my target audience was more technical in nature I don’t think I’d have as many questions about what to focus on, but, that isn’t the case. So if you were a non-technical business user what types of things do you think would be interesting to read about in an article about Agile Software Development?
Maybe beginning a list of the advantages that come to mind immediately will help me get my creative juices flowing:
- The highest priority for projects using agile methodologies is to satisfy the customer through early and continuous delivery of valuable software.
- Changing requirements are welcomed even late in the game. Change is seen as good since it indicates the team is learning new things about the system.
- Close interaction between developers and customers ensures the software being built has the needs and wants of the customer in mind.
- The technical practices that are used in agile software development:
- produce software that provides the most business value
- produce a simple, effective, architecture and design
- place high importance on technical excellence
- ensure the team is continuously improving and optimizing their practices
- ensures high quality software is produced by way of practices such as test driven development
Perhaps more important then any of this is the values of agile:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I’m not sure if I’ve helped myself too much but at least I’ve started some rough notes that I can use later!
Reference: Agile Software Development, Principles, Patterns, and Practices