The Greater Fool

Are you a brogrammer and is that a bad thing?

"I think what has changed," agrees my Anonymous Female Tech Authority, "is that engineers are thought of as awkward tech nerds with glasses. And now they are beer-slugging dudes who stare at sales ladies' boobs."

The recent run on brogrammers and their taking over of the tech space is greatly exaggerated. Just like most media-spawned stories during an election year, the truth is sometimes lost in search of good headline. The enterprise software space has been rife with so-called brogrammers for years. But now that they've reached the start-up world that's the darling of the media, people have noticed. Bottom line, a brogrammer is not a bro and a bro would never survive the pace of the start-up lifestyle.

An awesome talk on Dissonance Theory

Why people retreat to their original opinions when provided evidence that contradicts that position. This lesson is crucial on how to effectively influence others and reconcile our morality and judgement. We have to live with dissonance. "When a friend makes a mistake, the friend remains a friend and the mistake is still a mistake."

Apple Reports Second Quarter Results

Gross margin was 47.4 percent compared to 41.4 percent in the year-ago quarter

That's all you need to know. Nearly half of all AAPL's revenue is profit. Net Profit is increased 94% Year-over-year. Wow!

Real life grown-up August Gloop

Joey Chestnut has nothing on Alexander Valov, pictured, the winner of Moscow's caviar eating contest. Held on April 20, 2012, the contest challenges eaters to consume 500 grams (a little over 1 pound) of the pricey preserved sturgeon eggs in the shortest time period. That's roughly a CLS550 Coupe Sasha is shoveling down his gullet there. Capitalism is alive and well in Russia, my friends.

This is how every software company should be run

At a lot companies, this is where you’d see me writing something like, “so I’ve decided to leave $COMPANY, take a sabbatical, and then join $OTHER_COMPANY to find new challenges.” At Fog Creek, that’s not how it works. Joel and Michael have a strong attitude that good developers should be rewarded as developers. When I went to them and told them that I wanted to get new experiences and get back into the writing part of writing software, they were really happy to make that happen.

There's a lot that Joel Sposky has done for the software industry but I think this is one of the most significant. To reward technical people with technical responsibilities. Making a great developer into a mediocre manager costs the organization double. Tying compensation to number of direct reports is a non-starter strategy in the software business. And just about everyone is in the software business these days.

This line of argument is how we got the TSA, and how they squandered billions fondling balls and confiscating nail clippers

Testing like the TSA David Apr 11

84 comments Latest by Cássio Marques

When developers first discover the wonders of test-driven development, it’s like gaining entrance to a new and better world with less stress and insecurity. It truly is a wonderful experience well worth celebrating. But internalizing the benefits of testing is only the first step to enlightenment. Knowing what not to test is the harder part of the lesson.

While as a beginner you shouldn’t worry much about what not to test on day one, you better start picking it up by day two. Humans are creatures of habit, and if you start forming bad habits of over-testing early on, it will be hard to shake later. And shake them you must.

“But what’s the harm in over-testing, Phil, don’t you want your code to be safe? If we catch just one bug from entering production, isn’t it worth it?”. Fuck no it ain’t, and don’t call me Phil. This line of argument is how we got the TSA, and how they squandered billions fondling balls and confiscating nail clippers.

Tests aren’t free (they cost a buck o’five)
Every line of code you write has a cost. It takes time to write it, it takes time to update it, and it takes time to read and understand it. Thus it follows that the benefit derived must be greater than the cost to make it. In the case of over-testing, that’s by definition not the case.

Think of it like this: What’s the cost to prevent a bug? If it takes you 1,000 lines of validation testing to catch the one time Bob accidentally removed the validates_presence_of :name declaration, was it worth it? Of course not (yes, yes, if you were working on an airport control system for launching rockets to Mars and the rockets would hit the White House if they weren’t scheduled with a name, you can test it—but you aren’t, so forget it).

The problem with calling out over-testing is that it’s hard to boil down to a catchy phrase. There’s nothing succinct like test-first, red-green, or other sexy terms that helped propel test-driven development to its rightful place on the center stage. Testing just what’s useful takes nuance, experience, and dozens of fine-grained heuristics.

