SandyWalsh.com

Reminded me of this "Friends" episode : ...

2012-05-16T07:55:09.203-03:00

Reminded me of this "Friends" episode : http://en.wikipedia.org/wiki/The_One_Where_Rachel_Smokes

Very insightful! 20 years ago my VP knew this and...

2012-03-29T09:21:15.792-03:00

Very insightful! 20 years ago my VP knew this and would send me out daily to smoke with folks in different departments JUST to keep a pulse on these OOB conversations.

You've totally nailed it. As a developer that...

2012-03-27T13:48:00.936-03:00

You've totally nailed it.

As a developer that works primarily remotely, I encounter this issue quite often. On-site developers work together, making decisions over coffee or just chatting in their cubicles, and information doesn't filter down to those not present. This can even lead to divergent designs for related feature sets and technical debt.

Lots of the right hand now knowing what the left hand is doing.

Nicely put Sandy. This is a road I have travelled ...

2012-02-03T10:23:14.506-04:00

Nicely put Sandy. This is a road I have travelled many times and all the routes you discuss here. I can't make comment on the developer connection, but I burned wood for over 25 years and obtained it in many ways. While living in Dartmouth in our first house, I bought 8' lengths and bought a chainsaw to "chunk" it up my self. A ton of work but great exercise like you say. I rented a gas powered splitter a few times, but mostly I split by hand. This was a fantastic process, not just exercise, but it grew to be a very Zen like activity for me. Sort of at one with the edge of my splitting axe and the grain of the log. I know. I eventually moved to the Valley and bought a 16' flat bead trailer, truck, more saws and even sold wood for a while. Big investment. My next step was to open my own Wood Stove store which I ran successfully for 20 years. I became WETT certified in 89 and was National President then President of WETT Nova Scotia for quite a while. All this time advising folks on how to cleanly and safely process their own firewood. We will have to chat about this more over something aged in Wood barrels Sir. Oh and by the way, a face cord is an illegal measure for firewood in Canada. Worked on a project with Measurement Canada.

Later

This is a good point Sandy. It's also a proble...

2011-11-29T16:17:55.485-04:00

This is a good point Sandy. It's also a problem when you are doing funky RPC casts that are no longer sending the correct type of data the end function is expecting (ran into this today in OpenStack).

Another supporting point for static type-checking is that programmers are lazy and don't always go out of their way to inspect for everything that is calling a function. If someone is reviewing code, it's hard to go behind everyone and make sure they do this.

Good post, Sandy. I disagree on a couple of points...

2011-11-22T12:08:44.574-04:00

Good post, Sandy. I disagree on a couple of points, though.

I'm much, much, much more comfortable using fakes that maintain some amount of state than relying on the continued correctness of thousands of ad-hoc mocks objects. If the fake exposes more than a couple(!) of methods, I just add tests for the fake. I can run the tests against the real thing and against my fake, and see that they do the same thing. This pattern has served me quite well a number of times now. The amount of ad-hoc mock objects we have in Nova right now gives me the heebie jeebies. A method that mocks out a call to the db layer returning an object with an attribute that has since been moved could go unnoticed for months until some almost entirely unrelated change reveals that something has changed incompatibly. This is pain to clean up after.

I disagree about your 80%/20% thing. I think unit tests are even *more* important for the things that only 20% of your users use. If the stuff that everyone uses breaks, you'll find out in a jiffy and someone will always be up for contributing tests for that. The exotic stuff is exactly the sort of stuff you need help verifying.

I think your example of a method that doesn't need unit tests is much too general. Sure, I can think of many examples where such a method could acceptably be untested by unit tests, but in many cases, the correct, expected behaviour of that foo() method is exactly to execute those three methods in that exact order. If your mock library of choice doesn't let you verify this easily, I'd certainly whip up an ad-hoc mock that does.

@ryan, I agree, but I think you're missing the...

2011-09-30T11:42:53.236-03:00

@ryan, I agree, but I think you're missing the point of my post.

Testing the inputs and return types on a unit testing basis won't solve the problem when you're using a dynamically typed language. You *have* to do integration testing.

Otherwise, your tests will pass, but the program will fail in the field (since the inputs and/or output no longer match).

The contract of compute() includes both it's r...

2011-09-30T10:11:28.651-03:00

The contract of compute() includes both it's return type(s), and what it does. In a statically typed world, we're used to leaning on the compiler for the prior, and using unit tests to enforce the latter. But in a dynamically typed world, we need to explicitly test return types in our contract tests as well.

