Then again, it might just be because C# 4.0 has received little fanfare compared to the LINQ and lambda magic unveiled in C# 3.0.

Whatever the reason, I didn’t get around to installing Visual Studio 2010 and experimenting with the new C# 4.0 features until just a few days ago.

Optional and Named Parameters, the first feature that I’m excited about, appears like a pretty minor feature on the surface but it has the potential to eliminate a lot of noisy “ceremony code”.

The concept is very simple and familiar to anyone who has specified a default value in a SQL Server stored procedure.

Up until now, when we’ve wanted to provide defaults for a method in C# and offer the API consumer a more concise way to call the method, we’ve had to rely on overloading.

Take the following common case code snippet as an example:

   1: public void TakeOrder(string name)

   2: {

   3:     this.TakeOrder(name, "Americano");

   4: }

   5:

   6: public void TakeOrder(string name, string drink)

   7: {

   8:     this.TakeOrder(name, drink, "grande");

   9: }

  10:

  11: public void TakeOrder(string name, string drink, string size)

  12: {

  13:     string order = String.Format("{0} wants a {1} {2}", name, size, drink);

  14:     orders.Add(order);

  15: }

Although the client code below is nice and concise, the method definitions contain a lot of duplication.

   1: StarbuxWench wenchDuJour = new StarbuxWench("Russ");

   2: wenchDuJour.TakeOrder("Brian");

   3: wenchDuJour.TakeOrder("Grif", "Mocha");

   4: wenchDuJour.TakeOrder("Kim", "Latte", "tall");

   6: wenchDuJour.PlaceOrder();

You might not notice it at first because you are used to it, but imagine if you had to provide a separate sproc definition for each optional parameter in a stored procedure.

Besides being noisy and high on “ceremony”, overloading is suboptimal because it doesn’t make the default values that are being utilized explicit, which can sometimes lead to unpleasant surprises for the consumer. I recently experienced this first hand when I wrongly assumed that the default value for comparison type for String.Compare was a case insensitive comparison.

Another limitation of overloading is that it requires a unique combination of types, which means that I couldn’t provide an overload with just name and size because they are both strings and I already have a definition with two strings (name and drink).

Now consider the C# 4.0 alternative:

   1: public void TakeOrder(string name, string drink = "Americano", string size = "grande")

   2: {

   3:     string order = String.Format("{0} wants a {1} {2}", name, size, drink);

   4:     orders.Add(order);

   5: }

Besides being much more concise and saving you the trouble of having to modify your code every time you want to expose a new parameter combination, it also solves the unique type combination limitation as well as hiding default parameteres from the client.

Here you can see that I’m skipping the second parameter by using the new named parameter syntax, which should be very familiar if you’ve ever worked with ruby.

   1: wenchDuJour.TakeOrder("Jacob", size: "grande");

Here’s a snapshot of the intellisense, which makes the defaults explicit.

As I mentioned before, this feature is pretty trivial when compared with lambdas or LINQ, but anything that removes cruft from my code is a welcome addition to the language.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The last time I found myself in this position was several years ago during my pre-mocking days when my test suite was taking an hour to run, the majority of my test failures were data-related ghosts, and the sql-laden setup and teardown sections of tests were painful to create and even more painful to maintain.

Now I find myself facing similar types of friction even though the causes may be different. Tests require too much effort to write due to mocking requirements, especially in areas of legacy code that need to be refactored to use dependency injection. Test failures are too often false positives caused by simple refactorings due to the tight coupling caused by interaction-based testing. The overall number of tests is difficult to manage from the perspective of documenting system behavior or being able to quickly discover whether a test already exists for a particular piece of functionality that is being modified.

As a result, our department has clearly stalled in its effort to incorporate TDD into our everyday development process and now I’m trying to figure out how to rectify that.

My current thinking is that the best way to make TDD a viable and sustainable option is to selectively use it only when it provides a net gain in value.

I know that this is somewhat of a blasphemous thought because TDD\BDD is more about design than automated testing, which means that it is supposed to be baked into the development process and therefore not optional (or so I thought).

