Text Messaging version of PayPal.

You know what PayPal is, and how it works. How would you like to be able to do the same thing from any cell phone via text-messaging? Imagine splitting the restaurant bill right at the table, imaging doing a quick (and safe) sale of property with instant money transfer.

Here's the best part. If you sign up during the beta, you get NO FEES for LIFE.
Click it if you want.

Brilliant! Once in an Agile Lifetime

If you don't recognize the song, I'm ashamed of you...

And you may find yourself in a two bit startup And you may find yourself in another part of your career And you may find yourself in control of a large development team And you may find yourself in a beautiful team, with a beautiful project And you may ask yourself-well...how did I get here?

Letting the days go by/letting the defects hold me down Letting the days go by/defects choking up the schedule Into the blue again/after the budget's gone Once in a lifetime/defects chocking up the schedule.

And you may ask yourself How do I work this? And you may ask yourself Where is that beautiful process? And you may tell yourself This is not my beautiful team! And you may tell yourself This is not my beautiful project!

Letting the days go by/letting the defects hold me down Letting the days go by/defects choking up the schedule Into the blue again/after the budget's gone Once in a lifetime/defects chocking up the schedule.

Same as it ever was...same as it ever was...same as it ever was... Same as it ever was...same as it ever was...same as it ever was... Same as it ever was...same as it ever was...

Bugs dissolving...and code refactoring There is value at the bottom of the iteration Carry the change request through the end of the iteration Remove the bugs at the bottom of the iteration!

Letting the days go by/letting the defects hold me down Letting the days go by/defects choking up the schedule Into the blue again/in the silent standup Under the build report/there defects choking up the schedule.

Letting the days go by/letting the defects hold me down Letting the days go by/defects choking up the schedule Into the blue again/after the budget's gone Once in a lifetime/defects chocking up the schedule.

And you may ask yourself What is that beautiful project? And you may ask yourself Where did that schedule go? And you may ask yourself Am I right? ...or am I wrong? And you may tell yourself My god!...what have I done?

Letting the days go by/letting the defects hold me down Letting the days go by/defects choking up the schedule Into the blue again/in the silent standup Under the build report/there defects choking up the schedule.

Letting the days go by/letting the defects hold me down Letting the days go by/defects choking up the schedule Into the blue again/after the budget's gone Once in a lifetime/defects chocking up the schedule.

Same as it ever was...same as it ever was...same as it ever was... Same as it ever was...same as it ever was...same as it ever was... Same as it ever was...same as it ever was...

Technorati tag: Agile, David+Anderson

[Via Agile Management Blog]

Some utilities for .Net development

I've had several requests for a package of my various code snippets. I'm releasing these for anyone to use [download here].

Some are based on prior postings, some are things I've gathered from across the net for other projects, some are even things I wrote myself. Everything is packaged as a single Assembly. This code requires at least .Net 2.0 and is in C#.

• There is one class Utilites which is a partial class containing a ton of String, Double, DateTime, HTML, and serialization helper methods. This class is marked partial, so you can add members anytime.
• There is the ArgumentValidation class mentioned here.
• There is the DynamicComparer and SortProperty class mentioned here.
• Finally there are UndoableAction and DisposableAction inspired by a cool posting by Oren Eini here

If you make any improvements or have any comments, please let me know.

UPDATED: On 9 March, 2008 I updated the Utilities library to include fixes in my CombineHashCodes methods.

SQL Date Processing - First/Last Day of a month

Oren Eini posted a nice bit about SQL. It's easy to get the first or last day of a specific month and year without doing all the silly CASTing about. (slightly tweaked in LastDayOfMonth to avoid a redundant DATEADD)

CREATE FUNCTION FirstDayOfMonth(@year int, @month int)
   RETURNS DATETIME AS
BEGIN
   RETURN DATEADD(MONTH, @month - 1, DATEADD(YEAR, @year - 1900, 0))
END
 
CREATE FUNCTION LastDayOfMonth(@year int, @month int)
   RETURNS DATETIME AS 
BEGIN
   RETURN DATEADD(DAY, -1, DATEADD(MONTH, @month, DATEADD(YEAR, @year - 1900, 0)))
END

This works because 0 as a DateTime equals 01/01/1900, so subtracting 1900 from the year and one from the month gives the correct values.