Arguably, integration tests are a crutch for when you're not completely testing the contract of a service/interface that your other unit tests are mocking/stubbing.

(In the real world, the crutch is often useful or necessary, but I still like to lean on it as little as possible.)

@robinbb ... heh, well let's not go crazy now....

2011-09-01T21:29:34.071-03:00

@robinbb ... heh, well let's not go crazy now. I thought you would have enjoyed by little subtle dig of

# 100 lines of C

:)

There a good summary of hybrid languages here: http://en.wikipedia.org/wiki/Type_system#Combinations_of_dynamic_and_static_typing

When you wrote "What does this mean for us Py...

2011-09-01T21:18:12.250-03:00

When you wrote "What does this mean for us Python/Ruby/PHP developers?" I thought that you were going to continue in another direction entirely. "Switch to a statically typed language" would have been another way to go. :-)

Is there a statically typed Python-like language?

I agree. It doesn't happen that often, but whe...

2011-08-31T20:00:34.010-03:00

I agree. It doesn't happen that often, but when it does the first thing I think is "Why didn't the tests catch that?"

From the feedback I've been getting on this article I think people define the term "unit test" very loosely. They're willing to call outside of the function being tested and don't strictly mock everything external.

I view that as an integration test. A test that spans multiple components. It sounds like you're in the "willing to span components" camp as well by your assumption that the compute tests should have gone red. But they wouldn't have if all external methods are mocked.

And that's not to say your approach is wrong. Perhaps I'm just overly strict on what I view as a unit test? In other languages it would never be a problem.

I think what I'm trying to do is find the boundary between a pure unit test and a full-on integration test (which I fear creating).

In the process it seems I'm learning more about how other people approach "unit" testing.

I don't really expect this to bite me very oft...

2011-08-31T19:31:19.018-03:00

I don't really expect this to bite me very often. The return type is part of the contract, and everyone knows it even if the interpreter doesn't know it, so whoever changed compute() would have known that they needed to inspect the code that calls it.

Also, wouldn't the unit tests of compute() have gone red when they made this change, since the unit tests insisted that the return type be numeric? So they would have had to change those unit tests to no longer insist on that, which certainly should have clued them in that what they are doing is changing something that someone else relies on.

But yeah, static type-checking is great when it is great.

Great post Sandy! You have a great way of breakin...

2011-07-14T15:00:23.197-03:00

Great post Sandy!

You have a great way of breaking this stuff down...

On the mocking side, I've come to love mocking frameworks for doing stubbing instead of trying to create crufty mock implementations to maintain...mockito is my favorite. I find that inline mock definition (ie when(mock.getSomething()).thenReturn("something")) much easier to use and maintain.

Thanks Glen ... feel free to use the images.

2011-07-04T17:07:59.689-03:00

Thanks Glen ... feel free to use the images.

Sandy, Great idea. Close to our Planning Packages...

2011-07-04T17:05:56.827-03:00

Sandy,

Great idea. Close to our Planning Packages and Work Packages here in DoD flight systems development.

Can I reuse those two charts in other presentations to the DoD community?

Great post, Sandy! One of the things I would ment...

2011-06-30T18:02:01.748-03:00

Great post, Sandy!

One of the things I would mention here is that the terminology around all of this is so loosely defined as to be stupid.

In a previous life, we simply referred to tests as blackbox versus whitebox. The former was more like integration/functional whereas the latter was more like unit tests. In that same vein, the last couple months have in turn told me that the things I thought of as "integration" tests were truly functional tests, and vice versa. As such, I've personally come to define things "unit tests" and "not unit tests" for simplicity's sake.

Regarding mocks, I personally believe their value should be evaluated on a case-by-case basis, as they can lead to some incredibly brittle tests, especially if you're enforcing the order of method calls. As for stubs, I've come to believe the only real difference between these and mocks is whether or not you verify the mock was called explicitly, and what parameters the mock actually received. One of the testing frameworks I've used in Ruby made this same distinction: stubs only returned a value necessary for a test, whereas a mock would vet the input and place a hard requirement on whether or not it was called.

That was a very well written article. Being from ...

2011-05-26T01:30:15.001-03:00

That was a very well written article. Being from Los Angeles I have no experience with firewood, and enjoyed the rather foreign process. Then at the end you really brought it full circle. Very nice!

Hi Sandy, Welcome to the Kanban is better that It...

2011-05-22T23:02:24.870-03:00

Hi Sandy,

