Tim Barcz : Rant

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.

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.

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.

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".

Exercise Caution When Using Floating Point Numbers

Tim Barcz — Wed, 05 Nov 2008 20:13:11 GMT

I understand floating point numbers can be somewhat imprecise but I'm a bit bothered today when I see the following evaluates to false:

   1: float f = .16f;

   2: double d = .16d;

3:

   4: Assert.That(f, Is.EqualTo(d))

Annoyingly I wanted to see what the two values are:

   1: Console.WriteLine((double)f)

   2: Console.WriteLine(d);

produces the following respectively:

.159999996423721

.16

What bothers me about this, and I'm hoping someone can eloquently explain this, the MSDN docs say this should be implicitly converted. From the MSDN doc article on implicit numeric conversions:

From float to double.

Float is 32-bit and double is 64-bit, so why can't the float fit nicely inside the address space for the double?

Hell, if you're not going to respect the integrity of the number what's the point of the implicit conversion?

Testing Pre-Requisite - Care About Your Code

Tim Barcz — Fri, 03 Oct 2008 02:20:10 GMT

There's a lot of posts and chatter about testing, TDD, and a number of other topics on this blog, the larger devlicio.us site, and the .NET community in general. Before all that, it should go without saying, but it must be said; there is a pre-requisite to testing, care about your code.

You have probably come across some code in your career that is less than ideal. Maybe you've even submitted something to the Daily WTF. I'm currently combing some old code trying pull out some main concepts. As I'm going through the code I'm seeing some things that really are quite alarming. I'm not talking about differences in what I would do in terms in architecture, implementation, or even language choice. I'm talking about blatant code rot, code that no one has cared for.

Some stats for the current file I'm in:

Lines in file: 1820. This is the mildest offense, while I don't endorse a class/file that large I can live with it.
Classes defined in the file: 19. I find this a "little" excessive, Even if you don't subscribe to the "one class per file" rule, 19 is a bit much don't you think?
Example Method: 697 lines. That number isn't entirely accurate as 395 of the lines are commented out. I understand the scenario that probably led to this, in fact I'll admit to doing it. You comment out some code as a fail-safe in case the new implementation doesn't work. The problem here is that the code does work (and I use that term loosely). The developer never cleaned up after themselves and their trial code. This makes absolutely no sense when you have source control in place.

Here's a method I came across today:

   1: Public Overrides Function ToString() As String

   2:     If IsNothing(_fields) Then

   3:         Return ""

   4:     End If

5:

   6:     Dim r2 As String

   7:     'make room for 1 char and 1 delimeter for each field

   8:     Dim retVal As StringBuilder = New StringBuilder("", _fields.Length * 2)

   9:     For Each f As Field In _fields

  10:         r2 = r2 & f.Prefix &_

  11:             f.Value &_

  12:             f.Postfix &_

  13:             ConfigurationSettings.AppSettings("ControllerFieldDelimeter")

  14:         retVal.Append(f.Prefix)

  15:             .Append(f.Value)

  16:             .Append(f.Postfix)

  17:             .Append(ConfigurationSettings.AppSettings("ControllerFieldDelimeter"))

  18:     Next

19:

  20:     r2 = r2 & "<EOT>"

  21:     retVal.Append("<EOT>")

22:

  23:     'Return retVal

  24:     Return retVal.ToString

  25: End Function

The first thing I noticed was the string concatenation in lines 10-13. The problem is the "_fields" (the collection over which this code is iterating) can be large. So concatenation isn't the best choice. While clearly not optimal, let's let that slide for a moment. The very next line, lines 14-17, there is some appending of seemingly the same data. In the end r2, the concatenated value which was so expensive to generate, is never returned or used elsewhere. All of those extra, wasteful concatenation calls are spent on worthless code. The developer(s) who worked with this over time simply never cleaned up after themselves or cared for the code.

I'm amazed that code like what I'm looking at is found in code bases. I probably shouldn't be surprised but I am. Today I was posting my reactions on Twitter and a friend Rhys Campbell commented:

"395 of them are commented out".. delete them! do it! You know you want/need to

I think Rhys is right, I will fix the code as I see it. The codebase is being phased out but that doesn't mean it shouldn't be cared for. If I am caring for code that is going to be obsolete and replaced soon, how much more important do you suppose is it to care for your current code? If any of the above sounded like your code, get with it, clean up and care for your code.

Google Chrome - How Cool? Too Cool.

Tim Barcz — Tue, 02 Sep 2008 19:59:11 GMT

How cool is Google Chrome (new browser from Google)? Way cool...like "too cool to run on your machine cool"

Thumbs up though for their error screen, just wish I didn't have to see it

The Tortoise and the Hare

Tim Barcz — Mon, 11 Aug 2008 17:13:00 GMT

We're all familiar with the Aesop's fable of the tortoise and the hare. In the story, the hare, who is in every way is faster than the tortoise, loses a race to the tortoise. The main principle of the story is that slow and steady wins the race.

In my development I am shooting to be a tortoise, really I am. Read on and let me explain.

A few weeks ago I got some evil glares when I suggested at our .NET user group meeting that in enterprise systems that you don't have time not to test. It's a common hurdle for those new to testing to say, "I don't have time to write tests." Let's face it, we're all busy, that excuse is tired. As an agile and lean practitioner I seek out ways to improve velocity and reduce waste, not take my already busy schedule and cram in another tool for the sake of another tool. While writing tests does slow me down, it brings on tortoise like speed, which I would argue is a good thing. Writing unit tests is one tool that provide me the ability to keep a more consistent velocity over the course of development. Without tests I can surely write things faster, the problem arises as the codebase grows and each new feature or fix takes increasingly more time. Eventually, even simple requests become arduous to implement. Slowly you see your velocity come to a crawl.

It's an insidious cycle that I've seen before and am currently in the throes of; an application is built from scratch implementing everything the business requires. The application is enhanced and bolted on to, until you realize that you could move much faster if you could start from scratch. You make pleas to your boss and explain how much productivity would improve if you could shed the hideous code base. One day he gives in, you rejoice and you make the leap, start from scratch, breathing a sigh of relief at how easy implementing the features are all the while reminiscing about the old framework and how poorly it was written. And now that the application is rewritten from scratch the cycle, unless you were aware of it all the while, starts again.

You see, no one sets out to write crap code. People do the best they can with the knowledge they have. Code, following the second law of thermodynamics, tends towards chaos over time. With unit tests in place I can refactor with more confidence and implement new features without the fear of breaking existing code. If you have the ability to refactor, new code is no longer "bolted on" but rather "grafted in" becoming part of the system. With a solid framework with tests in place you can much better stop the cycle of rewrites. Quickly writing applications that degrade is the way of the hare. Developing purposefully using unit tests causes me to be slow in the short run, but over the life of the application comes out far ahead. In that way, I strive to be the tortoise.