Tim Barcz

Poor Design Is Not a Bug

Tim Barcz — Fri, 26 Nov 2010 03:37:18 GMT

Ayende recently posted a an article titled “Where is the bug”. While reading the comments, I was disappointed by some of the answers to Ayende’s request to find the bug. Here are two of the comments that stood out to me:

“You could argue the biggest bug is the use of a switch statement as it violates OCP.“
“The use of a switch statement is a bug in itself.“

What bothers me so greatly is people’s inability to separate design discussion with bugs. A bug is defined on Wikipedia as:

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways

The two comments above don’t attempt to solve the bug and instead take an “ivory tower approach” to the problem (more befuddling is that removing the switch in favor of something else would leave the bug in place). This bugs me because we (as an industry) continue to care very little about the output and meeting of customer/business needs and more about code structure and semantics than actually working code.

Let me state for the record, it is perfectly acceptable to talk about code structure and design but please let’s not confuse a bug – an actual error or flaw in code – with poor design.

(I think it’d be humorous for Ayende to post some perfectly fine code and ask “Where’s the bug” and watch people trip over themselves trying to find something wrong)

Task Parallel Library: Real-World Results

Tim Barcz — Fri, 19 Nov 2010 06:47:00 GMT

I’m working on a project that requires chewing through a lot of data. While looking for ways to make the code run faster – I hate waiting – I decided to throw the new Task Parallel Library at the problem to see what sort of improvements I could gain. Below is the concept and the results I saw (remember: your mileage may vary).

The Code

Here is the gist of the original code:

var lines = File.ReadAllLines(path).ToList();
lines.ForEach(x => parsedResults.Add(lineParser.ParseLine(x)));

Quite simple for sure, but to run through 10,000 lines this was taking about 15,000 Milliseconds, or 15 seconds. To me that felt slow, especially when you start talking about millions of rows (A million rows at 1.5 ms would still take just under 17 minutes).

Task Parallel Library Version (TPL)

There’s a very simple .ForEach method that’s quite handy and simple to use, however I have local variables and a master collection I need to combine into for later processing and therefore need to use a version of ForEach that supports thread-local variables. Here is that code:

Parallel.ForEach(lines,
                                                       () => new List<LineResult>(),
                                                       (current, loop, threadLocalList) =>
                                                       {
                                                           threadLocalList.Add(lineParser.ParseLine(current));
                                                           return threadLocalList;
                                                       },
                                                       parsedResults.AddRange
                );

Results

Using the 10,000 line test version and taking an average of several runs here are the results:

Before: 15,267

After: 7,546

Speed improvement: 100%

Conclusion

Overall this isn’t a very exciting example, however it does show the potential impacts that the Task Parallel Library (TPL) can have on your runtime performance. I was pleased with the library in that I had a very simple cast (looping) and there was very little to do. I simply added the “using” directive and that’s about it, no configuration or dependencies. If you’ve played with the Task Parallel Library what real-world uses have you found? What benefits have you seen from the code?

What to Make of Intel Buying McAfee

Tim Barcz — Thu, 19 Aug 2010 20:39:00 GMT

James Senior posted on his Twitter account:

“oh dear lord no. why intel, why? http://ow.ly/2s2dm reminds me of when Intel got into the hosting business. http://ow.ly/2s2fT”

James is referencing an article posted by the BBC on the recent news of Intel’s takeover of McAfee for 7.68 Billion. While I agree with James on Intel’s foray into hosting – of course hindsight is 20/20 – I disagree with his position on this particular deal and here’s why.

Despite the rapid growth over the last 15 years of PC’s, viruses are still problematic. Despite continual efforts at training the masses, viruses still are far too prevalent. Additionally the methods for exploitation continue to spread and evolve faster than the education can keep up with. For example, by now, the vast majority – save your grandmother – knows not to open executables sent via email (largely this practice is blocked at the email level anyway). A smaller, but still growing population have learned to not open attachments from people you don’t know. And yet viruses at times runs rampant.

The virus landscape has largely changed with a more sophisticated modern day virus writer. He/she is no longer malicious in their intent to infect your computer but instead often plant malware to consume and distribute private information on your computer. Certainly dangerous viruses still exist, but there’s less money in that.

