Great post about iterative development and embracing change in large projects.
I recently worked at a client that had a large project and their iterations were 24-36 months! Luckily I was working on a sub-project that had four iterations in one year. Our project was considered successful but the larger one I learned yesterday has been abandoned after four or five years of development.
Agility is the best thing about short iterations - even though both the big project and ours required VB6 (by the client) we were able to select a better grid control for our UI. And if we had continued, it would have been fairly trivial to move our code into the .NET world (though that was probably more because of our architecture than our short cycles).
If you were a team member of the bigger project, “new grid” was a banned phrase, and you could only refer to .NET as .NOT.
I really like this idea.
Joel and I recently worked on a project where we got in the habit of emailing the team regularly throughout the day with a quick note about what we were doing, or any problems.
I like the idea of the team members on a single blog, perhaps with Categories if the project was big enough.
Alas, I have my doubts that this would be accepted by my workplace.
I managed to get through a set of CQL queries parsed and output and at first blush they seem to be correct. Next week or on the weekend I will see about comparing the XCQL output of my parser and of course the BER encoded string too (yuck).
I still don't like the internals of this code, its not at all elegant yet. I was hoping by now that I would be more familiar with the bigger picture of the code rather than the intimate detail. I don't think I can re-design it with more elegance until I understand the “50,000 foot” view of it.
When that is complete I will then start hooking up a parsed tree to my new Stacks indexing structure, and see how well my indexes will manage with the query expressions.
So I spent 10 minutes yesterday looking in Help and Google searching for a way to access the value in a Hashtable object by its key. I've done it before, and I'm not stupid about these things, and its embarassing, frankly.
The Help tells you how to add stuff to the Hashtable (ie. myHashTable.Add(key, value)) and see if the key is in the hash table (myHashTable.ContainsKey(testkey)), but it doesn't show you in the examples how to get the actual value out. There is the Keys and Values collections that you can iterate through, but I know there's an easier way than that.
Finally I'm back to VS.NET and the Intellisense and I'm thinking “ok, it must be some sort of array-like accessor, maybe a ( ...? nope. maybe a [ ... aha! that's it!“).
myValue = (string)myHashtable[myKey];
Hooray for Intellisense.
That's 10 minutes I'll never get back. And now the three people who might read my blog knows that sometimes I feel like a complete idiot.
So today I am continuing work on porting a Java CQL library to C#. Yesterday I got a version to compile with no errors, and even made it more .NET-ish by implementing IFormattable in the parser class so I can just use .ToString(”CQL” | “BER” | “XCQL”) to render the query to a string. There's still a ton of code in there that is obviously not .NET-like.
The nice thing about this Java library is that the author included a set of scripts for creating random queries and testing the results of the two queries between two different parsers, and also a script for regression testing too. The scripts are written in Perl so yesterday I downloaded Perl and Java and installed them on my WinXP notebook. Oye - command line interfaces don't mix well with long paths such as C:\Documents and Settings\Mike Diehl\My Documents\Visual Studio Projects\Stacks\CQL.
But late last night I was stepping through my code anyway and finding that my implementation of StreamTokenizer in C# (that is included in Java) is not doing well. I can hear Joel admonishing me about unit testing already. So that's today's job, trying to get the tokenizer to work correctly.