Although I have definitely experienced moments where TDD has improved both the usability and elegance of my design by making me start from the perspective of the API consumer and incrementally add features in the simplest possible way that works, I have also seen plenty of cases where it provides little or no benefit in terms of design. For example, I often seem to write code that must fit into an existing design, follows a well known pattern, or only slightly modifies an existing method.

The same holds true for refactoring. While there have definitely been times where TDD has improved the quality of my code by providing a safety net that allows me to catch more bugs and refactor more freely, there have also been times when I’ve gained little value in this respect due to the simplicity of the code. In fact, lately I’ve noticed that there have actually been times when I have been less likely to refactor a section of code due to TDD because it had a large number of interaction-based tests around it that would all have to be changed to accommodate the implementation changes.

Finally, let us not forget that any and all code is intrinsically a liability. Since test code tends to grow at a much faster rate than normal code, the long term maintenance cost of your test suite becomes even more of an important factor to consider.

Ultimately, it seems as though some criteria for making a simple cost-benefit analysis are in order to help decide when it make sense to use TDD.

So far I’ve come up with the following:

When to write a test:

1. The design is unclear.
2. You’re implementing an important or complicated piece of business logic.
3. You’re about to implement a hack or sub-optimal solution because you’re afraid of breaking something in an existing piece of messy, complicated code.

It also occurred to me that just because you write a test doesn’t mean that you have to commit it. There are several design artifacts (whiteboard, napkins, etc) that are extremely helpful despite being disposable. Occasionally writing throw-away tests would certainly allow me to gain the design benefit without incurring the cost of maintaining a test that has little long term value.

With that in mind, the following scenarios seem like reasonable examples of when it makes sense to take the extra step of committing a test:

When to commit a test:

1. The code is important to the business and heads will roll if someone unintentionally breaks it.
2. The code is complicated and the next poor schmuck who touches it to make an enhancement has a good chance of unintentionally breaking it.

Other ways to improve the cost-benefit ratio of testing:

1. Use SRS to isolate important business logic – By favoring small classes and composition and focusing your testing efforts at this level rather than a higher level where they all meet, you will drastically reduce the setup cost of mocking out all the dependencies that probably aren’t relevant to your test anyway.
2. Favor state-based testing over interaction-based testing – I’ve run into a  few scenarios where interaction-based testing has been a blessing, but it seems like more often than not it just leads to inappropriate coupling with the implementation details that results in brittle test code. Use it sparingly.
3. Make test suite spring cleaning a post release ritual – Nothing succumbs to entropy like code. Test code is even more critical to keep clear, concise, and organized, because this has the potential to represent the specifications of how your system works. If something is no longer important delete it. If the test name isn’t clear or the folder structure isn’t optimal for finding features, then invest the effort to change it. Otherwise, the broken window theory will take affect faster than it takes Visual Studio to load.

Am I way off base here? Does anyone else have additional criteria for deciding when it makes sense to remove yourself from TDD mode?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Rating - 1/2  (out of 5)

Prerequisites – This book doesn’t assume any prior knowledge, but it helps if you’re familiar with some basic Agile concepts. If you’re like me and prefer to have some mental hooks in place before starting a non-fiction book, then also take a few minutes to read the wiki summary page first.

The Good

1. Easily Consumable – Unlike the vast majority of technical books, this one is well structured, concise, and well written. The authors package up the information in 7 easy principles and 22 tools which neatly correspond to chapters and subsections. Weighing in at a slim 180 pages, many of which contain easy-to-read project anecdotes, business novelettes, and case studies, the book can easily be read in the span of a week.
2. Broadly Applicable – This book is all about concepts and principals that can can be applied incrementally to almost any scenario. In other words, you can still get value from it even if you don’t have the desire or the freedom to change your current development methodology.

The Bad