[Via http://www.ayende.com/Blog/PermaLink,guid,23fefdfe-22f1-4649-8e12-f36d06cd54cc.aspx]

UPDATE: I've added a complete list of the ways to get first/last/next values for a date/week/month/quarter/year in SQL here. (I also removed the horrid syntax coloring of this post, sorry).

Dynamic sorting of objects using lightweight code generation.

UPDATE: This project is hosted on CodePlex as the Dynamic Reflection Library for all further updates.

I looked into the cool Dynamic List Sorting package on CodeProject. It's pretty good, but I wanted to get the absolute best performance for my framework, so I optimized the generated IL some [download here]. I've eliminated the local variable used to track the comparison- thus-far as it is always zero until we've got a mismatch. I've also added the ability to reference fields (as well as properties), and added flags to the DynamicMethod constructor to bypass accessiablity checks (allows access to private members).

This new version is very fast. In debug builds, property access is around 5-25% slower than field access, the cost of delegate invocation is about 15% and the cost of element-by-element versus using the object's ICompare method is 4%.

Here's the chart for sorting 500,000 Person objects (in seconds):

Sort By	Field	Property	Cost of property	Cost of dynamic
Age (double)	2.17	2.70	24.42%
LastName (string)	2.60	2.76	6.15%
LastName,FirstName,Age	7.17	7.99	11.44%	3.21%
Dynamic whole object	7.40			15.09%
Built-in whole object	6.43

Sorting by "FirstName, lastName, Age" [property,field,property respectively] results in this generated IL (through the cool DebuggerVisualizer mentioned here)

IL_0000: ldarg.0  
IL_0001: callvirt   System.String get_FirstName()/DynamicComparerSample.Person
IL_0006: ldarg.1  
IL_0007: callvirt   System.String get_FirstName()/DynamicComparerSample.Person
IL_000c: callvirt   Int32 CompareTo(System.String)/System.String
IL_0011: dup      
IL_0012: brtrue.s   IL_0046
IL_0014: pop      
IL_0015: ldarg.0  
IL_0016: ldfld      System.String lastName/DynamicComparerSample.Person
IL_001b: ldarg.1  
IL_001c: ldfld      System.String lastName/DynamicComparerSample.Person
IL_0021: callvirt   Int32 CompareTo(System.String)/System.String
IL_0026: dup      
IL_0027: brtrue.s   IL_0046
IL_0029: pop      
IL_002a: ldarg.0  
IL_002b: callvirt   Double get_Age()/DynamicComparerSample.Person
IL_0030: stloc      V_0
IL_0034: nop      
IL_0035: nop      
IL_0036: ldloca.s   V_0
IL_0038: nop      
IL_0039: nop      
IL_003a: nop      
IL_003b: ldarg.1  
IL_003c: callvirt   Double get_Age()/DynamicComparerSample.Person
IL_0041: callvirt   Int32 CompareTo(Double)/System.Double
IL_0046: ret

Edit: I forgot the call to .Compare in the benchmark, which saves a LOT of time because then the object isn't wrapped in another delegate deep in the guts of the FCL. Numbers above have been updated.

UPDATE: Revised extensively to handle nulls and faster performance. See this.

UPDATE: Revised links to point to GooglePages so I'm not serving the files from my DSL.

Generate C# attributes for XMLSerialization based on XSD schema

This cool tool will take an XSD schema and generate C# or VB.Net classes with the appropriate attributes such that doing an XML serialization of the class will result in valid XML per the schema. XSD Sample Code Generator 1.4.2.1

Lightweight Code Generation is fun, make it easier with a DebuggerVisualizer

When you're doing lightweight code generation (LCG) using DynamicMethod under .Net 2.0, it is easy to get lost and not be sure what your resulting code really looks like. Luckily for us, Haibo Luo knows enough about ripping IL and the new DebuggerVisualizer plug-in infrastructure of Visual Studio 2005. DebuggerVisualizer for DynamicMethod (Show me the IL) It's like having Reflector (in IL mode) inside the debugger.

SawStop is amazing

Simply amazing! A saw that can tell the difference between wood and flesh and STOP in time. Watch the videos! SawStop

Object-Relational Mapping Tools for .NET

A very thorough guide to choosing an O/R Mapping solution has been released here: Object-Relational Mapping Tools for .NET This is well worth the read

Marc's Musings - powered by FeedBurner

In order to track my subscription rate, I'm requesting that if you subscribe to my blog, please update to point via my FeedBurner. Thanks in advance. Marc's Musings - powered by FeedBurner

Off-shore or not? Things to think about...

I just returned from a wonderful 6-day cruise, and it got me thinking about being at sea, and that reminded me that I gave some thoughts to a friend about doing offshore development projects a few months back. Here is the brain-dump based on my real-life experiences in three projects and environments.

If I were a project manager that was just about to take on my first offshore project, what would you tell me are the critical success factors?

o Clear understanding of the working process (e.g. Test First or CMMI or whatever) o Strong version control system and procedure (Subversion for remote access at minimum) o Strong control of the development environment. You don’t want the far-removed developers working on systems containing things you many not want to include. I suggest you use VirtualPC machines and/or RDP to development images. o Clear specifications, with a formal process for answering questions about design. o Understanding that the off-shore developers will rotate through your assignments, so don’t expect to train someone “your way” to be a long term investment. Rather, interview for like-minded developers up front. o Always allocate at least one senior developer to answer questions and review code. Do NOT expect the code to have an quality unless you personally inspect for it. o Daily teleconference with the developers, preferably at their start-of-day. This is a remoted version of the daily stand-up meeting to establish progress and delegate answering of questions.

What were big mistakes that you made about which you would warn future PMs?

o Assumed that we would have the same team throughout; that simply doesn’t happen. o Failed to inspect code early on, once daily inspection was in-place, progress-rate and quality both went up. o Not detailed enough on the functional specification. If you have a internal developer worthy and willing, have them stub the unit tests before the offshore team begins the coding.

What were the primary friction points – elements of the process that slowed you down, frustrated you, and/or took you off course?

o The time-overlap is a good thing as long as you are not waiting on the other team. You can do reviews of the previous “night’s work” during your work day and leave TODOs for the team when you go home, but without daily reporting in (the stand-up), it is very easy to lose days of work. o In the case of India, there were many holidays, so we often were surprised by someone not being available for conference calls. o Much of the management communications when dealing with large firms centers on making sure that they are not to blame for flaws and delays. You have to push back very hard to make sure that the managers understand that a successful project outcome is the ONLY target. I found that I had much better luck working with the developers without the firm’s managers in the loop. o Many times, a disagreement about how something worked degraded into a “you told us to do this, so we did it exactly as stated”, without taking language differences and domain-specific knowledge into consideration, this needs to be controlled early to avoid poisoning the team with bickering.

How detailed did you make your designs and requirements?

o The better the specifications in the “how” realm, the better. You don’t need to give them more than a screen mockup for the UI, but every single interaction should be detailed. We found that activity diagrams and state diagram to be very useful o A data dictionary of terms and Domain Specific Languages is an absolute requirement. If you are interfacing to existing databases and systems, you need to have both a system-level description of the fields (in the parlance of the system) and the business use of those fields (in the parlance of the end-user of the system). Most specifications will use both terms, so a cross reference is absolutely required. o Don’t insult your partner; don’t worry about minutiae like pixel position and exact colors. Firstly because it stifles their creativity, and secondly those things change frequently, and each would be a change request that you will be billed for. o Each specification should be given a version number and any changes to the specification should be tracked and agreed to by both parties. Formal version control of the specifications is just as important as the source code. I suggest Team System for this.

What process did you have in place for code review – was it sufficient?

o Every day, first thing when I arrive, I get the current tips and do a mass compare. I used Beyond Compare (easily one of the coolest tools I’ve ever used, and cheap) and compared the entire directory tree. Doing it daily insured there was never much to review at one time. o All database changes should be scripted and checked into source control, and thus become part of the review process. o All changes should be “eight hour chunks” or less, so that any work can be checked in every night. This insures regular progress and won’t overwhelm the review process. Any longer-running changes should be broken down into smaller chunks. o Every defect found in review becomes a defect in the tracking system, even “style” issues. This insures they get completed, and are considered part of the work-product. o In general, reporting review issues is enough; but sometimes the on-shore senior developer will have to make framework-level changes or fix a defect in order to serve as an instructional example of the corrections needed elsewhere. o If you have a promotion scheme setup, you can label things for incorporation to the public-facing builds as the review determines they are good.

How was the development environment set up?

o Several configurations on different projects. For some, a Citrix Metaframe (RDP/Terminal Server) setup was used. This insured complete control of the development environment, which is key to insuring the build process has everything setup the same as the development process. It did incur a lot of overhead and delays getting the environments setup and changed, but that was specific to the company. o Another strategy, which I vastly prefer is to use a VirtualPC or VMWare virtual machine which is pre-setup with the development environment. That image can be distributed on a DVD or CD (depending on size), and then all development takes place on the local machine. Incidentally, I do this now for all my development and actually RDP into the appropriate virtual machine as this gives a very responsive and repeatable environment.

What have you found to be the best way to track the progress of the projects? How have you kept a handle on your progress in relationship to the project plan?

o I think classic burn down rates and velocity are great measures of progress that are easily understood. I recommend using TargetProcess http://www.targetprocess.com/ or Team Foundation to track the state of everything.

Have you found an optimal frequency of build?

o Every check-in for a build. Every day for a developer deployment build and at least weekly for QA review.

Have you found an optimal frequency of code reviews?

o Daily. No discussion.