The Zen of “Go Away” Rates

Posted October 6, 2009 * Comments(5)

wine-label-324x205A friend of mine recently revealed a super, ninja-level consultant secret to me.

Whenever his work pipeline floweth over and an unknown client approaches him with a job, he quotes them a ridiculously high rate that he assumes they would never accept.

He calls it his “Go Away” rate.

The only problem is that these clients often do accept his proposal.

In fact, my friend admitted to me with a certain amount of amusement that he has noticed that clients are actually much less likely to balk and haggle over his “Go Away” rate than they are his normal, more reasonable hourly rate.

It reminds me of a recent wine tasting experiment that I read about where subjects did a taste test for a variety of wines and the only piece of information they were given was the price.

Not surprisingly, the subjects of the experiment overwhelmingly reported enjoying the pricier wines more even though the sneaky researchers often swapped the price labels between the cheap and expensive wines.

What is surprising, however, is that according to brain scans that were conducted by researchers during the experiment, people actually did experience more pleasure while drinking the cheap wines that they thought were pricier and not simply falsifying their answers to avoid looking uncultured.

In other words, the wine actually tasted better to them simply because they believed that the wine was higher quality.

While that improves the prospects for many consultants hoping to take that 4 week vacation to the Bahamas this year, what lesson can us poor salaried corporate slaves glean from this experience?

Although most developers don’t have the luxury of being able to quote a “Go Away” rate, they often do (at least on a subconscious level) have the option of giving a “Go-Away” estimate.

Don’t believe me? Consider the following scenario.

Your boss asks you how long it takes to code a CRM system from scratch using your dream technology stack. Do you actually sit down and give him the bad news, which is that the project probably won’t be finished until after he retires or is fired for incompetence or do you succumb to the typical developer’s hopeless optimism and mumble a couple of months?

Now, what if on the same day your boss asks you to give an estimate of how long it would take to change the color of some text on a legacy PowerBuilder app?

Just to make it interesting, let’s assume that the app in question is written using an unsupported version of PowerBuilder. Moreover, the data travels through no less than 6 rube goldbergian layers, the highpoint of which is an excel worksheet written by a disgruntled accountant and a 5000 line .bat file written by the network admin who just sent to prison for embezzlement. To top it off,  it interacts with a mainframe you’ve never heard of that was scheduled to be retired a decade before you started working there.

In the second scenario, would you err on the side of optimism or would you promptly ask your HR person how much time is left before you vest and then multiply that answer by 8 in order to derive your very own “Go Away” estimate?

If you noticed yourself leaning towards the second option, then you may want to stop and consider what we’ve just learned from the wine researchers.

If you over-inflate your time estimate too much, then you may inadvertently make your boss want that change all the more.

Quote too high of a “Go Away” estimate, and you’ll soon find yourself in a product kick-off meeting heading up a team of “high quality” consultants, all of whom are charging “go-away” rates, and listening to your CIO give a sunshine up the arse speech about how the new TCII (Text-Colorization Improvement Initiative) is going to revolutionize the way you do business.

Don’t say I didn’t warn you.

Popularity: 2% [?]

Related posts:

On Crimes Against Duct-Tape, Mental Masturbation, and Pretty Boy Disclaimers

Posted October 1, 2009 * Comments(6)

duct-tape-manI’m deeply sorry.

The post you are about to read is mental masturbation in its purest form.

Its sole purpose is to release the mental tension that has been distracting me and otherwise preventing me from moving on to more productive lines of thought.

Yes, you guessed it. I am about to add yet another blog post to the already tedious list of reactions to Joel Spolsky’s now infamous Duct Tape Programmer Post.

