Tim Barcz

Resharper 5.0 - Bookmarks

Tim Barcz — Fri, 09 Oct 2009 18:35:00 GMT

Today it was announced that Resharper 5.0 will soon be introduced as part of the public EAP (Early Access Program). As one on JetBrains .NET Academy Experts I’ve had access to Resharper 5.0 for a few weeks. While in the coming weeks and months you’ll hear quite a bit from developers who are trying out Resharper 5.0 I wanted to alert you to one of my favorite features at this point.

Bookmarks

I read a lot more code than I write. When exploring new projects, doing code reviews, tracking down a bug, I like to mark different paths the flow of execution may take. Most often to keep track of call stacks and what goes where, I usually end up using a piece of paper with a pencil drawing lines to various methods and interfaces. I could use Visual Studio which has had the concept of bookmarks for some time. You can put a bookmark in code which creates a bit of a mark in your file that you can come back to later.

The problem with these bookmarks is that they’re flat and don’t and you get options of previous or next, but never the opportunity to define what “next” means? Hopping from bookmark to bookmark may not actually follow any intended path you meant to take when you placed the bookmark.

Resharper 5.0 introduces the concept of bookmarks where you can set order.

Now I can happily bounce around code and easily inspect different control flows in a much more controlled fashion.

ReSharper has been part of my toolset now for several years and I think what they’re doing is great. While ReSharper 5.0 is a bit buggy at times I like it and the improvements it brings. I am looking forward to further EAP releases of ReSharper and encourage you to check them out as well. Should be coming by the end of this month.

Git…Command-line or GUI?

Tim Barcz — Wed, 07 Oct 2009 19:15:02 GMT

A short quick post to get some feedback from you, the reader.

I’m working to learn and transition to Git (using Jason Meridth’s great series on Git). Up to this point I’ve been using the command-line only, working to learn Git on the command-line before I rely on a tool or GUI abstraction. Recently I’ve been going through some refactoring on a project where I’m using Git. Right now I’m slow, really slow. Renaming files/classes for example is cumbersome to say the least.

I got to wondering if knowing the command-line is even useful anymore or it just a geek badge of honor that a few developers like to point to proudly when talking about skill sets? Some part of me feels like using a tool like GitGUI or TortoiseGit is “cheating”. Ironically I admire Git because it seems to let me work the way I want to work; branch often, local commits, easier merging and yet right now the command-line use of Git is my primary roadblock. It is at this point that I start thinking I should give up on the command-line since an SCM tool shouldn’t be intrusive and move to a GUI tool and give up my chances at fifth degree black belt geek.

So what do you think?

Use command-line go slow now but know the tool very well.
Use GUI and go faster, however always be reliant on the GUI abstraction

Is using a GUI “cheating”?

Ship Software With Value

Tim Barcz — Tue, 29 Sep 2009 18:49:24 GMT

The blogosphere has gone a bit crazy the last few days with posts responding to Joel Spolsky’s latest article about "The Duct Tape Programmer". Bloggers everywhere are tossing their two cents in and saying what parts of Joel's post was good and what wasn't good. Once noticeable trend is that many have jumped on the "just ship it" bandwagon.

There’s a quote mentioned by Jamie Zawinski in the article:

“Yeah,” he says, “At the end of the day, ship the f---ing thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

I don't know Jamie and I imagine the context that the comment was made in was based around some pre-existing level of candor with the person he was speaking. We really don’t know what “…ship the f---ing thing” means in the context of that conversation and what level of quality is expected in that scenario. I would agree with Joel/Jamie that shipping products is important and that often developers (myself included) run the risk of becoming too entrenched in a design or beauty and all too easily miss the point of developing software...which is to ship a product that adds value. However...”shipping” is only part of the picture. As someone responsible for the value of the product my team ships, I’m keenly aware of what affects shipping early can do (both the positive and negative).

I'm reading a lot where people say "just ship it" but I've been part of teams where shipping too soon costs more money in the long run (and sometimes not even “the long run” but a few days/weeks down the road). These pro “ship it” bloggers surely must be talking about non-critical business systems when we say "just ship it"; would you want to ride on a plane where the flight control systems were sent out with bugs? Even a measly 1% failure rate of airplane system is unacceptable and is enormously expensive both in dollars and reputation for an airline.

The point is that shipping is the point but not the whole point, it's only one aspect of a well delivered software product. Shipping software with value is the point. Ship too soon with bugs and the value gained by shipping is potentially lost. Conversely shipping late provides no value at all. Neither lobbing a piece of crap over the wall at your customers early, nor refactoring your code till it shines is the point, neither should be considered a success. There’s a sweet spot that you need to find. Keep in close contact with your customer, if you pay attention they’ll let you know when you’ve crossed into either extreme.