Given that education can’t keep up (or thus far hasn’t proven to be able to keep up) with the changing exploits and security software saturation is still less than 100%, I see the move by Intel as a positive one. Imagine virus protection at the chip level. The virus uses the chip and it’s processing to do it’s damage. If the chip can refuse access to the virus, the virus is rendered ineffective.

In an environment with increasing questions/concerns about security threats, a chip maker who can offer it’s customers virus protection has a significant advantage over it’s competitors. Additionally, every computer has a CPU and saturation into the market would be swift as computers with this technology would be introduced into the market as people replaced their old PC’s.

In an interesting twist to this story, I could see Microsoft having interest in this particular marriage. Largely portrayed by many as insecure, a chip with protection renders the discussion about OS security potentially moot. Whether Microsoft would admit to it or not, it has skin in this game.

Overall, I think Intel’s choice is a strategic one and might prove be a great one. After over two decades of security software, software hasn’t been the answer. That doesn’t mean software couldn’t be the answer, however history has thus far shown software as a weak solution. It’s time for a game-changer. This could be the road to that much needed change.

Time will tell…

St. Louis Day of .NET

Tim Barcz — Mon, 02 Aug 2010 20:30:00 GMT

Now that we’ve entered August, we’re just three short weeks away from St. Louis Day of .NET (taking place August 20-21). Last year I gave two talks (Rhino Mocks and beginner’s guide to unit testing). This year I’ve been lucky enough to selected to be speaking again on two topics:

Building and Creating a High Performance Team - This session will give you strategies to turbo charge your team. It will deal with everything from how to build trust within a team to talking to management to process/methodology. This talk will use real-world examples from my recent experiences with my team at J&P Cycles and will include perspectives from both the development side as well as the managerial side.
Website Usability 101 - Do you want to create a more intuitive website? Want to make your customers happier? Website Usability is a very hot topic right now. I'll discuss several tools you can use to test your website and resources you can turn to if you're getting started in usability. First we'll define what it is and why you want it and then we'll walk through a series of tools and resources you can use. Attendees will see real-world examples throughout and will leave understanding how easy and quick testing can be.

This conference is one of the best in the Midwest bringing in great speakers and content with a great venue (Ameristar). This year there are already over 500 people registered for the event with numbers likely to go even higher as the date nears!! It’s a great chance to learn some new technical content to improve your .NET mastery as well as network with several other .NET professionals in the area.

(My dirty little conference secret: I like session content, St. Louis has some great content, but for me, it’s the discussion that take place outside of and between the sessions. Breakfast with developers and geek out sessions over a pint of beer. St. Louis Day of .NET provided some of the best conversations of the year last year.)

If you’re planning on going let me know would love to connect in person…also I have two discount codes that I can offer that will get $75 off registration.

Open Source Whining

Tim Barcz — Wed, 28 Jul 2010 14:04:28 GMT

Was working on a blog post talking about a problem I’ve found in Git (1.7.0.2) and I thought I would check to see if it’s been fixed in the most recent version. After downloading and installing I reviewed the release notes where I’m quite shocked to read the following:

“…All hopes to the contrary, Git for Windows is backed by only a handful of developers, in spite of being downloaded almost one hundred thousand times. You can expect developers to be enthusiastic to fix others' issues in such a situation only for so long. In short: Do not expect other people to fix your issues for you.”

Basically, what I get from this is that the msysgit committers are a bunch of whiners. What they fail to see is that the people who would benefit from their VCS may not have the same skillset to work on the code. This is something we’ve realized long ago with Rhino Mocks.

Should more people help? Possibly. As someone active in open source technology I don’t know that I can be of much assistance to the Git team – I am someone who benefits greatly from their software (I am quite thankful for it) but don’t have the requisite knowledge in C/C++ to assist in any meaningful fashion.

Just a bit disappointed to see this type of whining in their release notes – certainly there are far better ways to say what they’re trying to say. Doesn’t represent msysgit or the broader open source community well.

Are You Playing Checker or Chess? - YAGNI Revisited

Tim Barcz — Mon, 15 Mar 2010 05:08:37 GMT

This past Saturday I had an early morning coffee with a friend. He’s an entrepreneurial type – a big thinker who moves at a fast pace and is always thinking ahead. One question he asked of me, “Are you playing checkers or chess?”.

The question was asked around business and career but I could not help but think of the implications to software.

