jamieb

Why buy a computer from a company that has ties to the US government, an authoritarian government that supports dictators in Africa, the Middle-East, South America, and East Asia, including torture, drug smuggling, misogyny, and has itself engaged in abduction, detention without trial, and in relation to this case, illegal interception of communications?

"“The thing we try to help people acknowledge is that anonymous doesn’t mean untraceable,” says Byttow.

Am about to buy/build PC right now. It will be a six-core socket 2011 CPU with a couple of 780s. All the CPUs are little 1150s. Guess I'm not your target audience?

Here's another quote: "For every complex problem there is an answer that is clear, simple, and wrong."

My experience, anecdotal as it is, is that an open space per team is the most effective. This being science, when has the truth ever been precisely one end of the spectrum or the other? I'm naturally skeptical of pundits, advocating science, who point out that developers with their own office perform better than developer who share an open space with the call center and then claim that this demonstrates that private offices are the best solution.

The key quote from the article is "quieter and more private".

Maybe in the days when The Architect wrote a design doc and The Engineers went into their offices for six months, then a private office was a great way to get to the "Oh fuck this thing will never work" moment faster.

In contrast most teams I work with collaborate at the feature level: engineers work on the same feature, implementing different pieces together, before moving on to the next feature. We have other teams where individual developers take a feature and go off and work on it for a few days. The "individuals" are "faster" claiming work is complete, but the "teams" are faster at producing work that is accepted.

I should also add that while the team environment works for most engineers, we have some that absolutely require a private space, and we try to accommodate them. Individuals work differently and when we find someone good we try to make the environment work for them.

YMMV.

"TDD creates bad architecture".

What is good architecture? I subscribe to the idea that we are doing software engineering and as such there are some "generally" understood principles such as SOLID, the Law of Demeter, Cyclomatic Complexity, etc that provide objective measures of "good" architecture (I apply SOLID all the way up the architecture hierarchy not just on classes).

What I've noticed is that TDD results in code that scores well against these measures, while code that scores well is easy to test (i.e. after writing the code).

Therefore, I think the argument that TDD creates bad architecture is false.

About 25 minutes into the talk we get to the crux of DHH's complaint and it is that Hexagon is an alternative to the Active Record (which he created) and the only reason Hexagon exists is to allow TDD. Hexagon requires throwing away the really useful code that is Active Record.

Hexagon appears to be an attempt to introduce sound software engineering practices (SOLID etc) into the Ruby world (with what success I do not know). Active Record and Rails in general is really useful if what you want is what it does, but sometimes its not. The implied claim that Hexagon is a bad architecture is false. The claim that Hexagon only exists to facilitate TDD is false.

"Mocks returning mocks returning mocks"

I use mocks. Fowler and Beck said on the whole they don't use them which genuinely surprised me. They cited examples of code where the test actually enforced implementation rather than purpose. I think that's probably how I wrote tests for the first few years. Code that results in mocks returning mocks returning mocks is code that is violating the Law of Demeter. Its bad code. It happens to be really hard to test, and it happens to be really hard to write tests first that way. Universally I've only ever seen tests like that when the tests were written after the code. TDD doesn't produce code like that because its easier to refactor it rather than keep digging that hole.

Mocks returning mocks returning mocks is a symptom of not doing TDD.

"My mind works differently... I have to write code first"

Spike. Problems that I don't know how to solve I spike first (I write code with no tests, or with tests only as drivers of execution). That's easy. The hard question is, "Now I have all this code, I have to throw it away and TDD it?" That's pretty hard to stick to in a business environment. I choose to write tests-after for all those pieces of code that already meet SOLID metrics, and rewrite the code (using TDD) for the pieces that don't. The pieces that don't are very difficult to write tests for after, and they also happen to be the pieces where I find bugs (for example, I'll cut and paste a bit of logic and find its wrong for one set of inputs).

"All code should have full coverage of automated tests"

All three agreed that this is the case. Fowler: "If you have a full suite of tests I don't care how you got it [TDD or not]". I don't know about you but I'm still fighting this battle. I also have to deal with teams that have a "full suite of tests" and 80% test coverage, but where every single one of those tests simply executes code. No actual "test" occurs. Indeed, in particularly memorable test, I managed to delete 70% of the lines of code and all the tests passed (including deleting the one line that was the main purpose of the method). Approximately 90% of all the tests were complete garbage: they reported success as long as the code didn't throw an exception.

Isn't some part of their culture "be disruptive"? How does that square with "OMG Don't fuck it up!"

Will they start doing that to my phone line too? Selling my call history to third parties?

when someone gets your $197,000 house for $134, they can sell it for $71,000 and take $6000 in legal fees, interest etc, as documented in the article.

The owner loses $130,000. Don't be surprised if the person buying the house for $71,000 is in on the game too.

>We have a standardised desktop operating system that is familiar to nearly every computer user on the planet,

And then there's Windows 8.

Also, while we're on the subject, my 8 year old can put together an amazing Keynote presentation on an iPad. She has never used a Windows OS.

Hi. My team is responsible for the checkout process at a large company. I won't give exact numbers, but more than $100m goes through our teams two pages.

>by the time I'm entering my credit card details, I'm already "converted".

Our numbers say otherwise. Optimization of our checkout page is a huge deal any change, even text, comes under scrutiny, and for good (i.e. measurable) reason.

Would I put this demo on our page? If the bugs and confusion can be fixed, I might try it for a very small test group and see what happens. Not sure the confusion can be fixed though.

That's my point.

Yes. This is my point. =) Only by actually working out all these details can we have just laws, and IMHO, we would discover that most of our laws are not just.

We want law that prevents criminals from breaking into banks and stealing your cash, but what we got was a law able to be used to persecute young people to the point of suicide for accessing an "open" system belonging to an educational establishment.

The laws we have now cannot do what they claim to do without being impossibly broad or impossible to implement. As was was discussed elsewhere today, the joke of a "Do what I mean" button, is that nobody, in fact, knows what they mean, and this goes exponentially so for a congress of 500 or so people.

Yes, we should have black and white laws, and unit tests for them. So someone could write a unit test for "Will this allow the NSA to create a secret court that is outside the rule of law?" or "Does accessing a university computer that has an open access policy allow for a sentence of 130 years?"

I believe we'd see a lot simpler laws.