Testing URL Generation on Routes in MVC Framework

Tim Barcz — Thu, 27 Aug 2009 05:15:00 GMT

Today I wrote some code to output URLs in a certain manner in an ASP.NET MVC project. The code I wrote was extremely simple, but I struggled, I mean S-T-R-U-G-G-L-E-D, to write tests against the new code and ensure correctness. I could easily very visually that it was working but the amount of setup and kludge around ViewContext, RequestContext and ControllerContext was causing me to pull my hair out.

I tweeted my frustrations as I packed up and left work for the day and got the following responses soon thereafter:

@TimBarcz outbound routing is still hard, sadly (from @subdigital)

@TimBarcz …a way to test #aspnetmvc a helper to reduce the ridiculous noise/setup would be helpful (from @ehexter)

Determined to not give up I pulled down the MVCContrib source and started to peck away. I’m working on committing and finalizing the code but here is a sneak peak of the changes. Hopefully you agree that it is an improvement.

Before:

   1: [Test]

   2: public void Should_correctly_generate_session_url()

   3: {

   4:     new RouteConfigurator().RegisterRoutes();

   5:     var builder = new TestControllerBuilder();

   6:     var context = new RequestContext(builder.HttpContext, new RouteData());

   7:     context.HttpContext.Response.Expect(x => x.ApplyAppPathModifier(null)).IgnoreArguments().Do(new Func<string, string>(s => s)).Repeat.Any();

   8:     var urlhelper = new UrlHelper(context);

   9:     string url = urlhelper.RouteUrl("session", new { sessionKey = "this-is-the-session", conferenceKey = "austincodecamp" });

  10:     url.ShouldEqual("/austincodecamp/sessions/this-is-the-session");

  11: }

After:

   1: [Test]

   2: public void should_be_able_to_generate_url_from_named_route()

   3: {

   4:     OutBoundUrl.OfRouteNamed("session").ShouldMapToUrl("/sessions");

   5: }

And

   1: [Test]

   2: public void should_be_able_to_generate_url_from_controller_action()

   3: {

   4:     OutBoundUrl.Of<FunkyController>(x => x.New()).ShouldMapToUrl("/Funky/New");

   5: }

Much, much cleaner and easier on the eyes.

It’s not quite done yet and has some holes (accepting additional route values, etc) but it’s worthy of discussion and once completed should make one very frustrating aspect of testing in MVC even easier.

Zero Defects In Software, Setting a Higher Bar

Tim Barcz — Wed, 26 Aug 2009 18:04:37 GMT

Several months ago I published a letter to upper management about improving software processes. In that post I laid out what our team needed to do to be more effective at our jobs. Since that letter nearly five months ago, I have been promoted to management myself and now manage the team. While some might say I’ve gone to the dark side, I would vehemently disagree. The role certainly has changed me but I like my role because I still am a developer and know that high quality solutions do mean dollars in our pockets because we’re able to adjust/react more quickly.

I just got done reading an article over my lunch break and it caused me to shake my head in one key spot (emphasis mine):

It’s very difficult, if not impossible, to build and maintain a dynamic web site that works flawlessly every moment of every day for every customer. Between implementing new content, changing technology, managing internal stakeholders, and designing for customers who have different objectives, learning styles, and backgrounds, you could never produce a 100 percent error-free site. After all, to err is human.

Have we really set the bar that low with quality in software? I think we need to raise the bar. A few months ago I took a stand with my letter to management, here is a similar email I wrote to my team recently which works to combat the thought process and acceptance of poor quality so rampant in our industry:

All,

As a developer I've worked on systems and rarely, if ever, have we set the bar so high as to have zero known bugs in the system. I think often this is looked at as "too lofty" or "impossible". Well, the development team here currently has one bug and is fast approaching zero. It IS possible.

In our department we often talk of "demonstrating competency and expertise". The flip-side of setting such high expectation is that we can shatter our reputation quickly with even a few small issues or bugs. Chris has said that developers are like airline pilots and that you only hear about them when something goes wrong. There's a lot of truth in that. You expect a pilot to get you somewhere safely - people expect our software to work.

I think we should not shy away from holding ourselves to an excessively high standard. Frankly, I'm more familiar with how to do it as a developer having years of building software to gain knowledge and experience from. I don't have all the answers on how do this from the other aspects but I don't think this means we stop trying. I think quality should be the first and highest goal. Speed should follow quality. If you're keeping a high quality standard and feel overwhelmed that the work is backing up behind you and you can't ensure the highest quality, please don't hesitate to talk to me about it and we'll see if priorities can be reworked.

