Tim Barcz

The "Risk" of Open Source Software Support

Tim Barcz — Tue, 30 Jun 2009 03:18:00 GMT

Quite often there is a fear that surrounds open source tools and frameworks. For most shops the deciding factor against open source software is the apparent "risk" that is associated with a framework/tool that is not attached to any business entity.

In this post I want to share an interaction that occurred this last weekend to show you that the open source ecosystem is alive and very healthy. And while I won't go so far as to say the "risk" doesn't exist (you have to come to that conclusion on your time when your own fears are allayed) I do hope that this post puts some of those fears to rest.

Saturday morning before I went off to work there was a question posted to the RhinoMocks mailing list (for those who don't know RhinoMocks is an open source mocking framework). Before the end of the day the problem was resolved to a satisfactory conclusion. The "solution" (I put in quotes because there appears to be a bug but at least now we know there is a bug...hence "solution"). The result is not as important as the events that transpired to reach that conclusion below is the timeline.

12:22 AM - Kenneth posts the problem he is encountering

6:53 AM - I respond on the mailing list back to Kenneth with my findings and let him know that I will get some experts in DynamicProxy involved

6:56 AM - I enlisted the help of Krzysztof Kozmic on twitter (Krzysztof is a committer on DynamicProxy by Castle as has a great tutorial series on Dynamic Proxy)

8:38 AM - Fellow Devlicious blogger Tuna Toksoz (also a committer on the Castle project) hopped on the case and reported his findings

9:22 AM - Krzysztof responds to Tuna's findings reporting back on the root cause

10:23 AM - Kenneth reported back with feedback of Tuna's fix

Ultimately, as I mentioned earlier the fix was that it was found that RhinoMocks "relies on the buggy behavior, hence the error" (Krzysztof's words). Again the result here isn't what is important but rather the journey. Often people fear the support ecosystem around open source software but the exchange above and the players involved should give you some bit of confidence in the support of open source. It is worth pointing out that all of this happened on a Saturday, something you'd pay a premium for in a closed source model.

Whatever your roll in the software world is, one aspect you have to consider when choosing any solution is risk. The traditional thought has been that with commercial software the support would be better when backed by a reputable name. I think the exchange showcased above demonstrates that support for open source software can compete (and potentially surpass) support that any commercial piece of software could offer. Keep that in mind the next time you are evaluating commercial software versus open source software.

The Holy Grail is NOT Automation

Tim Barcz — Fri, 29 May 2009 02:05:00 GMT

Often times as developers who understand what computers can do is really limitless, we seek to automate everything. The holy grail is being able to sit at where everything is accomplishable with a simple double-click. Often times automation, however wonderful or geek drool inspiring, is not cost effective.

Once a month we have to update sales tax rates in our system. We have a program that does the update but needs two vital pieces of information which are supplied to us a few days before the end of the month via an email. These two pieces of information are a download file location and a password. We enter the two pieces of information as command line args to the program and off we go. The whole process takes about a minute.

While running the update today there was a brief discussion about how we could possibly automate the whole process. Ideas floated around like reading the email and parsing the text for the download location and the password. In order to do this we'd have to write an program which:

Can connect to our Exchange server or a mailbox on our system
Scan the inbox for the particular message you are looking for
Parse out the two pieces of information from the email
Launch the original program passing in the two pieces of information we just gathered

Let's say for a moment that you're a good programmer. I mean ayende good. How long does it take you to write this? An hour? Two? Ten? A week (40)? Let's be real aggressive developers here with over-inflated sense of skill for a moment and say we can do this and have it production ready in an hour. If it takes us a minute to run by hand, then it will take us 5 years to get a return on the investment we put into the project. If we're more down to earth and estimate the project takes 10 hours, we will absolutely never see a return on that time spent because your application which needs the tax information will be rewritten, trashed, or abandoned long before the 50 years it would take to start seeing a return. I was glad to hear it when my fellow developers came to this conclusion as well. Automation is great to a point when it saves time. Any effort beyond that is hard to justify and could be seen as wasteful.

Regular Expressions, Your Job Requires Them

Tim Barcz — Tue, 26 May 2009 02:18:00 GMT

In preparing my talk on Regular Expressions that I'll be giving this upcoming weekend at the Chicago Code Camp I decided to repost this article which I originally posted in February of last year. Rereading the information contained within my position or thoughts on developers and regular expression have not changed.

I've thought about writing this post several times over the past two years. Having had regular expressions come up three times last week, I thought it time to address the lack of programmers out there who understand regular expressions. The sheer amount of fear surrounding regular expressions and the work that goes into avoiding them is astonishing.

Last year I used to troll around the asp.net forums and quite frequently I would answer the regex questions. One question was posted which illustrates the problem with regexes among developers.

"...and i also i need to add a validator for the password textbox where the user is required to fill atleast [sic] 6 characters"

I suggested a solution to the problem using a regular expression validator. Making sure there are at least 6 characters, is a simple regex (example: \w{6,}), and yet my solution was met with skepticism. The following was said, in the event a change was requested,

"Putting a new version of a web site can take a surprising amount of time than can go into man-weeks".

Man-weeks?!?!? To change a regular expression?!?!? I see two problems, first the original developer who didn't know that regex would easily solve their problem. The second problem is the other developer who doesn't know regex advocating his way as "the way", in effect, spreading his ignorance. The first developer is easily forgiven, the second is not.

It's been said programmers can't program when faced with a simple FizzBuzz test, Imran states:

"Want to know something scary? - the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution."

I'll pile on. You want to know something scary? The majority of professional programmers can't write regular expressions, even simple ones. I'm not the first to say this. Last year, at the ALT.NET conference, Scott Guthrie made the following statement when talking about routes in the new MVC framework:

"It's pluggable, so you can use Regexes...<some incoherent stuff>...if you wanna use regexes you can. What we found is, regexes are super powerful, but only about 10% of people actually understand 'em."

Are regular expressions easy to understand? Well, let me ask you, was HTML easy when you started? Were you born understanding the following HTML?

<fieldset class="CheckRadio">
    <div id="OngoingEventContainer">
        <input type="checkbox" id="OngoingEvent" name="OngoingEvent" value="1" />
        <label for="OngoingEvent">
            This is an ongoing event (no dates and times)
        </label>
    </div>
</fieldset>

If you understand the above, you didn't always. My guess is that at some point you buckled down and learned HTML because you're job requires it. Well, if you're a programmer, web or windows, you need to know regular expressions, your job requires it, it's that simple.

Regular expressions have been around so long that they're deeply ingrained in many of the tools we use. Christopher Bennage illustrates how regular expressions solved a recent problems in Visual Studio. In a recent post he posts:

"Then I realized that I was missing the simple solution. Ctrl+F and a regular expression!"

I don't know that many people would be able to come to the conclusion that Christoper did. It's my belief that regular expressions are fundamental, yet the average developer doesn't treat them as such. They're ultimately doing themselves a disservice.

Regular Expressions are a tool that should be in every programmers bag. If you don't understand regular expressions and do a google search every time you need a regular expression, shame on you! It's time to bite the bullet and learn regular expressions.

Iowa Code Camp v. 3.0

Tim Barcz — Fri, 10 Apr 2009 03:52:00 GMT

After two successful iterations of the Iowa Code Camp it only seems fitting to have a third. This third version will held May 2nd in Cedar Rapids, Iowa at Kirkwood Community College continuing the trend that Iowa Code Camp will move to serve its constituents all over the state. I'd like to thank my former employer Geonetric for coming through in the clutch and helping out with securing/sponsoring a great location.

I want to echo the call for speakers that fellow coordinator Greg Wilson recently put out:

NOTE: I do apologize that due to logistical issues with securing the location and date this call for speakers is coming much later than normal. We, as leaders, have been working since early January on several possible locations/dates and just received confirmation on the final facility yesterday. Please help us in getting the word out to as many potential speakers as possible as fast as possible.

Topic ideas:

We are looking for 4 basic types of sessions:

1) We are welcoming non-.NET centric topics. Hopefully, we can have another full track of "alternative" stuff. Java, 'nix, Mac, Drupal, open source, etc.

2) Beginning 100-level sessions targeted towards students and/or developers from another technology. Things like: LAMP Programming 101, Getting started in the .NET world, What college doesn't teach you, Developing Java with Eclipse 101, User Interfaces 101