So let’s skip the cerebral foreplay and jump straight in to my naked thoughts on the matter:

  1. Did Joel really think that anyone would feel flattered by the Duct-Tape metaphor? – If you’re resourceful, then you might be able to use duct-tape get a car to the closest mechanic without the aid of a tow truck or keep pipes from flooding the house until the plumber gets there. If you’re McGuyver, you might even be able to fashion a bomb out of it. However, duct-tape is not typically a tool ascribed to artists or a material associated with fundamentally important work. Even Jamie Zawinski, the hero of the post, appears to have taken it for a back-handed compliment. Many of Joel’s ideological allies in the mini-flame wars that ensued also conceded that it was an unfortunate choice of words.
  2. Is Netscape truly the ideal poster child for the ‘Just F__ing Ship It’ movement? I’ll concede that Netscape deserves a prominent place in history for its role in opening the web to the masses, but its long term track record for both quality and business success is problematic at best. Early versions of the browser were widely criticized for being excessively bug laden and the company eventually went bankrupt shortly after the failed rewrite debacle that ended up causing a three year lag-time between releases. Although there’s definitely room to debate exactly who was at fault for the spectacular failure, it seems to me like Netscape wasn’t the best choice to use as a centerpiece for this argument. Perhaps it would have been better to practice the Separation of Concerns principle, one of those crazy design fads that Joel rails about, and split apart the book review thread from the other tangled ball of themes in this post. Then he could have selected a more effective example to illustrate his point.
  3. Does Joel really think multiple inheritance, templates, design patterns, and COM are good examples of the “fadish programming craziness” espoused by today’s architecture astronauts? – Perhaps he just forgot to insert “Imagine you were coding back in 1994” before he went off the latest installment of his architectural astronaut rant. Then again, perhaps it has been a little too long since he’s been on the developer end of things and its time that he stick with the marketing and managerial topics that he have become his staple in recent years.
  4. Does he really not see the conflict of interest in starting a “shipping over quality” crusade while at the same time selling bug tracking software – At the risk of falling victim to a circumstantial ad-hominen, Joel arguing against Test-Driven Development is a little like the proprietor of a fat person’s clothing store attacking the medical establishment for advocating diet and exercise as a way to lose weight. Perhaps he wouldn’t have been the recipient of quite so many pithy twitter jabs if he spent more time over the last few years focusing on substantive topics and less time pimping FogBugz on his blog.
  5. Why the “pretty boy” disclaimer? – This was the most confusing aspect of his post for me. It felt vaguely reminiscent of an old grade school “then I woke up” ending that I used to tack on to stories when I was just too afraid to to commit to their fundamental premise. Was he backpedalling because he realized that extolling “shipping above all else” as a heroic virtue was a fundamentally flawed premise when applied to the software industry at large? Perhaps he was trying to compensate for his unfortunate choice of the duct-tape analogy and reassure Jamie that he wasn’t actually making him the butt of a subtle joke. Then again, perhaps it was just a poor choice for an ending that served only to water down an already questionable piece of writing.

Ah. So much better…

The morning after

So…Um…Joel…AWKWARD…I guess that was pretty harsh in hindsight.

Did I mention that your original book is still among my favorites and that I would probably ask you to autograph on some decidedly non-phallic-looking peripheral device if we ever met in person?

Unfortunately, I still think that your post pretty much sucked. Sorry.

Popularity: 2% [?]

Related posts:

To Take or Not To Take the Nothin’ But .Net Training…That is the Question

Posted September 17, 2009 * Comments(3)

JPIt’s been a few weeks since I’ve taken the Jean-Paul Boodhoo’s Nothin’ But .NET training course and I’ve had enough time and recuperate and reflect more on the experience.

Although I really enjoyed the course and am glad I took it, it seems wrong to just give a blanket endorsement of the course.

I just don’t think that any training course can or should even try to be well suited for every type of person.

With that in mind, I tried to come up with a few helpful criteria to help someone who is thinking of taking the course make their decision.

You may want to take the course if…

  1. You are somewhat comfortable with 3.5 .NET syntax, but really want to geek out on Predicates, Actions, Funcs, and the angle bracket cesspool where they intersect with Generics.
  2. You like using natural language API’s like Fluent NHibernate and are curious about how to construct an internal DSL of your own.
  3. You are a Test Driven Development fanboy, but are looking for cleaner and more innovative ways of writing maintainable tests.
  4. You think design patterns are just swell and wouldn’t dream of writing a Hello World app without at least a dozen classes, but would like to see these principals in practice by someone who really knows his stuff.
  5. You prefer a code-centric approach to learning and want to spend most of your time either coding or watching someone else code rather than simply listening to concept-laden lectures.
  6. You wouldn’t mind a little motivational kick in the butt.