As a team we're setting a positive direction for our department and its future. As we continue to refine our processes and expectations within each subgroup be aware of the lasting impact of the work we do. Be vigilant about improvements in the process we can make. If you see areas where you see quality slipping, pull the "red cord" and stop the process from going further until the quality is fixed. We want anything that leaves this department to be of the highest quality, whether a proofing round or a final product build. Don’t rely on other departments to back us up. If we operate in this manner we'll only build further credibility and reputation within the company.

Tim

What about you? What’s your stance towards bugs? Think zero defect is too lofty?

RhinoMocks Exploration : RhinoMocks “Caching” Values?

Tim Barcz — Fri, 21 Aug 2009 22:26:00 GMT

Occasionally on the RhinoMocks mailing list a question pops up about various pieces of the framework that people struggle with. This post is the first in hopefully an ongoing series where I address specific underpinnings of RhinoMocks to you, the reader. I’ll do my best to explain the inner workings of the code and what is going on under the covers while trying to keep it “real”. If you have specific things you want to see, let me know and I will do my best to put together the tutorial.

That said, let’s get started…

Occasionally a question will come in about RhinoMocks caching a value and that something must be a bug in the framework. Consider the following very simple test where we want to return the current date/time from a property getter. You have a component with a gettable time but no setter. In order to fake this out we use the Stub() method return a "known" value.

   1: [TestFixture]

   2: public class TimTests

   3: {

   4:     [Test]

   5:     public void DateTimeDive()

   6:     {

   7:         var stub = MockRepository.GenerateStub<IFoo>();

8:

   9:         stub.Stub(x => x.Current).Return(DateTime.Now);

10:

  11:         Thread.Sleep(5000);

12:

  13:         Console.WriteLine(stub.Current);

  14:     }

  15: }

16:

  17: public interface IFoo

  18: {

  19:     DateTime Current { get; }

  20: }

What time do you suppose is written out the console given the Thread.Sleep cal? The common thinking is that the Stub() method stores a method to be called to return the value at the time of execution when in reality what is happening is that the stub.Stub(x => x.Current).Return(DateTime.Now) line is evaluated at runtime at the time the Stub is set. Therefore, in the above code, the Console.WriteLine(stub.Current) will actually write the time from 5 seconds (5000 milliseconds prior) when the stub call was made. In other words, when Stub() is called, the resulting value is calculated and ready to be returned, it's not deferred for execution.

