Hanselminutes with Scott Hanselman

My comment was a bit too late to be seen last time [0], so I'll repeat it here:

---

I was heavily involved with the Fit project for a while. (Fit is Ward Cunningham's predecessor to Cucumber. It used HTML tables rather than ASCII sentences.)

I find it interesting, if not surprising, that the Cucumber community is discovering exactly the same issues that we did with Fit: namely, that it encourages brittle integration tests, and that people don't use it for its intended purpose of collobaration.

I've come to believe that these problems are unsolvable.

I worked on and promoted Fit for several years. Eventually, after some deep soul searching, I concluded that Fit (and by extension, Cucumber) is solving the wrong problem. The value of Fit (and Cucumber) comes from discussions with domain experts. The tools encourage a certain amount of rigor, which is good, but you can get that rigor just as easily by discussing concrete examples at a whiteboard.

The actual automation of those examples, which is where Fit and Cucumber focus your attention, has minimal value. In some cases, the tools have negative value. Their tests are fundamentally more complex and less refactorable than ordinary xUnit tests. If you want to automate the examples, you're better off doing it in a programmer tool.

Some people got a lot of value out of Fit, and I'm sure the same is true for Cucumber. They got that value by using it for collaboration and focusing on domain rules rather than end-to-end scenarios. My experience, though, was that the vast majority used it poorly. When a tool is used so badly, so widely, you have to start questioning whether the problem is in the tool itself.

Ward and I ended up retiring Fit [1]. I've written about my reasons for abandoning it before [2] [3].

[0] https://news.ycombinator.com/item?id=7514651

[1] http://www.hanselminutes.com/151/fit-is-dead-long-live-fitne...

[2] http://www.jamesshore.com/Blog/The-Problems-With-Acceptance-...

[3] http://www.jamesshore.com/Blog/Acceptance-Testing-Revisited....

As I have read this thread, I keep coming back to how we measure competence and ability.

For example, at one point in history our IQ tests included questions based on baseball rules. So someone taking the test that didn't know the rules of baseball couldn't do well – regardless of their mathematical or logical ability, i.e. what the question was supposedly measuring.

Along those lines, I would strongly:

- recommend listening to the Hanselminutes episode on Women in Technology in the Muslim World (http://hanselminutes.com/203/women-in-technology-in-the-musl...)

- remind people that the first programmer was Ada Lovelace, and computers used to be actual people and mostly female (https://en.wikipedia.org/wiki/Human_computer) & suggest reading some of the reasons this changed (http://www.smithsonianmag.com/smart-news/computer-programmin...)

In other words, culture can strongly impact both perceptions of ability and measurements of ability, as well as impacting the equitable training and opportunity that people are afforded. I suspect that most differences in most fields are not actual sex differences (i.e. biological), but in fact are social differences based on gender (i.e. cultural based on a person's gender identity).

I would like to imagine this is more for awareness. Why would exchange server want to include x-originating-ip? Is it for validation and authentication? Do we not trust people who have obviously have authenticated as people with the privilege to send emails from a certain server?

Do we need to include this information in our email headers? Is it not enough to include the IP address of the mail server? Perhaps there is a need to do this?

I was just listening to Douglas Crockford[0] in a podcast where he talks about CR/LF and how we can't decide on whether A is correct or B is correct so we do both A and B which fits neither A's position or B's position so we pick something so neither side feels like they lost. The argument is that this middle-ground is worse than either side of the proposition.

Perhaps I am wrong. However, it is still good to know why we include this information in our emails. Is it simply a case of "we have this information, why not just include it?" or is it something to check against transaction logs? Perhaps a "distributed" way to add audit records of who logged on to the mail server? There had to be some reason why they included it, right?

[0] http://hanselminutes.com/396/bugs-considered-harmful-with-do...

Having read Shaw's recent essay [0]:

1. Because the target audience of Learn Python the Hardway is very new beginners and the pedagogy is programmed learning [1][2], Python 3 is a poor choice for the target audience of Learn Python the Hard Way.

2. Shaw is more concerned with the welfare of the book's intended audience than adherence to the dictates of Python's leading figures.

3. More subtly, that sales figures indicate a disconnect between the dictates of Python's leading figures and the interests of his students.

From my outside position, it seems Shaw has a legitimate stake in his decision and people like this essay's author have a stake that boils down to creating drama.

[0]: https://zedshaw.com/2016/11/24/the-end-of-coder-influence/

[1]: https://en.wikipedia.org/wiki/Programmed_learning

[2]: http://hanselminutes.com/407/learning-code-the-hard-way-with...

Glad to see Nancy is getting some publicity. I just found out about it yesterday on Scott Hanselman's blog. http://www.hanselminutes.com/default.aspx?showID=290

There seems to be a growing movement with OWIN, Knack, Nancy and other like projects. The .NET community is tired of sitting by as the OSS community is leaving them in the dust with cool tools and frameworks like Rack, Sinatra, Gems, Bundler, Django, Pylon and Node.js that are simpler and faster to develop with. They're tired of waiting for a new version of Visual Studio just to use a new tech. They're tired of waiting for MS to "bless" new technology. Nancy and other ALT.NET projects are trying to free and grow the C# community independent of MS and the enterprise developers making boring CRUD apps.

.NET needs something like this. C# has transformed into a wonderful and enjoyable language in 4.0, but the rest of the .NET Framework is still stuck in over-engineered enterprise-heavy wannabe Java C# 1.0 land. ASP.NET MVC is a good beginning, but this style of thinking really needs to be more pervasive in the rest of the framework.