You may want to run away screaming from the course if…

  1. You don’t due well with sleep deprivation.
  2. You are deeply cynical and motivational tangents cause you physical pain.
  3. You view design as hopelessly subjective and are fast to dismiss any additional layers of indirection as over-engineering.
  4. Although you might be interested in learning how to use MVC Frameworks and IoC Containers, the thought of creating your own implementations as a learning exercise seems downright ludicrous to you.
  5. You are NOT someone who is ‘convention promiscuous’ and the thought of doing things like naming_methods_with_underscores immediately sends you into Rain Man mode.
  6. You get frustrated easily whenever you don’t immediately understand what is going on. JP is of the ‘push yourself past your limits’ and ‘learn by immersion’ school of thought when it comes to teaching. Unless you are in the top 5-10% of programmers, you’re probably going to feel pretty lost at various points of the course. If you are someone who can’t deal well with that feeling, then this course is probably not be for you.

Great Big Fat Disclaimer – I get the feeling that the content of JP’s courses tends to change pretty dramatically from month to month. This is a testament to his own talent and discipline when it comes to being a continual learner. However, it also means that you should probably take characterizations of the course (like this one) with a grain of salt.

Some Essential Preparation Tips For Those Crazy Enough to Take It- For those of you that have decided to take the plunge and sign up for a future Nothin But .NET course, I highly recommend that you take the course preparation seriously. At the very least, you should do the following:

  1. Watch all of his DNR TV design videos – JP demonstrates design principals continually throughout the course, but doesn’t really take the time to explain them up front. It is helpful if you have a good grounding in these to begin with.
  2. Learn and Practice R# short-cuts – JP is a true ReSharper Jedi and therefore his coding demonstrations can be hard to keep up with if your brain isn’t already used to taking the mental shortcuts that R# allows you to take.
  3. Practice using his BDD Library Extensions – I feel pretty comfortable with TDD and am used to BDD-style naming conventions, but the fluent interface style BDD library that JP wrote and uses in the course through me for a loop at first. I wish I would have taken the time to get used to it more before the course.
  4. Sleep extra the week before the course and consider staying in the hotel even if you are local – In the words of a good friend of mine, “No amount of Starbucks makes you smart at 2:00 am”, at least not after 17 straight hours of intense training. It didn’t help that I only got a few hours of sleep the first night because of a sick baby at home, but I definitely would have been better off if I had tried to get extra sleep the week before.

That’s my two cents.

Any alumni out there want to offer a dissenting opinion?

Popularity: 1% [?]

Related posts:

Writing an SVN PreCommit Hook in .NET that integrates with Jira

Posted September 14, 2009 * Comments(2)

What are Subversion hooks and why would you use them?

Hooks are extension points that allow you to add behavior at various stages of the commit process through an executable file.

The most useful one is the probably the pre-commit hook because it allows you to prevent a commit from occurring, thus providing a way to enforce whatever policies that can dream up to help your development process run more smoothly.

We use it to ensure that developers enter a valid Jira key into the commit notes, which is a crucial step in making our code review process as painless as possible.

How do pre-commit hooks work?

All you have to do is create a console application or script named pre-commit and copy it in the hooks directory of your repository. Subversion will automatically execute any application following this convention before each commit.

The repository path and transaction id associated with the commit will be passed in as the first two arguments, thus allowing you to look up relevant information about the revision before making the decision about whether or not to allow the commit to occur.

To prevent the commit from happening, all you have to do is exit with a ‘1′. You can even display an explanatory message to the user (at least in TortoiseSVN) by writing to Console.Error.
SVNHook_tortoiseSVN_Failure_Message

Using SharpSVN to Avoiding Command Line Parsing Hell

During my first attempt at implementing a hook, I programmatically spawned a process and executed svnlook.exe to extract the information I needed about the revision.

This worked fine for simple cases, but quickly began to require some serious Command Line Parsing-Fu in order to accomplish what I wanted. At that point my “There-has-to-be-an-easier-way” alarm went off in my head, so I began to search around for a pre-built API to simplify the task.

I soon found SharpSVN, a stable open source project that is used by AnkhSVN and SharpDevelop.

Aside from a few annoying testability issues that forced me to create wrapper classes in order to do unit testing, I had a good experience with the framework and would definitely recommend it over rolling your own.

Integrating with Jira

Jira exposes a large portion of their functionality through web services that you can access by simply turning the “Accept Remote API calls” option on in the General Configuration area of the administration page.

