I’ve been asked a few times recently what I feel the best projects for “agile” methods are.

As I mentioned in a previous posting, I view “agile”/”rup” etc as more tactical versus more strategic methods of attaining goals.

Therefore I obviously believe that projects that are more “researchy” or “startupy” make more sense as far as taking a more tactical approach.

Eg, if you don’t know what the UI is going to look like, what features the customer wants, etc, then doing little to no design up front makes sense, and small iterations are handy for generating consensus and a road map of what to do next.

However, projects that have a concrete spec, where the goals are well defined, and the interfaces are well defined would tend to benefit from a more traditional, and less chaotic approach.

I believe all projects can benefit from an incremental and iterative development process; however the increments would tend to be small for the more “agile”/tactical projects and larger for the more traditional projects.

Note: I use “agile” with a small “a” not a large “A”; that is because I believe agile is a tactical mindset, and the tactical approaches to be used are up to the user. I do not believe in the “dogmatic” forms of agile, such as XP, nor do I consider some of the XP edicts as beneficial on any project (Pair Programming all the time, Refactor Mercilessly, Collective Code Ownership across tiers, etc are never on my radar).

I still believe in specialists and enough upfront design to avoid “merciless” refactoring; (I’d rather have merciless design and prototyping so that the production code doesn’t need to be mercilessly refactored).

I believe in concentration too so of course I’m not a big fan of pairs or noisy team rooms.

I’m happy to work shoulder to shoulder as the need arises, but I don’t confuse that as a substitute for lack of documentation by having people work shoulder to shoulder constantly in an effort to avoid having appropriate documents.

However much some methodologies claim to “lower the cost of change”, change is still lower cost to achieve at the paper/design level before it is turned into code. Therefore I like to leverage that cost savings as appropriate (eg, more design, less refactoring).

My approach is to combine what’s good and appropriate about all the methodologies and combine them in a way that makes sense for the project at hand.

Jordan

I just wanted to clarify my position on Unit Testing a bit.

First of all, I am a big believer in Unit Testing Production Code, during development and prior to internal or external releases.

As a matter of fact, I first started enforcing this type of testing on projects as early as the early 1990’s.

So, if “TDD” means “Test Driven Development”, I am all for that.

As far as “Test Driven Design”, as one can probably surmise from my blog, I view that as inefficient and cumbersome for a number of reasons; in any case it seems especially pointless to unit test prototype code that will be thrown away or redesigned in short order; once things stabilize a bit on the design front and begins to become part of the production code base, Unit Tests should be written and maintained for it.

Further, since “TDD” can mean both “Test Driven Design” and “Test Driven Development” I propose that “TDI” — “Test Driven Implementation” — might serve as a useful disambiguation.

Jordan

I was having trouble hosting a Silverlight 2 .xap on my ISP; apparently they don’t (yet) support .xap as a Mime type.

However, I was able to get around that simply by changing .xap to .zip on the .xap file name on the filesystem, as well as in the object tag of the page reference.

Voila, it worked without a hitch. You may want to give this a try if you are having trouble hosting Silverlight on your shared ISP.

I have updated the Silverlight 2 Controls Demo to run on the Release version of Silverlight 2.

If you have been trying to run the old b2 demo on the Microsoft site and have been unable to since updating your Silverlight to the release version, then you have come to the right place!

Simply go here to run my version which runs in the Release version of Silverlight.

Cassini is a stand-alone web server that you can use to deploy your ASP.NET web applications.

Cassini has been updated by it’s author to now run as a single .exe without needing to be deployed in the GAC! This is great news.

Additional features:

• Supported IPv6-only configurations
• Upgraded to support .NET Framework 3.5
• Includes VS project file 

License changed to Ms-PL

Get it here: http://blogs.msdn.com/dmitryr/archive/2008/10/03/cassini-for-framework-3-5.aspx

I was up in SF for a couple of days last week and took a few shots….

More shots + captions will appear soon…

Any Consultant will Frequently be engaged in rate discussions with potential clients.  Many times these are hiring managers, not HR folks.

Sometimes, these hiring managers expect consultants to work for the same hourly rate a full timer would perform the same task for.

If they are quoted a rate higher than that, they feel they are being “ripped off”.  Are they?

Let’s consider a Full Time Employee with Benefits (“Full Timer”) versus a Consultant (“Consultant”) at the same Hourly rate.  To make the comparison simpler, let’s assume they are both paid as W-2, and that they have equal talents, possibly even the same person just being paid one way or another.

Now, let’s say the “Full Timer” is getting $60/hr.  What rate should the Consultant be getting?

First of all, how much is the $60/hr Full Timer really costing the company?  If one were to say $60/hr, one would have a lot in common with many hiring managers who don’t know the true cost of an employee.

1. Full Timers generally get 5 weeks of vacation: 2 weeks of vacation, 10 paid holidays, and 5 PTO/Sick Days. This is 5 weeks out of 52, or basically 10%.  Therefore, with vacation factored in, that full timer is costing $66/hr.
2. Insurance can run $5-$10k, or another 10% of salary. Now that Full Timer is costing $72/hr.
3. Add in 401k, office space, equipment, software, etc, and that’s another 10%-15% bringing it to $80+/hr
4. Now factor in that the Consultant must continually market themselves, and must spend a percentage of time in business development, waiting for projects to start/contracts to get signed, etc, and that cost must be covered somehow.