Welcome to the Kanban is better that Iterations party! For the record, I am BIG believer in Kanban.

I don't think the core of the arguement is about process or efficiency. I think it is more about culture and values.

Reading your post, I really got the sense that you are coming from the perspective of technical excellence. I also hear you talking about the developer's perspective.

This is very striking for me. Scrum and Agile requires a whole, cross-functional team. The values of Scrum are much more around succeeding as a team and growing - perhaps that is why it has not sat well with you?

What you value will tell you how you see effectiveness: on the one hand keeping developers busy and on the other hand working as a team.

So I can see how from your value system, Scrum is probably the worst thing that could happen.

I have written quite a bit about culture since I think it is central to understanding where the Agile/Kanban community is. e.g. http://agilitrix.com/2011/04/problems-with-agile-check-your-culture/

BTW, for the record, "Stories" are an XP technical practice - Scrum has these silly things called "product backlog items".

Regards,
Michael

Nice to see someone thinking outside "the box...

2011-05-17T05:10:32.405-03:00

Nice to see someone thinking outside "the box"

Nice to see someone thinking outside "the box...

2011-05-17T05:09:53.091-03:00

Nice to see someone thinking outside "the box"

Thanks Tom! I agree ... really it's just askin...

2011-05-02T16:52:06.609-03:00

Thanks Tom! I agree ... really it's just asking person to person "whadda ya think?" and realizing it's all just an educated guess. 'Confidence' works for me. Someone else suggested 'Morale' ... anything really.

Nice post - lots of food for thought. I would als...

2011-05-02T16:36:15.580-03:00

Nice post - lots of food for thought.

I would also quibble with "sentiment", but don't like the proposed alternatives much either.

How about "confidence" or "comfort level"?

-Tom Bushell

Hey J.B. thanks for the feedback. I agree there h...

2011-05-02T10:50:59.315-03:00

Hey J.B. thanks for the feedback.

I agree there has to be some "thought time" set aside before tackling a problem. I'm talking about what happens after the plan-of-attack has been established. If the outcome of your planning says "I can get this done in a reasonable time, just let me do it". But if the management practice dictates that all tasks have to be broken down to small chunks regardless, there's a problem.

I don't think any effort should go longer than 3 days without a push to a branch for risk of "going dark". I may even argue 2 days. The code is the important thing, not the project management tasks.

I can think of many occasions where developers have ticked off "programming" tasks for the project and still not delivered any production ready code. Devs can go weeks playing that game when poor management is at the helm.

So, do devs hate tasking out a story?Yes, when the breakdown is artificial or provides little value. Do you really need a breakdown of every button on a dialog box? I'm comfortable with that being a fairly blanket statement. Do devs need time to get a plan of attack? Absolutely. And we should all love creating one.

Hm, Sandy. I was with you right up until this: &q...

2011-05-02T10:27:37.349-03:00

Hm, Sandy. I was with you right up until this:

"Developers hate having to break down tasks to such a fine resolution that they can be tracked in 4-8 hr intervals. If I have to think about a problem to 4hr resolution I may as well just code it. Why not 1 hour? Why not task out to every 30 minutes? Simple, it's a case of diminishing returns. The time it takes to document the tasks outweighs the effort itself."

Really? "Developers"? or you?

Early in my career, I met a colleague who told me how to distinguish a senior programmer from a junior programmer: give them a task and watch them for 15 minutes. The junior programmer has already started typing.

My point: few people like planning out their work. Most would rather just do it. Still, in order to avoid doing too much, veering off track, doing the wrong thing, and so on, we train ourselves to plan the work out. This way, we have more signals than our intuition to help us detect when we go off track, do too much, or get stuck.

Even so, I like the overall message, although I'd add that timeboxed iterations are useful as an intermediate step from very long cycles to free (iterationless) cycles. I usually cut feedback cycles in half repeatedly until we reach an effective size, and when the overhead of tracking exceeds the amount we can do in a cycle, then we stop tracking so closely. That equates, I think, with the iterationless approach.

foredecker: thanks! Mark: progress can still be m...

2011-05-01T10:13:59.384-03:00

foredecker: thanks!

Mark: progress can still be measured (in time units) by code getting submitted and reviewed. So long as the developers don't go longer than, let's say, 3 days without doing a push to a branch. As for "what to work on", the customer still controls the backlog, but there are no "time blocking" impediments to picking them up.

xhevahir: heh, yeah, sorry about that :) I like the idea of "morale" as well. The great good of the team. Same principle ... thanks.