We use the key parsed from the comment to query the Jira web service and verify that the referenced issue is in an opened state and has a fix version that has not already been released.

Downloading the Code

I zipped up a sanitized version of our pre-commit hook that you can download and either use as a learning sample or modify for your own use.

Popularity: 2% [?]

Related posts:

Should We Change the Way We Name Interfaces in .NET?

Posted September 8, 2009 * Comments(28)

swimming-against-the-streamAs part of the Nothin But .Net training experience, JP Boodhoo encouraged us to try out a few non-standard naming conventions that has adopted recently.

The one that intrigued me the most was his convention for naming interfaces.

Rather than taking the Microsoft sanctioned approach of adding an I prefix to all interface names, JP adopted the convention used in the Java world of reserving the unadorned name for the interfaces and instead adding an Impl suffix to the end of the concrete classes that implement the interface.

Actually, this was actually not the first time I’ve been exposed to this convention.

I have a vague recollection of Dru Sellers making a similar case for using this convention a few years ago when I worked with him. However it didn’t make nearly as much of an impression on me at that time because I wasn’t in the habit of using interfaces except when I wanted to achieve polymorphic behavior and I had already used up my base class.

Since then I started using interfaces for almost everything except entity classes. I first went down that path out of necessity because it was a requirement of Rhino.Mocks, but after I started reading about the SOLID principals and getting a better understanding of the benefits of loose coupling I adopted the approach as a de facto design guideline.

Now that interfaces play a much more central role in my code, it makes perfect sense to me that they should take precedence over concrete types when striving to create names that make my types more readable.

It also strikes me as odd that the naming standard for interfaces is clearly a vestige of the days when Hungarian notation (e.g. strName, intAge) ruled supreme. If Microsoft actively discourages the use of Hungarian notation in the case of every other type, then why should this one be any different?

When I first considered the possibility of going against the Microsoft standard, I worried about the confusion it would cause for future developers.

However, my experience in the course was that it was only confusing for the first day and then I actually grew to like it once I internalized the convention and started relying more on my color scheme of my IDE to immediately distinguish interfaces from classes.

I especially liked how the new convention served as a constant reminder of the central role that interfaces should play in my design.

Is anyone else out there using this convention?

Is it folly to swim against the stream in this regard?

Popularity: 3% [?]

Related posts:

Newsflash: Killing Zombies Increases your Typing Speed

Posted September 6, 2009 * Comments(2)

Here’s a fun productivity enhancing tip that I picked up from JP at the Nothin But Net course I just took.

If you’re much of a gamer, then Typing of the Dead, an old Sega game that was released in 1999, will probably make you wince due to the poor graphics and absurd storyline. In fact, it appears to have won the dubious honor of being runner up in one of PC World’s top 10 worst games list.

Nevertheless, I’m hooked.

blog_typing_game

It could be because I’m one of the only men under 40 that I know who doesn’t own a gaming system and therefore have incredibly low standards when it comes to games. In fact, the last one I remember owning was an Atari back in High School.

It might just be because I have a soft spot in my heart for zombies every since I read World War Z: An Oral History of the Zombie War.

Whatever the reason, I’ve been dismembering hoards of zombies in the last week and hopefully increasing my typing speed in the process.

If you’ve already mastered a tool like ReSharper and are looking to eek out some more productivity by simply increasing your typing speed, then I recommend downloading a copy of the game here and giving it a try. It installs through a simple setup bat file.

It is no longer being sold, so there is no need to worry about pesky copyright laws.

Happy typing.

Popularity: 1% [?]

No related posts.

Creative Idea for Improving Your ReSharper Skills

Posted September 3, 2009 * Comments(0)

This is a screenshot of my current desktop.

I exported a snapshot from the ReSharper Default Keymap pdf and set it as my desktop background. I got the idea from Jean-Paul Boodhoo when I asked him how he had become so proficient at using ReSharper.

Popularity: 1% [?]

Related posts:

Random Thoughts on Day 2 of the Nothing But .NET Course

Posted September 2, 2009 * Comments(1)

I woke up this morning in a semi-zombie state and just learned that tonight will be our “late night”, which means we’ll go until 2 or 3 am instead of midnight. Nevertheless, I’m still enjoying the course.