1. Management Genre – It has been a while since I’ve read Dante, but I’m pretty sure that at least one of the inner circles of hell is dedicated to making developers recursively read management drivel until they beg for mercy. While this book is very developer-centric and arguably has potential to greatly improve the quality of life for the average developer, it is still firmly grounded in the business-management genre and thus may inevitably irritate developers in a number of subtle ways.
2. Too Vague at Times – While the focus on broadly applicable principles has its strengths, it could also be frustrating for someone who is looking for a more concrete and instructional guide to help them overhaul their Software Development Lifecycle. This book is probably best used in conjunction with other more detailed and prescriptive resources.
3. Potentially Out-Dated – Despite being written in 2003, this book remains remarkably relevant. However, it is not at the forefront of Lean-inspired thinking these days and does not take into account the lessons learned from the front-line agilistas over the last 7 years. Based on some preliminary research, it appears that the current Lean-inspired trend is focused around Kanban, which you can find out more about here and here.

Conclusion – As long as none of my negative bullet points are deal breakers for you, then I would go ahead and recommend reading the book. If your bookshelf already over-floweth or you can’t justify spending another penny on tech books, then this might be a good one to “thoroughly browse” cover to cover at your local bookstore over a series of lunch breaks.

Related posts:

1. Book Review: the CLR via C# As promised, here’s my review of the January book, the...
2. Return of the Becoming a Better Developer Meme: My 2010 SMART Goal When I first started writing this blog, I devoted several...
3. Technical Book Sequels: A Case Study in Trying to Salvage a Second Edition In a recent post, I raved about Jon Skeet’s book,...

Related posts brought to you by Yet Another Related Posts Plugin.

The Bug: We recently upgraded one of our desktop apps from .NET 1.1 to 3.5 and our tester reported that it immediately crashed during start-up on a 64-bit machine (both XP and Vista). There were no problems with it prior to the upgrade and it still worked fine on 32 bit machines (…or rather, it did after we fixed all the cross-threading exceptions). The event viewer only showed a rather unhelpful unhandled exception in the Kernel32.dll (exception code 0xe0434f4d).

The Mystery: Why would upgrading an app cause it to stop working on a 64 bit machine? Wouldn’t upgrading it make it more rather than less likely to work on a newer machine?

Clues:

1. We have another desktop app that went through a similar upgrade but experienced no problems on a 64 bit machine.
2. The desktop app in question uses the default build configuration.
3. The application references an older ActiveX component.

Helpful Facts:

1. 64-bit machines support running applications as both 32-bit processes and 64-bit processes. The simplest way to find out if an application is running as 32-bit is to look for the *32 suffix in task manager. When testing a pre-upgraded version of the app, the suffix was there. After the upgrade it wasn’t there.
2. 1.1 apps automatically run as 32-bit processes, but 2.0 apps can be run as either. On 64 bit machines, the OS looks at a flag in the PE header of the executable to determine which type of process it should run in. The flag is set by the compiler and can be ‘x86’, ‘x64’, or AnyCPU. AnyCPU means that it will run as a 32-bit process on 32-bit Windows and as a 64-bit process on 64-bit windows. The default configuration in Visual Studio is AnyCPU.
3. A 64-bit process cannot load 32-bit dll’s – The application will crash with a BadImageFormatException.

The Culprit: The problem was obviously the ActiveX Control, which was a 32-bit dll. It didn’t cause problems before the upgrade because the application was forced to load in a 32-bit process since it was using the 1.1 framework. Once it was upgraded, it started loading in a 64-bit process because of the ‘AnyCPU’ default configuration we were using.

Our Solution: We simply changed the build configuration to ‘x86’, which forces our app to run in a 32-bit process. I read where you can also make an out of process COM server that wraps the 32-bit dll, but that seemed like more work than we were willing to do at the time.

As I warned, nothing particularly complicated or earth-shattering, but some good fundamentals to be aware of when debugging apps on 64-bit machines.

Anybody else have interesting 64-bit bug war stories or helpful hints?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Rating - (3 out of 5 stars)

Prerequisites

1. IL Tutorial – Although most of the samples in the book are in C#, there are several key code samples in IL and the book doesn’t provide much help for the uninitiated. I think I got a few hundred pages into the book before I relented and took a 100 page reading detour through the first couple of chapters of Advanced .NET Programming so that I could get a better grasp of the basic IL instructions and concepts. My reading sessions went much more smoothly after I did that.

The Good