3) Nice, meaty .NET sessions - The core of any code camp

4) Audience driven sessions. We are planning to have various format sessions of experts that the community can ask questions to. We need volunteers to be in the sessions as "experts". We have various discussion groups (fishbowl, open topics, etc.) and may try some 1 on 1 help-them-with-their-code type of stuff.

I (greg@solidDONTSPAMMErockstable.com) need to know as soon as reasonable who is interested in speaking. Please let me know if you are definite or tentative, and what you intend to speak on. (Title/Description/Bio) I will be making the final schedule of speakers and tracks in mid-April. we already have more than 10 speakers committed, so please respond soon. If we have more speakers than sessions, we will work (per topic) on a first come/first served basis.

Like most code camps this camp will be free to attendees. It is through generous sponsorship from companies and vendors that make these code camps possible. If you are interested in sponsoring an aspect of the code camp please let me know ASAP and we can see what can be worked out.

If you are within a few hours drive, I encourage you to attend. It should be a great day of learning and exploring together. I hope to meet some of the readers of this blog at the camp. Enough talk, go register now before all the spots fill up.

Code Coverage - 100% Coverage and Still Failing

Tim Barcz — Tue, 31 Mar 2009 17:15:00 GMT

Casey posted last year about statistics that lie. In the post Casey gives an overview of Cyclomatic Complexity and some guidelines to aim for when reviewing the cyclomatic complexity of your methods. There's a gem in the comments post by Davy Brion:

Yeah, code coverage is such a terrible indicator... the only time it really means something is when it's low... at least you can be sure that's not good. If it's high, it doesn't mean anything.

To illustrate why 100% code coverage should not be your ultimate goal, I have provided the simple illustration below.

The System Under Test (SUT)

I have a very simple method, which returns the quotient of two numbers:

   1: public int SampleMethod(int dividend, int divisor)

   2: {

   3:     return dividend / divisor;

   4: }

The Test

   1: [Test]

   2: public void Sample()

   3: {

   4:     // Act

   5:     var result = SampleMethod(8, 2);

6:

   7:     // Assert

   8:     Console.WriteLine(result);

   9:     Assert.That(result, Is.EqualTo(4));

  10: }

The Warm Fuzzy

Well would you look at that, I'm covered, 100%. Time to ship this bad boy.

The Hammer Drops

   1: [Test]

   2: public void Sample_zero_divisor()

   3: {

   4:     // Act

   5:     var result = SampleMethod(8, 0); // will throw an exception

6:

   7:     // Assert

   8:     Console.WriteLine(result);

   9:     Assert.That(result, Is.EqualTo(???));

  10: }

Produces an error:

TestCase 'Samples.CodeCoverage.Tests.Test.Sample_zero_divisor'
failed: System.DivideByZeroException : Attempted to divide by zero.

Conclusion

Yes this is all a bit contrived, but it illustrates the point, 100% code coverage does not mean 100% tested. As demonstrated here, 100% coverage simply means all code paths have been visited. As such we have to both code defensively and test defensively.

Your IoC Container Choice is Not a Feature of Your Application

Tim Barcz — Mon, 30 Mar 2009 02:51:00 GMT

I don't want to be a wet blanket, but someone's got to put a stop to the IoC love fest going on out there. An Inversion of Control (IoC) container , for those of you were aren't yet familiar, allows you to retrieve instances of objects at runtime. A relatively common solution to a common problem. In the .NET world there is no lack of choices of IoC containers:

(I won't go fully into IoC, but If you'd like more resource you can read Martin Fowler's article on the subject or post specific questions in the comments or contact me through. Read on, there is value here in this post for you.)

Let me state clearly now, IoC containers are a means to an end and NOT a feature of your application. The goal is to have loosely coupled applications, IoC containers help get you there, but you can absolutely have a loosely coupled application without an IoC container (see the Gang of Four creational patterns).

Occasionally I'll hear some comment about IoC and how great a certain container is or how an application would be so much better if another, sexier, container was used. Here are some recent tweets that illustrate:

Man i love #StructureMap, always finding new things i can do, and have fun doing them
really need to look at structuremap, but we''ve invested a lot into castle with our own facilities/resolvers/etc
Ninject is da bomb!
Switched from Windsor MicroKernel to Ninject in 10KLOC project in < 1 hour by creating a little proxy. Now to complete the conversion.
It is a talk on Castle Windsor so i guess Ninject will not do.
Can't imagine why somebody would use Ninject beside the fact that it's PURE AND UTTER AWESOME. Yeah! Ninject FTW.

Some of the statements above are probably innocuous, but some rub me slightly the wrong way. Specifically the two comments above about switching from one container to another. There are probably times when the choice of one container over another makes sense, but I would bet that these scenarios are the exception and not the rule.

Choosing one container over another won't make your application a success, the architecture, or lack there of, will have far more of a say on your application than will your container choice. As yoda might say, "The container you choose does not a good app make".

ALT.NET Bingo!

Tim Barcz — Mon, 23 Mar 2009 18:02:20 GMT

Inspired by Bullshit Bingo I've created ALT.NET Bingo for you next ALT.NET conference, Twitter conversation, or blog reading session. It's simple:

Get your card! http://is.gd/oA0A
Every time you hear a word, you mark it off. If you get bingo you stand up and shout, "WATERFALL!!"

Happy playing!

Choosing A Mocking Framework

Tim Barcz — Fri, 20 Mar 2009 04:02:59 GMT

If you're serious about testing before long you'll bump into the need to do some mocking. You can of course chose to write your own mocks but that is hardly time effective or trivial. More than likely you'll want to use a framework, but how do you choose between the most popular options?

There's been some discussion on Twitter between myself and Daniel Cazzulino (@kzu), the creator of Moq (pronounced "Mock-you" or just "Mock"), a newer and popular .NET mocking, about mocking frameworks and what goes into choosing a mocking framework. Daniel and I share a passion in mocking and by extension testing. As the creator of Moq, I hold him in very high regard.

The discussion centered around some work that Andrew Kazyrevich has been doing recently. Andrew is passionate about mocking. As such he's created an open source project which compares the "big dawgs" of .NET mocking frameworks. In his introductory post he explains the intent, which is message I support and want to help spread:

I've started a small open source project. It provides a unified set of tests written against Moq, NMock2, Rhino Mocks and Typemock Isolator, so that you can easily compare the frameworks and make an informed decision when picking one up.

In Andrew's most recent post he compares the execution time of the various frameworks. My response on the RhinoMocks mailing list was terse but sincere:

Curious about speed in your tests, is the a first level concern when choosing a testing framework?

Daniel answered the question in a tweet:

IMO, API design, usability and expressiveness is a much more valuable comparison. #moq is not optimized for runtime perf.

To which I responded:

I would also throw in documentation, discoverability, and community into your equation.

So, fine blog reader, I have a question for you. If you are using a mocking framework, what are your first-level concerns when you chose your framework? For those who have yet to utilize a framework, what will you base your decision on when you do choose?

Execution Speed
API Design
Usability
Expressiveness
Documentation
Discoverability (possibly coincides with API Design)
Community
Other?

Open Source Maturity Model Explored

Tim Barcz — Tue, 17 Mar 2009 04:49:31 GMT

About a month ago Ayende posted his thoughts on the Maturity Model found in Open Source Projects. Ayende's method for determining maturity is simple:

From my point of view, there is a very easy model for the maturity of an Open Source project. Look at the answers in the project's mailing list. The questions do no matter.

The model is simple, the higher the percentage of answers given by non project members, the more mature the project is.

I thought of this today when I came across the group info page for the RhinoMocks and saw the statistics for this month. I was struck by how low on the list Ayende is:

You can see here that Ayende is tied for #5 on the list. (Yes that's me on the list, but that's beside the point.) In two polls (poll #1, poll #2) done over the last two years Roy Osherove has found RhinoMocks to be the #1 mocking framework of those polled. I believe it is safe to say at this point that RhinoMocks is mature. Measured with Ayende's method above and the data for this month's RhinoMocks group, I'd say that RhinoMocks is quite mature. Ayende, the project creator/owner, sits at #5, which is pretty good.

Being familiar with open source I wanted to explore the maturity idea a bit further in depth on some other projects. I posted on twitter a question about what open source projects people are using. I wanted to take a few projects that are out there and explore a little bit to see if Ayende's assertion was in fact correct.

Other Projects

(Note: I am only exploring projects which have groups on Google. These projects are in no particular order.)

jQuery

Members: 15487

(Note the absence of John Resig)

Castle Project

Members: 795

(Note the absence of Hamilton Verissimo)

NUnit

Members: 204

(While I would rank NUnit as "mature" Charlie Poole is the top answerer, which does not match Ayende's method)

MbUnit

Members: 353

(The findings in NUnit are not isolated, Jeff Brown, the MbUnit lead, is the top answerer)

NHibernate

Members: 1434

(This is where I started to douby my original hypothesis. I did not expect to see project owners so high up on the list for such a seemingly mature project. However NHibernate has a learning curve to it that may hinder would-be helpers from ever getting to the point where they can confidently answer questions regularly on the framework.)

FluentNHibernate

Members: 301

(Again project owner is top answer, by a long margin here).

StructureMap

Members: 209

(This one again surprised me a bit, especially given the work that I know Jeremy has done with documentation)

MvcContrib

Members: 302

TestDriven.NET

Member: 184

(Owner and creator, Jamie Cansdale, clearly the favorite)

Spark (Mvc View Engine)

Members: 83

(Owner and creator, Louis DeJardin, sits atop the #1 position)

Conclusion

When I started to dig, I wasn't sure what I find. In many cases here the project owner is sitting right at or near the top of the top answerer list. Still, I think Ayende's original assertion is somewhat correct, however more has to be considered. For example, a very well documented framework may lead to questions being asked that are rather difficult and therefore a larger number of questions answered by project founder may not really prove anything. In other cases there may be a framework which is widely used but users don't feel compelled or comfortable answering questions for that group, for any number of reasons. Ultimately any notion of what presumed before exploration was blasted to bits.

These projects above are not fringe projects, they're relatively mainstream for a certain sector of the .NET crowd. If you haven't checked out any of these projects (admittedly I did not attempt to introduce them at all) I would encourage you do so. One thing is for certain judging from the numbers above, these projects are viable, strong, and have a good following.

What do you think of the figures above? Is Ayende right? What strikes you about the projects and their discussion groups?

Debugging .NET Applications - Podcast Alert

Tim Barcz — Fri, 13 Mar 2009 19:38:00 GMT

I have a penchant for taking "unsolvable" computer problems and getting to the bottom of them. Often times this means I'm exploring the contents of a memory dump, that is, all of the data held in RAM of the process you're inspecting. When I got started in this area about 2+ years ago I found Tess Ferrandez's blog blog was a great resource. In fact I've blogged about Tess and WinDBG before. Her blog is one of my favorites when it comes to debugging and troubleshooting .NET applications (web or otherwise).

Debugging and troubleshooting is a skill I think too many developers lack. By debugging and troubleshooting I don't mean stepping your way through code. I mean, "Holy Crap our production app is failing and we don't know why," kind of debugging. I think debugging is so valuable that I used to ask specific questions about it during interviews. Too many times I could ask questions and see the developer try to answer, but often it was easy to see that if this was a real world scenario and not an interview question, they would have long ago thrown up their arms in defeat. Computers are predictable, they don't "decide" anything, they're told what to do. If you understand that you're a step ahead of the average developer when it comes to debugging and troubleshooting.

Earlier this week DotNetRocks interviewed Tess Ferrandez, an escalation engineer with Microsoft. She's Tier 2 support. In other words, when you have a problem and call Microsoft you get Tier 1 support. Then "when thinks get too sticky" she comes to the rescue.

(I'd like to take a moment and have you consider the types of problems she gets. The typical engineer will encounter many issues over their career. I'm sure you've had them. I've had them. However, I typically will peruse articles, blog posts, and forum posts to find the answers I look for. When faced with a problem, how many times have you ever resorted to calling Microsoft? Me? Zero. So imagine for a moment that you've not found an answer on any of the typical resources and have called Microsoft. You're working with their Tier 1 support but they can't seem to help you. It as it this point that you get a person like Tess. She's smart. She know .NET like I know Mt. Dew).

If you're sitting at a desk download the podcast and listen now:

Real Life - Code Reuse

Tim Barcz — Mon, 09 Mar 2009 18:37:16 GMT

A few months ago I blogged about how we're using the single responsibility principle in our application at work. I'm going to make an effort here to write more "Real Life" content. Often when a developer read principles or ideas in books, there is disconnect between what he/she is reading and how an implementation would look in the real world. The goal of these "Real Life" scenarios is to show areas where I feel I've reaped some benefit from following a specific pattern or practice. This does not mean that my implementation is the only way or always "book correct". The goal is to act as a bridge (quite possibly a old rickety bridge) between the book knowledge and the real world.

Moving along...

One of the purported benefits of OOP has always been the abundant reuse of code. However, in my experience many applications fail to realize any amount of reuse beyond copying and pasting between applications. To really take advantage of code reuse you have to have small, concise pieces which you can rearrange in order to make a new behavior. As a side note, and I want this be clear, many of the principles of good software development, ie. SOLID, go hand-in-hand. You can't do one without the other and the benefits of one cannot be fully realized without the implementation of the others. You'll notice that a few sentences ago I said "small, concise pieces". A light bulb may have gone off in your head thinking "Single Responsibility Principle", and if it did, bonus points for you.

The key to code reuse is to build your components in a very focused way. By doing so, you can add functionality by combining different pieces of you application.

Consider the following code used to authenticate a user into a site:

   1: protected void btnSubmit_Click(object sender, EventArgs e)

   2: {

   3:     string Username = Server.HtmlEncode(txtUsername.Text);

   4:     string Password = Server.HtmlEncode(txtPassword.Text);

   5:     int nUserID;

6:

   7:     if (Username != "" && Password != "")

   8:     {

   9:         using (SqlConnection cnn = new SqlConnection(connectionString))

  10:         {

  11:             using (SqlCommand cmd = cnn.CreateCommand())

  12:             {

  13:                 cmd.CommandText = "usp_Login";

  14:                 cmd.Parameters.AddWithValue("@Username", Username);

  15:                 cmd.Parameters.AddWithValue("@password", password);

16:

  17:                 using(SqlDataReader reader = cmd.ExecuteReader())

  18:                 {

  19:                     if (reader.Read())

  20:                     {

  21:                         nUserId = Convert.ToInt32(reader[0]);

  22:                     }

  23:                 }

  24:             }

  25:         }

26:

  27:         if (nUserID > 0)

  28:         {

  29:             // if the user has checked the box

  30:             // store his information so he doesn't have to log in again

  31:             if (cbRememberMe.Checked)

  32:                 FormsAuthentication.SetAuthCookie(nUserID.ToString(), true);

  33:             else

  34:                 FormsAuthentication.SetAuthCookie(nUserID.ToString(), false);

35:

  36:             BusinessLogicLayer.User objUser = new User(nUserID);

37:

  38:             // store session variables for later reference;

  39:             Session["UserID"] = nUserID;

  40:             Session["Username"] = objUser.Username;

  41:             Session["Password"] = objUser.Password;

  42:             Session["AccessLevel"] = objUser.AccessLevel;

  43:             Session["AccessLevelName"] = Enum.GetName(typeof(Utilities.AccessLevel),objUser.AccessLevel);

44:

  45:             Response.Redirect("~/admin/admin.aspx");

  46:         }

  47:         else

  48:         {

  49:             View = Views.Failed;

  50:         }

  51:     }

  52: }

While the code above is functional, it does way too much. In this button click event there are:

Call to database explicitly
logic to set an authorization cookie
Some session variables being set

Imagine for a moment that you now want to implement a new piece of functionality, user impersonation. In order to accomplish this with the path of least resistance, which developers commonly take, would be to copy/paste all of the login logic to another UI event somewhere else in the site. The issue copy/paste development is that any future change to the login logic has to be copied again or else the impersonation feature isn't really impersonating a users experience. The insidious nature of copy/paste development is that while often it works, it creates a brittle application.

In a recent application we were wanting to add user impersonation. Below is an example of an implementation of user impersonation. Adding the feature to the application was gleefully simple. The ease in adding impersonation was due entirely to the proper granularity in our application components. Seriously, this is all the code it took:

   1: public ActionResult ImpersonateUser(int id)

   2: {

   3:     var authService = Container.Resolve<AuthService>();

   4:     var userRepository = Container.Resolve<UserRepository>();

5:

   6:     var userToImpersonate = userRepository.GetById(id);

   7:     if (userToImpersonate != null)

   8:     {

   9:         authService.SignIn(userToImpersonate);

  10:     }

11:

  12:     return RedirectToAction("Index", "Home");

  13: }

I did not know we were going to want user impersonation for this application when we started. However because we developed the site with certain principles in mind, we were able to reuse pieces of code in ways not originally intended for added behavior. As you can see from the code above, there are no "clever hacks" or tricks to get impersonation to work. The beauty of the code above is that if we change the implementation of "SignIn(user)" all appropriate areas will follow the same rules since all areas use the same code.

As I'm closing I want to challenge those of you who have read this far to stop yourself the next time you find yourself copying code from one location to another. Is there an abstraction or component you're overlooking? Think about the long term and ask if you're really making the wisest decision for the long term health of your application. It will be through this introspection and honesty that you'll find areas where you can write smaller component which will allow you to realize the oft spoken benefit in OOP of code reuse.

Improving Software Process - A Letter to Upper Management

Tim Barcz — Thu, 05 Mar 2009 18:49:12 GMT

The following is an email I wrote to the upper management in our company when asked about things we can do to improve the process and what are the next steps of things we need to fix in our application. It remains mostly unedited and contains my thoughts on what will make our company better when it comes to the software we're writing. It wasn't written as a blog post. It wasn't until after I finished with it that I realized that it was decent content for a blog post. You'll find a very "XP-ish" theme throughout, and that isn't necessarily an accident. Hope you enjoy! Please leave feedback if something moves you.

Overview

The following contains my thoughts on software development at Super Awesome Company. While I can address the specifics of the project that I see need to be fixed and modified (the “what”), I am instead going to focus on how these items get fixed. I am choosing to do this because over time the new website will have bugs that need to be fixed, enhancements that need to be made, or new features requested. For the long term health of the project it does not matter so much “what” is implemented but rather “how”. For that reason I am avoiding specific project level tasks in this document and speaking at a higher level.

Software has been being developed for over 30 years. While the internet is relatively young, software development by comparison is not. Super Awesome Company will benefit from a commitment to good software development practices. Further, it takes a great deal of commitment and discipline to reap the benefits these practices can bring. Many of my suggestions are based on these principles, which are principles I have committed to learning and adopting over the last several years.

The overarching suggestion I would make is make quality the focus. In order to produce quality, we must slow down. In order to go fast you must go slowly. Sacrificing quality should never be an option. Consider a car manufacturer who needs to get 100 cars built in a single day. If they can only build 80 cars a day, is it better for them in the long run to get 100 cars out the door but have problems or 80 problem free cars? Building deficient cars carries more expense that just fixing the broken cars, such diminished brand reputation. If the goal is 100 cars per day, measures should be sought to increase production while keeping quality high.

We don't need to look too far to see where in a rush we've done something that we've had to revisit several more times because we were "going fast". We've been rushed for nearly a year and I can't say that we are any further along than we would have been had we approached the project more methodically. In some areas we may be further behind where we would have been since we "made sacrifices" to get things done, which have ultimately only put us further behind. Again, to go fast we must go "slow" (methodical). Put another way, quality breeds speed.

Any process, principle, practice we choose should have quality at its heart. Regardless of what process, principles, practices we adopt they will only be successful if we are disciplined enough to follow them.

Planning

Requirements

Requirements need to be clear and understood by all parties. Before developers set out to coding we need to have a clear understanding of what the problem is. The developer is not able to provide a solution until the problem is fully known and understood. Often the perceived solution to a problem is not the best solution. Failure to fully understand the problem/scenario results in rework.

Releases

We need to have planned releases. The timeframe can be discussed and agreed upon by the team. In order to have successful releases we need to plan each release. Each release should be broken down into smaller time frames, iterations. During the iteration the work should be stable for each developer. In other words, they know what they’re going to work on and accomplish (see requirements above) for any given time period.

Metrics

We need to be measuring metrics for the purposes of planning. If we get 10 units of work done each week on average and we have 20 units of work to do, we can easily figure out what is left to do. Without any metrics gathering we can’t do any planning and we’re really flying blind. This will also help with project post mortems. For example, the “web order manager” project was originally estimated to take a week worth of development effort. Three months later, it is still not finished. This is a combination of putting someone with limited knowledge of the business estimating the project, an overly aggressive developer estimate, and having no metric to pull from on how long something should take.

Flexibility

We need to be disciplined in the process of building software, but also realize when the process needs tweaking that we should respond and not be afraid to tweak the process to meet the needs of our team

Design

Simplicity

We should strive for simplicity in our designs. “Clever hacks” are often not healthy for the life time of the project. Simple designs are easier to understand and improve upon. Simple designs also allow other developers ease in working on code. This is much harder to do in practice but it always pays off in the long run.

Design aspects dovetail with testing (later in this document). Typically complex designs prove to be hard to test. When we write code based on simpler designs we’ll find that our code is easier to test. We want both, simple designs and easy-to-test code.

Coding

Standards

We should implement a standard for code development. Right now you can find three different styles/methods of coding in the code base. This makes it hard for developers to work on code they did not author. Projects I work on outside of work require all new code meet the standard, otherwise it is rejected until it meets this standard. As a consumer of these projects I’m always grateful when I can move through any of the project pieces and the code always looks the same.

Testing

Given the environment and complexity of the code, we need to require the developers to be able to test their code in an automated fashion. Visual verification is orders of magnitude slower than automated testing. Once an automated test is written, it runs every time. By having a large collection of tests we can makes changes to certain parts of the application and use existing tests as a safety net to verify nothing else has broken. We currently have over 1,150 tests (about 30% of code has tests) that run whenever someone commits code into source control. Those tests run in about 20 seconds. Imagine how long it would take a user to test each of those cases visually every time a piece of code changes.

Two weeks ago I sat in a meeting adding functionality to shipping and enhancing rules around shipping hazardous items to Canada while people were finding issues because of a solid base of tests. Before the meeting was over both issues discovered were fixed and tests were added for these specific issues so we would be guarded against this happening again.

Unit Tests

All code must have unit tests that can be run in an automated fashion. If the code cannot be unit tested (tested in isolation from other components) it should be restructured in such a way that it can be tested. Very few pieces of code are truly not testable. As such we should have very few areas in our code base which are not tested.

Proving Bug Fixes Through Tests

When bug is found a test should be written before any attempt to fix the bug. This test proves to the developer the bug exists but secondly gives the developer a marker to know when the bug is fixed. As a benefit, this new test acts as a guard against this particular bug ever happening again. This test, when first written, should fail because the developer has not fixed the bug yet. The developer should then work to make the test pass, and by extension fixing the bug. The cost of adding the test is very small when compared against having the test guard against this condition ever happening again.

Code Coverage

We should implement a standard for new code coverage, code that is tested by an automated test. I would recommend somewhere in the 80%-90% range for code coverage. In order to write tests the developers will be forced to think about their code a bit more thoroughly.

Pair Programming

We should adopt pair programming as a method to both increase shared knowledge but also as a means to quality. Pair programming is two developers sitting at one computer for a period of time while code is written. From the outside it may seem impractical to devote two developers to a single computer, thinking it is inefficient. Industry studies however show that code written in a pair has a four-fold benefit:

15% less code– Studies showed that less code is written in order to implement the same functionality. Less code means less to maintain and understand. Less code is also typically simpler.
Less bugs – Developers, when working in pairs, can catch each other’s bugs before they ever make it to production. We therefore save time that it would take to fix the bugs that would otherwise go undiscovered.
Shared domain knowledge – When “pairing”, each developer is training the other and sharing knowledge and rules around the business. This avoids silos and situations where only one person knows the code.
Increased Skill – When “pairing”, design, coding, and testing techniques are transferred between developers. This is often why many development shops pair their senior developers with junior developers; to raise the skill level of the junior developer.

Collective Code Ownership

No one person should be a silo/bottleneck for any area of the code. Any person should be free to make suggestions, fix bugs, or refactor any part of the code. Pair programming (see above) is one tool which seeks to address this.

Conclusion

While the above recommendations may seem like a lot, the above items all really go hand-in-hand. Consider:

Collective Code Ownership is had through Pair Programming
Standards are enforced by developers when Pair Programming
Writing Unit Tests typically leads to Simple Designs
A commitment to Code Coverage leads to more Unit Tests
Gathering Metrics leads to better estimates and Release planning

Adopting the above will move us in a positive direction and ensure that all projects coming from our department will be of ever heightening quality. Once the quality bar is set, then we will begin to see the pace pick up; Remember, quality is a prerequisite to speed.

Default Values and Smarter Property Assessors

Tim Barcz — Mon, 02 Mar 2009 03:18:14 GMT

In your applications there may be times when you want to give the user the ability to override a setting or configuration value. Often times you want to provide sensible defaults so that every single configuration option does not have to be specified, only those you which to override. I want to show a very simple way to make your applications a bit smarter when creating classes with overridable default values.

Example 1:

   1: public class DemoObejct

   2: {

   3:     private string DEFAULT_MESSAGE = "Thank you for your order";

4:

   5:     private string message = DEFAULT_MESSAGE;

6:

   7:     public string Message

   8:     {

   9:         get { return message; }

  10:         set { message = value; }

  11:     }

  12: }

Example 2:

   1: public class DemoObejct

   2: {

   3:     private string DEFAULT_MESSAGE = "Thank you for your order";

4:

   5:     private string message;

6:

   7:     public string Message

   8:     {

   9:         get { return message ?? DEFAULT_MESSAGE; }

  10:         set { message = value; }

  11:     }

  12: }

So what's the difference? The difference IS subtle but I consider the following code snippet:

   1: var obj = new DemoObject();

2:

   3: Console.WriteLine(obj.Message);

4:

   5: obj.Message = null;

6:

   7: Console.WriteLine(obj.Message);

Setting the Message property to null in line 5 results in different behavior between the two examples. I find the second example to be preferable, setting the property to null invokes the default message again. It's a very simple thing you can do to provide a more robust object

Here are two more examples where I use this strategy often:

Integers and Default Values:

   1: public class DemoObject

   2: {

   3:     private int? attemptThreshold;

   4:     private const int DEFAULT_ATTEMPTTHRESHOLD = 3;

5:

   6:     public int AttemptThreshold

   7:     {

   8:         get { return attemptThreshold.HasValue ? attemptThreshold.Value : DEFAULT_ATTEMPTTHRESHOLD; }

   9:         set { attemptThreshold = value; }

  10:     }

  11: }

Logging Component:

   1: public class DemoObject

   2: {

   3:     private ILogger logger;

4:

   5:     public ILogger Logger

   6:     {

   7:         get { return logger ?? NullLogger.Instance; }

   8:         set { logger = value; }

   9:     }

  10: }

The above logging example is where this type of strategy really shines. It prevents NullReferenceExceptions in your code if by chance your logger gets a null value at some point, again providing for a more robust object and application.

Look What I Found

Tim Barcz — Tue, 10 Feb 2009 18:00:52 GMT

Digging through the Castle source code look what I found in the "HowToBuild" file (note the last line):

Possible problem with 3.5
=========================
if you get the following error:
"The SDK for the 'net-3.5' framework is not available or not configured."
then you probably need to fix the sdkInstallRoot in your nant.exe.config file to point to the correct location in the registry
See the following article for more info:
http://www.timbarcz.com/blog/NantSetupForVisualStudio2008AndNet35.aspx

Looking through the file's history I can see that Ken Egozi is a pretty smart man. *wink* *wink*

Testing - Mandated By God!

Tim Barcz — Tue, 10 Feb 2009 14:21:31 GMT

1 Thessalonians 5:21

"Test everything. Hold on to the good." (NIV)
"Prove all things; hold fast that which is good." (King James Version)