Here’s some thoughts about the second day of the course (yesterday).

  1. Actions, Predicates, and Funcs…Oh My - We started the day with a wrap up of all the work we did with delegates from day one. This is when the lightbulb finally went off in my head on the differences between the Actions, Predicates, and Funcs types. They are just convenience wrappers for delegates with different signatures. If you need to pass around a method that returns a bool, then you’ll want to use a Predicate (filtering & matching). If you just need to store a void method, then pick Action. Otherwise, if you’re working with a method that returns a value, then Func is what you’ll need.
  2. Imitate, Assimilate, Innovate – This is a model that represents the stages of learning. I realized that I spend too much time in the imitate stage (adapting googled code) and almost no time in the innovate stage. One of the first goals I selected for myself this week is to spend more time in the innovate stage. A long term goal is to eventually launch an open source project. Kudos to Dru and Rob, two former co-workers, who took this step already.
  3. JP’s BDD framework – This is a fluent interface that replaces test attributes, asserts, and obscure mocking API’s with more a fluent interface that reads more like an English sentence. It disoriented me for a while, but the syntax is starting to grow on me after a few days of using it. Check out this post for a sample of the syntax.
  4. Rewriting frameworks from scratch – The first day we implemented LINQ extension methods from scratch. Yesterday we wrote the routing portion of a basic MVC Framework. Today we’ll be writing an IoC container from scratch. These sound like an inane “reinventing the wheel” tasks, but they are meant to be simple exercises to help us practice good design. Not only did it help increase my conceptual understanding of the lower level infrastructure I’ve been using, but it was also very empowering to temporarily counteract the long term trend of consuming API’s and frameworks at that are higher and higher on the abstraction stack..
  5. Coding Centric Course with no Lab Manuals – Most training courses that I’ve attended or taught have provided students with detailed instruction manuals on how to complete the lab portions of the course. By contrast, JP cuts you loose with minimal direction. It was frustrating at first, but then I saw the value as soon I noticed how focused I was when he finally showed us the solution. It made so much more sense than it would have otherwise once I had some context based on first hand experience.
  6. Using Delegates to Test the Untestable – Probably the most memorable technical epiphany I experienced yesterday was when JP showed us a technique for testing methods that contain static framework methods or concrete framework classes without interfaces, both of which are unmockable when using RhinoMocks. By turning the methods into delegates that are private member variables, we were able to use interaction based testing to verify that the methods were invoked and that all the correct parameters.

Popularity: 1% [?]

Related posts:

Some Lessons from Day 1 of Nothin But .Net

Posted September 1, 2009 * Comments(4)

I’m working on 2 hours of sleep last night thanks to my 17 month old, so I thought I would record some of my thoughts about my first day of training yesterday before they are completely lost in the haze of sleep deprivation and the blur of day two.

  1. Delegates are like onions: there are many layers to peel back and prolonged exposure sometimes makes you want to cry.
  2. Slamming a Mountain Dew at 9:00 PM to help to make it through the last few hours of class seems like a really good idea…until you get home and try to go to sleep.
  3. JP codes hella fast. I really need to make a commitment to go mouseless and dig even deeper into R#.
  4. Internal DSL’s are fun to consume, but creating them is like drinking day old Folgers coffee through your nose.
  5. The branching and merging story in Git is way better than it is SVN, but you’re forked if you rely on everyone in the class being able to pull from GitHub through a hotel network.
  6. Goals are powerful. I think I’ve been aiming way too low lately.
  7. Unlearning is sometimes more difficult than learning.
  8. Training should be as much about getting inspired and having your baseline expectations blown away than about learning specific content.
  9. I wish I had taken JP’s course sooner and will recommend it to everyone I know.

Time to go refill my caffeine IV before class starts.

Popularity: 1% [?]

Related posts:

Essential Tool List Reloaded

Posted August 31, 2009 * Comments(1)

Here’s an update to my Essential Tool list that I published last year. I highlighted all of the additions and changes in red.

I’m in JP’s Nothin’ But NET course this week, so I’m guessing that I’ll have many new ones to add shortly. However, I’ll probably also be so worn out from the class that I won’t be able to publish it for a while. The prep work alone almost did me in…:-)

As always, any new suggestions are welcome.

Development

Code Analysis

Development Lifecycle

Debugging

Utility

MISC

Essential WebSites

Popularity: 2% [?]

Related posts:

Next Page »