What is going on is that deep in the bowels of RhinoMocks there are things called Expectations, MockStates, and Recorders. In the code above, when Stub() is called, what happens is a two step process (but appears as one, given the fluency, or dot-dot notation, of the call).

    1. An expectation is created with a null return value (stub.Stub(x=>x.Current))
    2. The expectation is updated with the known return value (.Return(DateTime.Now))
    (Note that if you try to write code without the second piece, you will get an InvalidOperationException when you try to use the stubbed property stating:
        failed: Method 'IFoo.get_Current();' requires a return value or an exception to throw.
        System.InvalidOperationException: Method 'IFoo.get_Current();' requires a return value or an exception to throw.
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Expectations\AbstractExpectation.cs(342,0): at Rhino.Mocks.Expectations.AbstractExpectation.ReturnOrThrow(IInvocation invocation, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Impl\StubReplayMockState.cs(63,0): at Rhino.Mocks.Impl.StubReplayMockState.DoMethodCall(IInvocation invocation, MethodInfo method, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Impl\ReplayMockState.cs(118,0): at Rhino.Mocks.Impl.ReplayMockState.MethodCall(IInvocation invocation, MethodInfo method, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\MockRepository.cs(678,0): at Rhino.Mocks.MockRepository.MethodCall(IInvocation invocation, Object proxy, MethodInfo method, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Impl\RhinoInterceptor.cs(96,0): at Rhino.Mocks.Impl.RhinoInterceptor.Intercept(IInvocation invocation)
        c:\OSS\Castle\Tools\Castle.DynamicProxy2\Castle.DynamicProxy\AbstractInvocation.cs(202,0): at Castle.DynamicProxy.AbstractInvocation.Proceed()
        at IFooProxybc98a6ed8f1b4aa3b9ea36d89f80e6af.get_Current()
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks.Tests\TimTests.cs(43,0): at Rhino.Mocks.Tests.TimTests.err()
    There is an "expectation" created when the call is made and that expectation is added to a recorder (There are ordered and unordered method recorders, by default (the most common scenario) you will be using unordered recorders). These recorders record the mocked object (our stub object here), the method being called, and the "expectation". The call to .Return(DateTime.Now) updates the expectation with the desired return value. In the RhinoMocks framework this code is very simple but it's important to note this value is executed at the point this code is run.

   1: public IMethodOptions<T> Return(T objToReturn)

   2: {

   3:     expectation.ReturnValue = objToReturn;

   4:     return this;

   5: }

You can see from the code above that setting up a return value simply updated the expectation's return value.
I hope you've followed the above code. The RhinoMocks codebase is not simple per se and you do not need to understand it in depth to use it but I think in this case it help (as I see it often pop up on the mailing list).

So what do you do if you want something to be called in a delayed fashion? In our example I want the call to IFoo.Current to represent the DateTime.Now when I call it (as opposed to when I set it up). To do that, simply use the "Do()" method. Here is an example that provides the same functionality as above, only the return value of the Stub is deferred until the stub is actually called.

   1: [Test]

   2: public void Realtime_results_with_Do()

   3: {

   4:     var stub = MockRepository.GenerateStub<IFoo>();

5:

   6:     stub.Stub(x => x.Current).Do(new Func<DateTime>(() => DateTime.Now));

7:

   8:     Thread.Sleep(5000);

9:

  10:     Console.WriteLine(stub.Current);

  11: }

I hope this helps a bit with the confusion around RhinoMocks and perceived "caching" of values. If you have questions about this or other areas of RhinoMocks, I would love to tear into them for you, just ask!

Invoke.CallFor(()=> Speakers).For(IowaCodeCamp.Version(4))

Tim Barcz — Fri, 21 Aug 2009 03:48:00 GMT

Not too long ago Iowan developers had to travel to other states to get to a code camp. Now, a few short years later, Iowa, on November 7th, is having it's fourth Iowa Code Camp in Des Moines. I'm writing today to officially announce that we are now accepting speaker submissions for the event. I encourage you to think about what excites you about .NET and software development and how you can impact software developers in the Midwest with your topic. Code camp attendees are typically talented developers who demonstrate their dedication to their craft by coming to a learning event on a weekend. High quality content, such as that topic that just popped into your head or that topic you've been waiting to speak on, are the kinds of sessions our attendees are looking for.

To submit a session or three, simply go to http://iowacodecamp.com/Speakers.aspx and follow the instructions there.

The deadline to submit is September 23

A few quick notes:

Speaker and session selection is done by the Iowa Code Camp leadership. We'll accept as many sessions as we can hold and will work to balance between advanced and beginner level topics
You may (and are encouraged) to submit more than one abstract

Special note to new speakers or people interested in speaking at a code camp for the first time:
Code camps are a great way to enter the world of speaking and "dip your toe in the water". If you've thought about speaking before and have a topic you're knowledgeable about, consider taking the next step and submitting a session. Iowa Code Camp welcomes new speakers and works hard to provide a very friendly environment to present for the first-time presenter.

Moving to Kanban : A Mentoring Session

Tim Barcz — Thu, 20 Aug 2009 03:49:00 GMT

After my recent post about our software team moving to Kanban I got an email from Derick Bailey asking how he could help with our transition. Derick graciously offered to meet with our team and help with any questions we may have and provide guidance as someone who has traveled this path before.

We met for a little over two hours on Monday and recorded the discussion. You'll find that we bounce around a little bit which is because what you're hearing is a team working in Scrum learning about Kanban. This wasn't scripted. It is a teams honest questions about how one would go to Kanban and how to put the right pieces in place to make it succeed.

Derick and the guys at LosTechies have set up the hosting for this on PabloTv: Check out the first Adopting Kanban video

Book Review: Web Design for ROI

Tim Barcz — Fri, 14 Aug 2009 13:19:00 GMT

So I've been on a kick lately to publish book reviews of books I've been reading. I hesitated at writing this review given the nature of the book tends to be more around design than it does around code. I decided to write the review for a few reasons:

Designers, who also code, may read this blog
If you work on a web site you should care about the design since it will affect the success of your site as well the way you code

I wouldn't normally have picked up this book, instead favoring usability books by Jakob Nielsen or Steven Krug or other well known usability personalities. However, back in May I went to the ACCM Conference (Annual Conference of Catalog and Multichannel Merchants) and sat in a day long seminar by the authors of this book, Lance Loveday and Sandra Niehaus. Both were very knowledgeable and presented their material well and as such I was interested in the print version of the seminar, this book, Web Design for ROI.

Part I - The Big Picture

The first part of this book talks about some of the principles of what design can do and the state of web site design as a whole. If you're reading this page chances are good that you have worked for sites that pay little attention to design. If you have not worked for such a company, you can easily think of one in which you are a customer.

There is a good case made for revisiting design aspects of the site as an investment in future profitability. Quite often a site that is "up" is considered done and work soon begins on the next set of features without really watching to see how a page or set of pages is performing. Are people finding what they are looking for? Is it clear on a page what someone should do next? This book presents the idea that web design is never done and really it's a constant effort to tweak pages to see changes in the analytics.

Chapter four introduces the idea of user testing which, after being exposed to it a several years ago has been a closet interest of mine. Analytics are brought into the picture here too but again all stuff that is pretty basic if you're already in the web space and are actively tracking users and patterns. If there is one thing I learned from this section is that even the most minor changes to a web page, things most developers would scoff at, can have a dramatic effect on the performance (ROI) of a page.

Part II - Design Guidelines

This section of the book goes through different pages on an e-commerce site, landing pages, checkout, product detail pages, and of course the home page. I liked how each of these pages were featured in their own chapter. Throughout this section I appreciated the full color screen shots of examples. My only issue was with the softness of some of the advice. Granted it may be presented this way because design is really a case-by-case basis and there is really no one-size-fits-all. Or it could be that the authors feared putting concrete advice in the book only to see their advice (and book) quickly become outdated. I'm not sure.

Conclusion and Final Thoughts

This book was a very quick read and did add to my knowledge a bit but more importantly got me thinking about design and usability, which is always a good thing. If you're looking for a few ideas and conversation starters with your design staff then I would pick it up. If you're new design and analytics this book can be a good primer as the various terms and definitions are given in the sidebar at times and inline. If you're in the e-Commerce space already and have been doing design for some time, I think you may be disappointed in the book because many concepts are things you would probably already know. The problem for me may lie in the intro where the authors talk about who this book is for

"These days it takes a village of people to inspire, envision, create, and maintain a web site. This book is for everyone in that village. We've attempted to make the book useful and accessible to people with a range of experience levels"

In my opinion they cast their net so wide they missed the mark. Having sat in on a seminar with Lance and Sandra, I can confidently say they know their stuff and some of that came through in the book. The problem ultimately lies in the quote above. With making this book appeal to everyone it appeals to very few because it never achieves the depth that I've seen that both Lance and Sandra have. Ultimately Lance and Sandra have a wealth of information and quite honestly I would have liked to have seen possibly two books which go into much deeper depth than this single book which scratches the surface.

Jet Brains Development Academy Welcomes Another

Tim Barcz — Wed, 12 Aug 2009 02:55:00 GMT

A few years ago I was introduced to ReSharper (JetBrains) from a co-worker (Thanks Grant!). Having always been one who desires to move more quickly through code and take advantage of any shortcut I can, ReSharper felt like "coming home".

Last week I was invited to be part of their development academy as a an academy expert. For those of you not aware of this hidden gem that JetBrains has created:

Members of the Academy are recognized experts in various areas of software development. They contribute to Java and .NET communities by advocating best development practices through formal and informal publications and meetings, and serve as a versatile source of expertise.

I'll be entirely honest and say that I don't consider myself an "expert" in anything, let alone ReSharper. Yes, ReSharper is an integral piece of my development environment and an extension of my finger tips, but I'm always coming across new key commands or features that were always sitting there, begging me to use them, making me realize, I can stretch this tool a bit more (or is it the other way around?).

The reason I'm so fond of ReSharper is that development tools litter the .NET space. This is plainly visible by picking up a magazine and thumbing through it, taking notice to all of the component manufacturers and tools available. The quality and usefulness of some of these tools can often be called into question. ReSharper, however, is a pleasure to work with. Even in it's memory hogging days (around version 4.0) I didn't mind it so much, the productivity gain was entirely worth it (version 4.5 works beautifully). There are tools that I like having and tools that I must have. Had the company I work for not purchased ReSharper, I would have paid for it out of my own pocket. I can't say that for a great number of tools out there.

Coding Contest: Create a Programming Pearl

Tim Barcz — Mon, 10 Aug 2009 03:14:00 GMT

The other day I was solving a seemingly simple problem. While solving the problem I came across several hiccups one could have to consider (I say could given some unique environments this problem could surface in, ie. performance a primary concern). While working the solution to completion, I got to thinking about other ways I could solve the problem. It got me to thinking Programming Pearls, a great book about solving problems effectively.

Now that I've "solved it" myself, I'm curious what you could, the readers of this blog could come up with and I, by extension, can learn from.

The Problem at Hand

When given some text as an input, that text could include some "bad" characters. For example, in Microsoft Word when typing a hyphen, Word will change the hyphen to a dash, since grammatically speaking a dash is different from a hyphen and most often you, the Word user, mean to use a dash so Word puts on there for you (thumbs up on the usability aspect of this feature Microsoft). The problem is, the dash character that Word uses is not in the ASCII character set.

With this program, we don't want to allow a certain subset of characters, and instead replace the characters with a different character. Using the Word example of a dash and a hyphen, I want to scrub uses of a dash and replace with the hyphen.

Here are some other common ones:

Character	Correct ASCII Value	Bad Values
Hyphen	45	8208, 8211, 8212, 8722, 173, 8209, 8259
Single Quote	39	96, 8216, 8217, 8242, 769, 768
Double Quote	34	8220, 8221, 8243, 12291
Space	32	160, 8195, 8194

What the code should do is simply take in a string, and output the string with the offending "bad" characters replaced with a specified character (using the table above). Very simple.

I've provided the stub code here and a unit test, to provide an example, based on the table above...fill in the blank and submit!

   1: [Test]

   2: public void Input_with_bad_characters_should_be_replaced_with_approprate_character()

   3: {

   4:     var badChars = new[] {(char) 96, (char) 8216, (char) 8217, (char) 8242, (char) 769, (char) 768,

   5:         (char) 8220, (char) 8221, (char) 8243, (char) 12291,(char)8208, (char)8211, (char)8212,

   6:         (char)8722, (char)173, (char)8209, (char)8259,(char)160, (char)8195, (char)8194};

   7:     var badString = new string(badChars);

8:

   9:     var cleanedString = CleanInput(badString);

10:

  11:     Assert.That(cleanedString, Is.EqualTo("''''''\"\"\"\"-------   "));

  12: }

13:

  14: public string CleanInput(string input)

  15: {

  16:     // your details here

  17: }

The Judging

The judging of the winner will be entirely based on my discretion. I'm looking first for correctness, that the problem is in fact solved. After that I'm open to seeing what you can do. The only limit is your creativity.

The Prize

I am offering up your choice of a book from Addison-Wesley or a $25 gift certificate to ThinkGeek

I am thoroughly excited to see what you can come up with....

(Please post submissions ~~as a comment~~ to http://gist.github.com Leave some way for me to get in contact with you)

Updates

Update #1: Please Make All submissions from hence forth to http://gist.github.com (Thanks Tuna)

Update #2: I will stop reviewing submissions one week after post date

Update #3: Feel free to leave your comments on who you think should win and why (I still reserve the right to overrule you :-))

Moving to Kanban, Did Scrum Fail?

Tim Barcz — Fri, 07 Aug 2009 03:25:00 GMT

Several months ago our software team decided to dive into the Scrum process. What we were doing before that simply wasn't working. The project had unstable delivery dates and we knew something needed to change.

Fast forward about four months and we're going to take a shot at using Kanban and leave Scrum behind. Quite surprising since I blogged that Scrum was a pretty good development methodology. Why change if Scrum is so great? Did Scrum fail? Is Kanban that much better? Is Kanban Better than scrum? Read on fellow Kaizenista.

Why Change To Kanban?

The developers that I work with are professionals at their core. For us we want to deliver code, we want to make an impact. We want a consistent process that brings us maximal results. We want a process that aides our development and doesn't impede it.

I work for the world's largest motorcycle parts and accessories dealer. The code we right is in high demand, we want to get it out to the world as soon as possible. Scrum imposes sprints and releases (several sprints) on the team. We found that we don't work that way. If a feature is "done, done, done" we promote it to production we don't wait for an arbitrary end of sprint. This seems to fit better with Kanban.

Secondly we want to reduce lead times, see features get implemented quicker. While we saw a huge improvement with the adoption of scrum, the idea of a pull system versus a sprint backlog would have meant shorter lead time in several cases in the recent past.

There are other reasons, but they all point to our desire to produce more. Upper management has been quite pleased with scrum. They see consistent work being accomplished and goals being met and the team quite happy. I had a discussion with my boss today about Kanban and was initially hesitant given only four months of using scrum. He was thrilled with the idea of us working in ways to improve the process.

Did Scrum Fail?

I was asked my thoughts on a similar question on the drive home tonight by Chris Missal. I absolutely don't think Scrum failed. Scrum was a huge improvement and has shown us that it is okay to experiment and tweak with processes. Had we adopted Kanban several months ago rather than first going through Scrum I believe our Kanban process would not have gone over well. Quite simply we wouldn't have done it right. Now, after having worked in Scrum, we're transitioning to Kanban to address very specific points where we see waste.

Is Kanban Better than Scrum?

Nope, Scrum is a perfectly fine solution and I don't have a negative thing to say about it. For us Kanban seems to work more the way we work.

It's like putting on a tennis shoes to go golfing in then later trading in the tennis shoes for a pair of golf spikes. The spikes are better than tennis shoes but the tennis shoes are better than nothing (barefoot).

It's a better fit. For the way our process flows and how we work, Scrum was like golfing in tennis shoes, it was an improvement but there are better optimizations to be made. If Scrum is working for you, great. For us we wanted to try Kanban.

How are you Going to Start?

First, we don't know much about Kanban. No one on our team carries certification like I do with Scrum. Therefore we're going to leverage you, the community, and our passion to learn and improve. We're going to use post's from great authors and teachers like Derick Bailey who posted yesterday (very well timed Derick) about "How To Get Started With Kanban In Software Development". We're going to become student of Kanban and more importantly process improvement. Ultimately I don't want the fear of something new to stop of from trying something that could help us. You have to experiment, tweak, and never be satisfied where you sit, you can always improve something.

I'll keep you all posted as we go forward. My hope is that the improvement we saw with Scrum will be magnified and we'll see similar improvements with Kanban.

Will keep you posted.

Help: My Twitter Account Was Suspended

Tim Barcz — Tue, 04 Aug 2009 04:48:00 GMT

After a really good evening at CRineta, I hop online to post a final tweet of the night only to see that my account has been suspended:

Very strange indeed. I've looked over the terms of service and to be honest I can't see where I've faltered at all.

*Sigh* If I'm silent on Twitter for the next few days you'll hopefully now know why? If you by chance know someone who knows someone at Twitter who can escalate this please by all means let me know.

Welcome Krzysztof Koźmic

Tim Barcz — Tue, 28 Jul 2009 02:38:00 GMT

It is my pleasure to announce a new voice to the Devlicio.us community, Krzysztof Koźmic. Krzysztof, also called Xtoff, has been putting out great content on his personal blog for some time. He is a committer on the popular open source Castle Project and is my DynamicProxy yoda having put out what I consider the most complete tutorial on DynamicProxy on the internet.

I've had the pleasure of working with Krzysztof on the RhinoMocks mailing list and solving problems and helping community members there and I look forward to writing alongside him here and learning from him in the months to come.

You can follow Krzysztof's blog at http://devlicio.us/blogs/krzysztof_kozmic/

Welcome Xtoff!!

Book Review: The Art of Unit Testing

Tim Barcz — Thu, 23 Jul 2009 16:16:00 GMT

Over the last few years my blog has been filled with posts imploring testing and sharing techniques about testing. Most recently I’ve been speaking at code camps on how one can begin unit testing, sensing that a large majority of people out there don’t yet have the level of comfort with testing. Given my personal commitment to software quality through testing, I was excited to get my hands on a copy of Roy Osherove’s The Art of Unit Testing from Manning. A few weeks ago our copy was delivered and I have been excited for an upcoming vacation which would give me the time to sit down and churn through the book.

Part I – The Basics of Unit Testing

In part one Roy defines unit testing. Roy takes a similar approach as the one that I use, explaining early on that we all do unit testing in one form or another. Too often I hear from people that they don’t have time to unit test. The reality is, and Roy makes this point very well, is that we never hand over code right after writing it. We all take some time to “test”. Some people write unit tests. Some write a simple app to test various scenarios and yet others will run the whole application.

Roy takes the time early on to contrast a unit test with an integration test. This is a masterful move on Roy’s part as the confusion between unit testing and integration testing is one that even seasoned testers don’t always seem to understand. It sets the stage early and well for the introduction in part two of the use of isolation frameworks.

In this part of the book Roy introduces us to a sample application that carries us throughout the book. I always appreciate it when books do this. The consistent sample application allows the user to follow the addition of new concepts more easily than examples that jump around. Roy focuses solely on the NUnit framework which is something I plan to take with me when I give future talks on unit testing. In my talks I introduce users to NUnit, MbUnit, as well as xUnit. My thought process has been to inform the listeners of my talk to the different options available. After reading the book, Roy’s approach of presenting a single framework to the user is a much better approach. It allows the reader to go deeper with a single framework which will benefit the reader much more than the surface knowledge of several frameworks.

Part II – Core Techniques

This section goes into depth quite a bit on how to introduce “seams” (“…places in your code where you can plug in different functionality…”). I appreciate the effort Roy goes to in this chapter to explain how you exactly break apart your designs. He takes a methodical and thoughtful approach to design patterns that many out there have never used.

I was pleased to see the introduction of stubs as a concept outside of an isolation (mocking) framework. I take a similar approach when I talk about RhinoMocks and isolation frameworks. While Roy ends up talking about RhinoMocks (an isolation framework) he makes sure the reader understands why the framework is useful. Ultimately this is a benefit to the reader as they no longer become a drone using a framework advertised by a respected book author but instead are informed and make the decision based on what is best for their situation.

Roy also goes into detail about the differences between Stubs, Mocks and Fakes. These questions are something I encounter often when talking about “mocking”. The move towards simplicity and clarity was refreshing. In general for the mass public terms like “Test Doubles”, “Spys”, “Dummy”, “Fakes”, provide little to no value and only add confusion. Roy takes a similar stance and does a very good job clearing the air and setting the reader on a course for success.

As someone with a vested interest in RhinoMocks I was pleased to see it’s coverage in chapter 5. There were times where I questioned what Roy was doing (the introduction of strict mocks) but soon recovered with further explanation about the topic. I will say that I was not a fan of the use of the record/replay syntax in the book and the subsequent AAA syntax (which was really record/replay). I really can’t fault Roy on this because I believe that RhinoMocks 3.5 was released after Roy began working on the book.

Part III – The Test Code

This part of the book covered more of the non-code aspects to unit testing such a build automation, project structure, and inheritance for tests. In the beginning of the section Roy writes:

“In chapter 7, we’ll look at the three basic pillars of good unit tests – readability, maintainability, and trustworthiness – and look at techniques to support them. If you only read one chapter in the book, this should be it”

I questioned why this seemingly crucial chapter was in Part III of the book and not part of Part I (The Basics). Further, the importance of chapter 7 only appeared in the introduction to Part III and the reader would not find it unless they were already there.

Chapter 6 felt a bit out of place to me in the book. The inclusion of test class inheritance patterns isn’t something I see often in codebases nor the use of generics in tests, which was another pattern mentioned. Much of what was contained in this chapter seemed like common sense to me. I trust that Roy and the editors/reviewers of the book have seen enough instances to believe otherwise, hence the inclusion of this chapter in the book.

The information in chapter 7 was very good and I do agree with the statement (quoted above) that appeared in the introduction to the section. While I maintain the information may have served the reader better had it been presented in an earlier section it did not feel out of place or ruin the flow of the book.

Part IV – Design and Process

This section again is a section where the book undersells itself. Having spoken in the past about unit testing at several code camps, questions constantly comes up about the political aspects of testing. Developers question how they can bring it into their organization or how they can explain the benefits to other developers or even upper management. This section of the book does a great job at anticipating the common questions and how to best make unit testing efforts succeed. It addresses ways to help your unit testing efforts succeed and demonstrates ways that will cause those efforts to fail. Despite my previous adoption and enthusiasm for testing I still found the information in this section very useful and worthwhile.

Chapter 9 goes into testing legacy applications. The entirety of the book up to chapter 9 is spent on testing with the assumption that the developer has the ability to change/create the design. I believe this is a vast minority of people out there. Chapter 9 entices readers by talking about how to introduce testing into a legacy code base. The idea of graphing the priority of components in your system was something new to me but is very interesting and seems to be a thoughtful “scientific” way of attacking an untested legacy application. In general this chapter is shorter than I would have preferred but I believe that the majority of information that could be here would be out of the scope of this book which is why the chapter makes references to Michael Feathers' book Working Effectively with Legacy Code. (Not e to self: Buy Michael Feathers book)

Conclusion and Final Thoughts

This book is a must own, buy it. It covers unit testing from start to finish and will get you up to speed on unit testing rather quickly while giving you a solid foundation to build upon in the future. My only gripe with the book is that it generally undersells itself, which is a great position for a book to be in (the reader believing the book contains more value that was thought when the purchase was made).

I am generally not surprised that I enjoyed the book. I’ve closely followed Roy’s blog for several years and cut my unit-testing teeth on much of the advice contained on his blog. Roy is well respected in the community as well in the unit-testing circles and this book does the developer who reads it a great service in advancing their abilities in writing solid, testable code, a goal all of us should be striving after.