1. Illustrative scenarios with diagrams – I’ve read about value and reference types, the stack and the heap, boxing and unboxing, and the generational algorithm for garbage collection several times before, but I felt like this was the first time that I moved beyond a superficial conceptual understanding. This is primarily due to Jeffrey Richter’s approach of providing concrete code-based examples interspersed with helpful state diagrams. The picture to the right from his “How Things Relate at Runtime Section” in Chapter 4 shows the contents of the thread stack and heap as of a certain line in a simple code sample. His diagrams showing the contents of the heap, the finalization list, and the freachable queue as of each line in the sample code from his chapter on automatic memory management were also incredibly helpful in understanding how garbage collection works.
2. Critical Analysis – The author periodically presents some strong and sometimes unexpected opinions on various topics through the book. Despite disagreeing with him on several points, such as sealing classes by default or avoiding the use of properties, I always felt like I gained new insights from reading his arguments. For example, I never knew that switching from unsealed to sealed breaks backward compatibility or that the JIT compiler produces more efficient code for sealed classes because it can call it non-virtually. Neither argument was enough to outweigh the testability issue in my mind, but it did give me a better mental hook to assimilate the knowledge than just reading a bunch of random facts in the style of a reference book would have.
3. Novel Perspective – A few years ago I probably would have dismissed the book based on the title and the frequent use of IL as code samples because my focus as a developer was much more on the language than the runtime. Much like with the hardware on my computer, I expected the virtual machine my code was running on to just work for me and preferred to be shielded from what was under the hood whenever possible. However, as new language features rely more and more on the compiler to perform the magic, the potential for gaining insight into the language by moving closer to the runtime and looking at the IL (Intermediate Language) that the compiler generates increases dramatically. For example, rather than having separate chapters on anonymous methods, lambdas, and closures like most C# books, this book simply has sub-sections in the delegate chapter entitled syntactic shortcut # 1, 2,3, and 4. The decision to use that structure alone did more to provide insight into these new features than the vast majority of other C# books that I have read.

The Bad

1. Lack of editorial discipline – I have to admit that I experienced periodic bouts of boredom with this book because there were sections that read like reference manuals (e.g. tables with API descriptions) or else included excruciating details about edge cases that seemed to be included more for thoroughness than as a way to explore or illustrate an important concept. This was particularly frustrating because I found myself jumping into skim mode or not fully paying attention and thus almost missing the scattered gems. In my opinion, the book could have gone from good to great if an editor had told him to put a disclaimer about not being comprehensive in the Forward and then challenged him to trim at least a 100-150 pages from the book. In order for a book to be great, it has to hold my attention for the majority of the time and this simply didn’t do it.
2. Outdated coding conventions (nitpicker’s corner) – It was pretty easy to ignore this, but I have to admit that it threw me for a loop to see all the m_ variable prefixes in the code samples. I thought it was especially odd since the book was published from Microsoft Press since Microsoft has officially discouraged Hungarian notation for quite a while.

What’s Missing?

1. A larger perspective on virtual machines – I would have loved to have read a chapter that explained where the CLR fits into the larger picture of virtual machines. It would have been nice to know a little bit of history as well as some analysis of what is innovative about Microsoft’s runtime and what is lacking in comparison to other execution engines such as the JVM.

Recommended Sections & Chapters (for lunchtime perusal at the bookstore)

1. How the Runtime Resolves Type References (Chpt. 3 – pg. 85)
2. How Things Relate at Runtime (Chpt.  4 – pg. 107)
3. Reference and Value Types (Chpt. 5 – pg. 123)
4. Boxing and Unboxing Value Types (Chpt. 5 – pg. 129)
5. Exceptions (Chpt. 20)
6. Automatic Memory Management (Chpt. 19)
7. Threading (Chpt. 23 & 24)

Conclusion – It definitely qualifies as one of the seminal .NET technical books that you should probably try to read it if you’re serious about increasing your depth of knowledge about C# and the CLR. However, if you do find yourself starting to lose interest while reading, then I recommend give simply yourself permission to skim sections that you are already familiar with. There are too many hidden gems in there to let the slow sections derail you from reading it cover to cover.

Related posts:

1. Book Review – Lean Software Development: An Agile Toolkit I just finished my February book from my 2010 tech...
2. Technical Book Sequels: A Case Study in Trying to Salvage a Second Edition In a recent post, I raved about Jon Skeet’s book,...
3. On C# in Depth and the State of Old School Technical Publishing I recently downsized my technical library and got rid of...

Related posts brought to you by Yet Another Related Posts Plugin.

Although I was inspired by a certain unnamed developer’s public quest to read a book a week for six months, I never chose reading technical books as one of my goals.

I’m not sure why I didn’t consider reading technical books as a worthwhile endeavor at the time. Perhaps it was because I was overly infatuated by my RSS reader or maybe I was just fixated on the burgeoning list of tools, frameworks, and open source projects that I had only recently become aware of after finally branching out from my Microsoft-centric comfort zone.

Whatever the reason, I now find myself with a very different perspective on what will help me grow the most as a developer.

For one thing, after reflecting on my own strengths and weaknesses I realized that I have been focusing on breadth of knowledge for too long and now need to concentrate on increasing my depth of knowledge about software development. I decided the best way to remedy this current imbalance was to embark on a methodical journey to finally read the dozen or more high quality books on software development that I currently have collecting dust on my shelves.

My 2010 professional goal is to read one of the technical books in the picture below each month for twelve months and then do a blog post reviewing each one.

When I first hatched this plan a few months ago, I put some serious thought into the best way to ensure that I would actually meet this goal. I knew that publicly announcing an ambitious goal would provide some motivation, but probably wouldn’t be enough, especially since I have been apt to abandon blogging for 4-5 month stretches these days.

Instead, I opted to take the SMART approach, which is acronym that describes the characteristics of well formed goals. I first read about in Pragmatic Thinking and Learning: Refactor Your Wetware and was impressed how such a simple concept really helped me to refine my goals in ways that made me much more likely to achieve them.

How did I make my goal SMART?

• S – Specific – I didn’t just make a vague statement about reading more technical books. Instead I went to the trouble of picking out exactly how many and which ones I was going to read (although I left the order unspecified to give me a little bit of freedom to pursue what was most interesting or relevant to me at the time).
• M – Measurable – Writing a blog post review after finishing each book not only serves as a clear finish line for each monthly goal, but also provides a good way to mentally assimilate the information in each book from a SQ3R reading perspective.
• A – Achievable – I didn’t want to make myself miserable for a year with unrealistic demands on my time, so I sat down and thought about the maximum number of hours I could realistically spend doing technical reading in a week (10 hr) as well as how many pages I average an hour on technical reading (25 pg) and how long my biggest books were (800 pg). After doing the math, I figured out that I could realistically handle one book a month, especially if I alternated between easy and challenging books. So far I’ve validated my hypothesis by successfully tackling one of my toughest books in January, CLR via C# by Jeffrey Richter, and also being ahead of schedule for finishing my February book, Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck.
• R – Relevant – Besides addressing my concerns about focusing too much on breadth of knowledge and not enough on depth, I also found these goals to be particularly relevant to me because I had just received 6 new ones in the mail due to my amazon gift certificate windfall that I got from taking JP Boodhoo’s Nothing But .NET class last fall and thus was suffering from a nasty spike of unread book guilt.
• T – Time-Boxed – Setting clear time deadlines is essential in order in terms of both motivation and measuring success. I chose one month reading iterations because they were easy to track (my January book is…) and it kept me on a brisk yet sustainable pace.

As I already mentioned, I’ve completed one of my books so I’m off to work on my first review.

Related posts:

1. Book Review – Lean Software Development: An Agile Toolkit I just finished my February book from my 2010 tech...
2. return thoughts.Where(x => x.IsCaffeineInspired) It’s too hard to pick just one topic to delve...
3. Technical Book Sequels: A Case Study in Trying to Salvage a Second Edition In a recent post, I raved about Jon Skeet’s book,...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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?

Related posts:

1. Some Lessons from Day 1 of Nothin But .Net I’m working on 2 hours of sleep last night thanks...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

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.

Related posts:

1. Frictionless Code Reviews Having a second set of eyes on your code has...

Related posts brought to you by Yet Another Related Posts Plugin.