Seven don’ts of testing
But while all that nuance might have a place in a two-hour dinner conversation with enlightened participants, not so much in a blog post. So let me firebomb the debate with the following list of nuance-less opinions about testing your typical Rails application:

  1. Don’t aim for 100% coverage.
  2. Code-to-test ratios above 1:2 is a smell, above 1:3 is a stink.
  3. You’re probably doing it wrong if testing is taking more than 1/3 of your time. You’re definitely doing it wrong if it’s taking up more than half.
  4. Don’t test standard Active Record associations, validations, or scopes.
  5. Reserve integration testing for issues arising from the integration of separate elements (aka don’t integration test things that can be unit tested instead).
  6. Don’t use Cucumber unless you live in the magic kingdom of non-programmers-writing-tests (and send me a bottle of fairy dust if you’re there!)
  7. Don’t force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).

Given all the hundreds of books we’ve seen on how to get started on test-driven development, I wish there’d be just one or two that’d focus on how to tame the beast. There’s a lot of subtlety in figuring out what’s worth testing that’s lost when everyone is focusing on the same bowling or bacon examples of how to test.

But first things first. We must collectively decide that the TSA-style of testing, the coverage theater of quality, is discredited before we can move forward. Very few applications operate at a level of criticality that warrant testing everything.

In the wise words of Kent Beck, the man who deserves the most credit for popularizing test-driven development:

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

Great sanity check by David of aaaa37signals discussing the cost of testing and chasing 100% coverage. While I love the analogy to the TSA, I'm not so sure code coverage isn't a noble goal, at least in the enterprise software realm. To me, the real value of unit tests is not protecting the code from mistakes I typically make but rather the mistakes that the next developer may make.
By the time, code reaches production and needs to be refactored, it has undergone many (many) iterations, and hopefully, is concise, succinct, and descriptive enough to be maintainable. What isn't always obvious (though, probably visible in some version) are the multiple layers of intention that got to that end. Unit tests are one window into that thought process. Ends and means are often different when it comes to code.

The Free Universal Construction Kit

How awesome is this? Having loved Legos as a kid and seeing all the new generation of construction toys my boys have to play with today, these are a dream come true. Now we can mate Tinkertoys to Legos to Lincoln Logs all in the same piece! The Free Universal Construction Kit is a set of 80 interoperability adapters between 10 popular construction toys including the aforementioned sets.

They're also available as download if you have your own 3-D printer. Now to I finally have a reason to buy a 3-D printer.

Software is the future

I've heard many times how software and the people (architects, designers, developers, testers, et al) that make it happen is the currency of the future. How companies and industries will have to learn to do more with less and make up the difference with software. The other side of that equation see it that companies are replacing people with robots and processes. So how are we, the implementers of software, supposed to operate in order to be most effective? The Agile process has taught us our goal should not be to create perfect software but to gather feedback to eliminate the bad software. Well, what if those giving the feedback are incentivized to not give genuinely useful feedback since it's quite possibly their job they are eliminating?

My task as a developer is to decompose a complex problem into easily solved or solvable problems that limited computer logic can accomplish that task. I can spend the time to learn the business domain as well as the back of my hand or, more often, rely on business analysts, product owners, subject matter experts to fill in that gap. The problem that I've seen in more than one Line-Of-Business application is that those people may not be in the best position to offer constructive feedback. Professionals, which is anyone who gets paid to perform a task, want to feel valued. They want to be the keeper of the "secret sauce" that makes the machine work so well. They don't want their contributions reduced to the sum of its elementary parts. It devalues their effort, experience, and training. They don't want to see their legion reduced or eliminated by process or software.

That is the single greatest hurdle to producing quality effective software. We are using requirements from sources that have no incentive to produce quality or even valid requirements. By de-humanizing the process and workflow, we de-incentivize the very people we are trying to help.

The Daily Mash - Why I am leaving the Empire, by Darth Vader

I hope this can be a wake-up call. Make killing people in terrifying and unstoppable ways the focal point of your business again. Without it you will not exist. Weed out the morally bankrupt people, no matter how much non-existent Alderaan real estate they sell. And get the culture right again, so people want to make millions of voices cry out in terror before being suddenly silenced.

If I had Galactic Moon Coin for every time I've sound the culture alarm at a company...