The above analyses clearly shows that Companies are paying far more for their full timers than the base hourly rate would suggest; these are true and actual costs, and should add ~30% or more to the rate being offered to a consultant who is bereft of those additional benefits.

Additionally, hiring companies are enjoying the flexibility of the consultant relationship, and therefore should bear a fair cost of the business development, sales and marketing and other operational costs that consultants must bear in providing services.

Therefore, even on a W-2 versus W-2 basis, Consultants need to make an hourly rate of 30%-45% more than a full timer just to achieve parity.

Additionally, Consultants often have unique or in depth skills that the organization lacks, which would tend to push their rate above standard employees in any case.

Hiring companies who think that Consultants should work for the same (or less!) hourly rate than equivalent full timers do not understand the economics of the situation; this has led many consultants to exit the field and reduced the availability of consultants in the marketplace.

Hiring companies want to hire the “best and brightest” … What part of the “best and brightest” would operate as a consultant for less money than they would make as a full timer, in the bottom line analysis? If you find someone who would agree to that, one can almost guarantee they are not the “best and brightest” — certainly not at math anyway.

Hopefully this posting illuminates some of the issues facing the rate that many managers and consultants are unaware of.

All of the costs in 1-3 are true costs born by the company when using full time employees.  #4 is an adjustment cost (the cost of sales) that is passed on by the consultant.

Companies could lower #4 by using more efficient hiring practices (eg, interviewing only 3-4 candidates,  and making a decision within a week). Industry trends away from this baseline (interviewing dozens of candidates and taking a month to reach a decision) raises the costs of sales of the consultant.  It is only fair to pass this along to the hiring organizations, who are “benefitting” from this longer process.

In a future posting I’ll go into more depth about W-2 versus 1099.

The good news here? Hiring Companies who think they are being “ripped off” by their consultants almost universally are not.  In a fair analysis, one will find that the rates are not as far fetched as might have once seemed before the true costs of the Full Timer are appropriately factored in.

DISCLAIMER:  THIS IS NOT FINANCIAL OR CAREER ADVICE; JORDAN IS NOT AN ACCOUNTANT OR TAX PROFESSIONAL; EVERY SITUATION IS UNIQUE; FOR A COMPLETE ANALYSIS TAILORED FOR YOUR UNIQUE SITUATION PLEASE CONSULT YOUR ACCOUNTING PROFESSIONAL OR HR DEPARTMENT.

Agile & Waterfall are two sides of the exact same Coin, and are equally good or bad.

Agile enthusiasts enjoy lambasting waterfall while espousing “Agile”, however the two techniques are exactly the same.

“Waterfall” is basically a Strategic method of attaining goals, and “Agile” is basically a Tactical method for achieving goals.

Both are equally limited; strategy without tactics is ineffective, and tactics without strategy are especially ineffective, especially over a longer term.

Some happy medium (Iterative Traditional) would be best; either extreme is equally good or equally bad depending on the point of view.

However trading in one extreme (“Waterfall/Strategy”) for another extreme (“Agile Programming/Tactics”) is certainly no great improvement, in fact it is merely a change — in this case, swapping one extreme for another.

The solution is not to be found at the extremes, but in the middle.

This has been known for centuries, but has been lost in what Sun Tzu rightfully decries as “Noise.”

Strategy without tactics is
the slowest route to victory.

 Tactics without strategy is
the noise before defeat.
– Sun Tzu

Traditionalists might stand to improve from a little more iterative and incremental cycle, and Agilists could probably stand to improve with a little more documentation, process and architecture.

Any successful campaign must be waged using both Strategy and Tactics, not merely one or the other.

Examples of wars/battles failed by using exclusively one or the other are: The Maginot line was clearly a failure, with far too much emphasis on strategy and little on tactics. The current gulf war is a failure because it was purely tactical in nature (removing “Saddam”) with little though if any given to the strategy of a post Saddam Iraq.

 Hopefully this shows that neither extreme is particularly ideal, and modern planners at all levels should be mindful of both Strategy and Tactics when waging campaigns.

I found a great little list over at Freelance Switch.

http://freelanceswitch.com/humour/top-ten-signs-you-may-be-charging-too-little/

One of my favorites:

Number 6:
Clients pay your invoices in cash from their wallet.

Also check out:

http://freelanceswitch.com/humour/top-ten-signs-you-may-be-charging-too-much/

Number 9:
You’re still living off a job you finished in 2005.

I had been losing space on Drive C for awhile and it seemed odd to me as I rarely store things on Drive C, therefore the space should not be going down.

It ended up I had 255 GB (!) of files stacked up in the Windows Error Reporting Service queue in C:\programdata\microsoft\windows\wer\reportqueue

Definitely worth checking from time to time if you have apps that crash a lot and use Windows Vista