In the agile software world we often use the mantra…”do the simplest thing that works”. I have found that I cringe at the usage of that statement at certain points (when honest - even at my own usage at times upon later reflection). Really, if we step back and honestly evaluate ourselves, how often do we really implement the simplest thing that works. My opinion is that it’s often used as an excuse to get get out of work - a “wild card” of sorts that’s pulled out when convenient.

With “the simplest thing that works”, developers associate the term YAGNI – You Ain’t Gonna Need It. While very often true – you really don’t need that feature (studies have demonstrated and confirmed) – I see times where people confuse YAGNI and the agile principle of “the simplest thing that works”. What’s the difference?

Chess versus checkers my friend. Checkers is a pretty simple game with few rules and even fewer game pieces. Chess however has several game pieces, each of which has their own movements and rules associated with them. The types of discussions and strategies that exist around chess do not exist around checkers. Put simply, chess is much more complex than checkers. Checkers is really treated on a move-by-move basis whereas chess is far more strategic, where moves are setup far in advance of their execution.

When talking about “the simplest thing that works” we have to be careful to not be playing checkers. Play chess instead. Make a small, single move that moves you closer to some strategic end. Like it or not, many waterfall processes are playing chess – trying to anticipate every outcome or piece of functionality and adjust/account for it. What the waterfall practitioner fails to see is the inevitable change. Many agile adopters start playing checkers, making small move after small move, assuaging fears of downstream problems with the comfort that their doing the simplest thing that works.

Therefore, have a strategy, a end in mind, and then do the simplest thing that works that moves you closer to that end. Note however that this may not always be the absolute simplest thing that works.

Where Do You Want to Be In a Year?

Tim Barcz — Thu, 31 Dec 2009 17:31:00 GMT

This time of year is a time of resolutions and there certainly have been blog posts sprouting up about 2010 and what people are going to change about themselves. I’m however going to approach it differently…

Habit #2 of the The 7 Habits of Highly Effective People is “Begin with the end in mind”. Which has a key part I like:

“…If you don't make a conscious effort to visualize who you are and what you want in life, then you empower other people and circumstances to shape you and your life by default….”

Where do you want to be in a year?

My Answer:

By the end of 2010 I want…

to have learned more about the business.
to understand lean manufacturing/processes and it’s adaptation to the software development world.
to continue to read and learn more about marketing and the intersection of technology and marketing so that I can make more effective/informed decisions in my role at work.
to continue exploring enterprise architecture both in book form but also in the often messy real-world. At work I’d like to use my knowledge of technology and architecture to continue to work to bring disparate systems together to reduce human involvement.
to explore Ruby or F#, whichever seems to have real-world impact value to what I do.
move to Git for source control at the enterprise level
to be renewed as an Microsoft MVP
to speak fewer times but with more authority/knowledge

That’s me, how about you? Where do you want to be in a year?

Unit Testing Strategy: Hiding Out In the Open

Tim Barcz — Wed, 16 Dec 2009 15:38:00 GMT

Sometimes there are pieces of code that you want to test but you just don’t quite see how you can unit test it easily. I have illustrated one such example below where I am interacting with the file system.

Take the following snippet for example:

   1: public class FileRenamer : IFileRenamer

   2: {

   3:     public void RenameFile(IList<DomainFile> files)

   4:     {

   5:         if (files == null)

   6:             return false;

7:

   8:         foreach (var file in files)

   9:         {

  10:             var newName = string.Concat(file.FullFileName, file.Client, file.Site, file.DesagilationCount, ".file");

  11:             File.Copy(file.FullFileName, newName);

  12:         }

  13:     }

  14: }

I want to “unit test” that the correct file is created, but I really can’t. The “File.Copy()” is going to hang me up a bit because in order to verify the method worked I am going to have to go visually verify that a file was copied to a certain location. I could of course automate this but in either case I’m touching the file system, which is not a quality of a good unit test.

In reality, the only thing I really care about here is that the new file is named properly. However, as it sits, the new name is really coupled to the copy process and the hard disk. Let’s change that…

   1: public class FileRenamer : IFileRenamer

   2: {

   3:     public void RenameFile(IList<DomainFile> files)

   4:     {

   5:         if (files == null)

   6:             return false;

7:

   8:         foreach (var file in files)

   9:         {

  10:             File.Copy(file.FullFileName, BuildNewFilename(file));

  11:         }

  12:     }

13:

  14:     public string BuildNewFilename(DomainFile file)

  15:     {

  16:         return string.Concat(file.FullFileName,file.Client,file.Site,file.DesagilationCount,".file");

  17:     }

  18: }

