Seth wrote:

...here are my two big ideas to start:

1. Humans tend to work on a problem until they get a good enough solution, instead of a solution that's right.

2. The marketplace often rewards solutions that are cheaper and good enough, instead of investing in the solution that promises to lead to the right answer.

I emailed him back:

Isn't good enough inevitable? Doesn't the square drive screw have some deficiency to it? Perhaps there's a better way to attach things together than any sort of screw could provide. Maybe we're not investing enough time in making duct tape better.

Better always is going to take some effort, and effort is not limitless. I can't go everywhere at once on a journey, I can only do one step, right now, one direction.

Your big ideas make a big assumption: that we can know ahead of time what the right answer is. Sometimes we can, but many times better only becomes visible once we've arrived at good enough.

Seth's follow-up puts a good bit of weight on the other end of the issue:

I'm not arguing that nothing is good enough. Far from it. ... But for those that are intent on creating something remarkable, it seems that the attractive vision is to believe precisely the opposite, at least about the stuff you care about.

6 years later, Seth hits up the same topic:

Good enough, for those that seek perfection, is what we call it when it's sufficient to surpass the standards we've set. Anything beyond good enough is called stalling and a waste of time.

If you don't like your definition of 'good enough', then feel free to change that, but the goal before shipping is merely that. Not perfect.

---

JonathanKohl emailed me some linkage to two articles by JamesBach on this topic. In the first, James makes this point:

Good Enough has nothing to do with mediocrity. It has to do with rational choices, as opposed to compulsive behavior. ... CemKaner, in Testing Computer Software (International Thomson Press, 1993)—standard issue to Microsoft's testers—also refers to bug fix deferral as a routine practice.

Jonathan added this bit about corporate denial in his email...

In my experience, projects that have unrealistic goals of perfection (zero defects comes to mind) tend to fail. The zero defect goal on a project always leads to politicizing failure-reporting and redefining terms. "That's not a 'defect', that's an 'issue'" is a very common one. Quality suffers because people are measured by impossible goals, so the truth gets hidden. Here's an example I saw on an Agile project that had unrealistic goals: testers and customers were bullied into not logging defects, developers redefined defects as only something that occurred after shipping the product, and even then wouldn't acknowledge problems because only one or two customers reported it.

... and then liked the topic so much, he blogged it himself.

see also ConstructionAnalogy

Software starts in the dark. If I'm building a physical RubeGoldberg machine I get visibility for free, but with code I only have as much visibility as I build into it. This is one reason I like TDD, it starts creating some visibility from the beginning.

Googling "Autotests Growl Windows" currently comes up with some outdated hits. I found this to be current - basically, it just all works. No special Windows hax required.

via Alistair Cockburn:

Trying to troubleshoot a transformed web.config file? Want to see what the transformed .config file looks like? This MSDN article includes one way to do it:

MSBuild [.csproj file] /t:TransformWebConfig /p:Configuration=[ConfigName]

MSBuild builds the application and transforms the web.config file according to the Staging transform rules. The output files placed in the obj\[Config]/TransformWebConfig folder.

Oh, and if you want to keep something out of the Web.config and only in the Web.[Config].config files, presuming VS2010 will do you transform for you ... um, no (the post is in the context of Azure, but I'm finding the same issue in just a plain-jane web app).

So, you still need a valid Web.config, but can only use Web.[Config].config transformations for building -> publishing to another site. When running local out of VS2010, no transformation is done, apparently.

InfoQ Presentation:

Ashish Kumar presents how Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository.

(Via Roy O), David Anderson weighs in on comparisons between adopting Scrum vs. Kanban:

If your organization has low maturity, limited capability at risk management, change management and decision making, and is riddled with specialization and defensiveness then Kanban is probably a better choice. If you have time to let the culture and performance evolve and improve over months and years then Kanban is the right choice. If on the other hand, your organization is highly mature and capable of assessing risk, evaluating process alternatives, making good quality decisions, and managing high impact change gracefully then Scrum may be the right choice for you.

Found this tasty bit to launch a console window running under the LocalSystem account: use psexec from SysInternals

psexec -s -i cmd.exe

If CodeIsTheDesign, then each build is probably better thought of as a prototype.

One of the hidden bits in Visual Studio which can come in handy at times is adding a file As Link:

It's useful for making sure the assembly under test's app.config file is available to the unit tests, or sharing a single AssemblyInfo.cs file across many projects.

[I originally wrote this some years ago, and it got some twitter traffic recently, so decided to publish it, part of a small collection of DevelopmentAnalogies]

I find myself frequently searching for a good analogy to convey to non-programmers to enormity of dealing with even a small to medium-sized application. The following is the one I keep working on:

My main app on the job these days comes in around maybe 75k lines of code I've written (it's hard to get a good count cuz there's a bunch of 3rd party code lines included in the count Delphi's compiler comes up with).

Of those 75k lines, I can only look at maybe 30 at one time. Of those 30 visible on the screen, I can only focus my mind on maybe to 5-15 of them. 15 lines out of 75k is only 0.0002% of the codebase.

Now say I've built a 2,000 sq. ft. house, but can only look at 0.0002% at a time -- that's about a 5 in. square. I have no ability to size up a room, no ability to see an entire window, an entire door, a cabinet, much less a blueprint of the entire floorplan. The only things I can see in one shot are items like a door hinge, a window lock, a stove top knob.

These measurements are very crude, of course ... but it seems to me, so far, to get the gist across.