2010 BLogic: Sufficient Design

link -> 2010 BLogic: Sufficient Design

This muddies the waters for me but I can kinda see what he is saying. My head hurts from too many lemon bars.

Comic for April 22, 2010

link -> Comic for April 22, 2010

This reminds me of a discussion I had the other day about bugs. As long we can redefine what success is we don't have any problems. :)

Shhh. We’re Hunting Yabbits | Situated Geekery

link -> Shhh. We’re Hunting Yabbits | Situated Geekery

Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.

Like this: “Yabbit, our shop does shrinkwrap, so what works for some web app isn’t gonna work here.” or “Yabbit, we all work 80 hours a week, so we don’t need slack.” or “Yabbit, if you write tests + code, that’s more code than if you just write code”.

Let’s try again: Ever get the yabbits when introducing a new idea?

Yes, I thought so.

Whoops this always gets me. I need to start writing down the list and memorize some short canned responses.

Best-kept Secret in DDD Community: DDD Immersion

link -> Best-kept Secret in DDD Community: DDD Immersion

Coaching The Projector Rule | Situated Geekery

link -> Coaching The Projector Rule | Situated Geekery

You are done refactoring when you’re ready to project the code onto the wall for the whole team to see.

I love the part about nine year olds and his comment to actually project your code.

James Shore: Alternatives to Certifications: How to Hire the Agile Way

link -> James Shore: Alternatives to Certifications: How to Hire the Agile Way

James Shore consults and writes about high performance software development for teams who are willing to be great.

How to hire someone. Timely.

Ride The Divide - A feature film about world's toughest mountain bike race.

link -> Ride The Divide - A feature film about world's toughest mountain bike race.

I dream about this ride

James Shore: Singed Egos

link -> James Shore: Singed Egos

We still got flamed in the forums, but they went from "you're obviously stupid," to "I'm not convinced." By Internet forum standards, that's high praise.

That is a funny comment. I am going to shoot for "I'm not convinced" from now on in our design discussions.

Don't get all your stories done?

Read something interesting today in Scaling Software Agility

But at the high end, which looks like excellence incarnate, additional tuning may be required, because if a team truly hits 100 percent of stories on every iteration, then it is likely taking on too little work or deferring technical risk-laden stories until a later time. Effective agile teams typically run between 60 to 90 percent story acceptance, and even that percentage will vary significantly from iteration to iteration.

I have never read this before. I always thought you were supposed to get all of your stories done. He makes a good point that we are probably deferring technical debt to a later time. I thought you were supposed to do this though. I will keep looking around and see if other people agree with his statement.

How I Learned to Let My Workers Lead

link -> How I Learned to Let My Workers Lead

It took me additional years to learn the art of coaching, by which, in a nutshell, I mean communicating a vision and then getting people to see their own behavior, harness their own frustrations, and own their own problems.

I like this quote too. 6 months ago I would thought coaching meant something very different then what this quote defines. I still don't how to do what he is saying, but I guess knowing what I want to learn how to do is a good start. Yay for progress!

How I Learned to Let My Workers Lead - Mark Needham - CodeBetter.Com - Stuff you need to Code Better!

link -> How I Learned to Let My Workers Lead - Mark Needham - CodeBetter.Com - Stuff you need to Code Better!

Every system is perfectly designed to get the results it gets.

I like this quote. Reminds me of Norm Kerth's prime directive. Don't blame people. Fix the process.

Cuke4Nuke or SpecFlow? - Stack Overflow

link -> Cuke4Nuke or SpecFlow? - Stack Overflow

Cuke4Nuke definitely has a cooler name.

Cucumber - Making BDD fun

link -> Cucumber - Making BDD fun

Green like a cuke

James Shore: Stumbling Through Mediocrity

link -> James Shore: Stumbling Through Mediocrity

I wasn't really being asked "Does Agile scale?" (By now, though, we know the answer: yes.) What I was really being asked was, "Does Agile work in large, dysfunctional organizations? Can I keep doing all of the ineffective things I'm required to do and still say I'm Agile? I can't have a co-located team--it's out of my control. I can't have active, involved product managers--they're too busy. I can't create cross-functional teams--it would disrupt our reporting hierarchy. How does Agile scale to my situation?"

It doesn't... at least, not well. Welcome to Mediocrity.

Long way of saying you can't get something for nothing.

Important function of developers testing

Read this quote today from Scaling Software Agility by Leffingwell

There is another subtle benefit at work in the philosophy of agility. When developers are forced to think through how the code will be tested, or better, when developers realize that they themselves will have primary responsibility to assure that it passes the test, a new psychology emerges: developers write the code differently than they otherwise would have. In other words, the developers build systems that are inherently testable by building in the interfaces and methods they need to see inside their components to assure they work as prescribed. This is one of the key benefits of agile methods, and these inherently testable systems exhibit higher overall quality.

Lately I have been feeling like every time we write tests before we write the code we end up writing higher quality code. I have no real way to prove that through logic though. It just seems like having to write the test forces you to decouple your code and simplify your interfaces. This process of decoupling and simplifying gets your mind working and you end up writing better code.

Maybe we should start calling it DTT (Design Through Tests) instead of TDD. People might be more willing to give it a shot if they thought they were focusing on design instead of focusing on tests.

Strengthening your domain: Avoiding setters

link -> Strengthening your domain: Avoiding setters

As we start to move our domain model from an anemic existence towards one with richer behavior, we start to see the aggregate root boundary become very well defined.  Instead of throwing a bunch of data at an entity, we start interacting with it, issuing commands through closed, well-defined operations.  The surface of our domain model becomes shaped by the actual operations available in our application, instead of exposing a dumb data object that lets anyone do anything, and consistency and validity are a pipe dream.

Cool series