What I’ve done here is move the logic of the new name creation to a new method. By extracting that single line to its own method, we’ve made the “untestable”, testable.

So at this point you may be asking yourself why this strategy is called “Hiding Out In the Open”? I call it that (is there another more formal name? possibly an xUnit test pattern name?) because we haven’t added the method to the interface (the “hiding” part) but we have made the method public so it’s visible to consumers (the “out in the open”).

Hiding

When I added the public method to the FileRenamer class, I *did not* add it to the interface IFileRenamer. That means anywhere where this particular class is referenced as an IFileRenamer that the new method (BuildNewFilename) won’t be visible (see below). Hence the usage of the term “hiding”:

Out In the Open

The whole point of this exercise was to gain some testability aspects for this particular class. Since the method is public, in our test method when we create an instance of our FileRenamer class, we now have the ability to test (see below):

Some Caveats

Some will argue that the renaming of the file is a separate concern from the copy. The separate concern would then be a separate class that is possibly used by the FileRenamer, in which case the new class would be testable. This is a fair argument and at times it’s a good strategy. I think it’s good to know the strategy so there are more tools in the bag when a curious situation arises.

Some will argue that you’re increasing the surface area of your API when you make the method public. Again, a fair argument however, in most cases when dealing with the abstraction (the interface) this doesn’t rear it’s head. It’s a small insignificant side-effect. If you don’t like it don’t use it. Disclaimer: I strongly discourage this course of action if you’re building a public API that others will consume. In my case, 99% of software I write is used in house. If making something “public” really bothers you, then make it internal and use the “InternalsVisibleTo” assembly attribute to give your test assembly visibility.

Conclusion:

The original snippet of code above had some pieces that were hard to properly unit test. What we’ve done here employed a strategy I call “hiding out in the open” to the class under test to achieve a bit more testability. I think this is just another testing strategy to have in your back pocket. There should be few times when you need this particular strategy, but when you need it it does come in handy.

Ralph Waldo Emerson Would’ve Been a Great Developer

Tim Barcz — Mon, 14 Dec 2009 18:06:36 GMT

A very short quote I came across to start your week off and get you thinking about technology with the correct frame of reference:

“As to the methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”

- Ralph Waldo Emerson (1803-1882)

Mr. Emerson would surely have made a great developer. We need to heed his advice.

As an exercise: think of how many different “methods” you can think of and then think of how many “principles” you can come up with.

Principles:

Single Responsibility Principle
Don’t Repeat Yourself
Dependency Inversion Principle
Liskov Substitution Principle
Open Closed Principle
Interface Segregation Principle

Methods:

ASP.NET
C# 2.0
C# 3.0
LINQ
LINQ to SQL
Entity Framework
NHibernate
SOA
StructureMap
Windsor/MicroKernel
Ninject
ASP.NET MVC
Ruby
IronRuby
W*F
Silverlight
And on and on and on…

“As to the methods there may be a million, but principles are few.”

Confessions of a First Time Manager

Tim Barcz — Sun, 13 Dec 2009 04:10:39 GMT

Many months ago I wrote a letter to upper management about principles of software development and the ways in which should build software. Since that time my role has changed within the company and for the first time in my career I’m managing a significant number of people (at a previous company I was an R&D Manager but the team was much smaller).

Below are a few observances/realizations I’ve had in the months since I’ve made the transition that I want to share with you:

Just cause you’re the manager doesn’t mean you know everything – Just because someone has tapped you to lead the team doesn’t mean “you’ve arrived”. You don’t automatically go from individual contributor to all-knowing edict maker.
Don’t Relax/Stay involved – Too many managers think because they’ve “arrived” they no longer need to keep pushing themselves. They think they are afforded some special privileges or don’t have to abide by the same rules others are held to. Not wise.
Rely on your team – This one is often hard. It was likely your contributions as in individual contributor that got you noticed for the management position and it’s often hard for an individual contributor accept the role change and not want to tackle challenges individually or continue to contribute. As a manager you’ll have to rely on your team to see the same level of success as a manager as you presumably did as an individual contributor. You’re no longer measured on what you do but rather how your entire team performs. This one is admittedly hard for me and I’m growing into this more and more every day.
Build your team – As an individual contributor you were primarily responsible for just one person, yourself. As project lead or a team lead you’ll have more responsibility but likely you won’t have people reporting directly to you. As a manager you’re now responsible for everyone on your team and giving them the opportunity to be the best they can. Give people the freedom they need to do great things.
Be honest - Don’t lie, shade the truth, or embellish. When you mess up, fess up, I believe the team will respect you more for it. ‘nuff said.
Never ask your team to do something you wouldn’t do yourself – Managers who require/ask team members to do something they wouldn’t do themselves are being unfair. Asking your team to work late while you get to leave every day at 5:00 is an amateur move. Asking the team to give up the weekend might be a necessity at times. Just make sure if you ask, you’re right there alongside of them.
Don’t be a bottleneck to change – The team shouldn’t always move at the speed of the manager. In general just because you don’t understand something doesn’t mean it shouldn’t be adopted. If you cut your teeth on VSS and were a ninja in VB.NET but now your team wants to move all projects to C# and this new thing called Git, don’t blindly say no. Technology moves fast, if you have a trustworthy team, you’re going to have to let go a bit and rely on the team (#3). Remember, you don’t know everything (#1) and you need build your team (#4), sometimes that may mean doing or trying something you don’t quite understand.
Don’t be afraid to push for change – While you shouldn’t be a bottleneck to change you shouldn’t be afraid to push for it either. As a manager you typically have a greater visibility to the team or the process and if you see something that could be improved you shouldn’t necessarily wait for someone on your team to bring it forward. You’re still part of the team
Hiring/Firing Sucks – Movies make firing seem like an easy thing to do and an ego-boosting power-trip. It couldn’t be further from the truth. The days I’ve had to let people go I’ve rarely slept the night before. There’s nothing enjoyable about the process of taking away someone’s livelihood. Hiring can be fun, but most often it’s time consuming and all the time you spend interviewing is wasted except on the one person you hire.

You’ll notice that many are intertwined and I think at the heart of many of these is pride. Pride is a dangerous beast, avoid it at all costs. Whether it means you have a trusted friend or colleague keep you in-check or you do frequent self-assessments, don’t let pride seep it.

Please note that these are my personal observances that I’ve taken mental note of while on this journey. Your mileage may vary.

I Just Cloned, Why Did Git Change My Files?

Tim Barcz — Mon, 30 Nov 2009 04:35:00 GMT

Being new to Git I got thrown off a few weeks ago when cloning a remote repository and immediately seeing changes after the clone completed. Scratching my head a bit, I reached out on Twitter and James Gregory came to the rescue.

How is it that right after a git clone <url>, git status shows modified files? (http://twitter.com/TimBarcz/status/5920294511)

What James showed me was that there is a setting core.autocrlf on your system which needs to match the remote repository. If it does not match, when you clone the directory files will be changed.

After experiencing this myself and coming across it again the other day, I thought I’d put a quick video together showing the problem and the fix, since I suspect others will have it at some point as well.

Git - Core.AutoCrlf Setting from Tim Barcz on Vimeo.

To recap: when cloning a new repository, always perform a “git status” command right after the clone. If you see modified files, a core.autocrlf mismatch is likely the culprit. Change your setting, clone again, and you should be good to go.

Devlicio.us Lands Another - Rob Reynolds

Tim Barcz — Mon, 23 Nov 2009 04:05:00 GMT

One of the goals of the devlicio.us community is to bring you some of the best developers and content in the developer community. Over the past few months Devlicious has added a few new people to it's growing blogging community. If you haven't noticed already, we've added another, Rob Reynolds.

Rob is from the Kansas City area where he works at a bank where he says, "The doors are always locked and there is no money inside." I met Rob about a year ago at the Alt.NET Open Spaces conference in Seattle. Rob and I hit it off immediately as we share a lot of same passions for IOC, SOLID, DI, and other neat acronyms.

Rob is an automation expert and is continually looking for ways to use automation so he can focus on more interesting things. "Automate your life" is his mantra. He automates everything from his bills and retirement to computer backups, database restores and everything code.

Rob is also heavily involved with the open source projects and manages a number of projects including UppercuT, RoundhousE and Bombali. He's contributed to other OSS projects (MSBuild Community Tasks, Tarantino) and is also a committer for AutoTest.NET.

When it comes to continuous integration and automation Rob is your guy. I'm thrilled to be blogging alongside him and have the opportunity to learn with and from him. Please join me in welcoming Rob to the Devlicio.us community.

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.