I have noticed a significant difference in the results achieved by teams with pairing depending on how they approach learning to pair.
In particular, many people don’t expect pairing, itself, to be a skill. They don’t realize that they’re going to have to learn new ways to think, to problem solve, to be creative, to filter their perceptions, and even to converse. Since they don’t realize this, they get surprised. And then they set themselves up to make that learning hard, and quit when they get poor results and find pairing to be hard while learning. Continue Reading »
Posted in post | Tagged Agile, learning, pair programming, pairing | 3 Comments »
An overheard conversation at work got me thinking while I was headed home. I’ve now got to send some of those thoughts your way.
The one guy was arguing against agile on the basis that it “throws the baby out with the bathwater” with respect to design. Me made several statements. Some are true, some are partially true, and some are flat false. These statements are:
- There is still a role for design when trying to release quickly (true).
- Agile throws design out the window (mostly false).
- Agile only works with 5 people, in one room (false).
- Agile ships prototypes, not real code (false, but an easy misinterpretation from a true statement: agile teams always ship the simplest thing that could possibly give them the feedback they need).
Assuming the above represents his position, I would respond as follows. Continue Reading »
Posted in post | Tagged Agile, design, feedback | Leave a Comment »
I keep writing up talk submissions for conferences. They get accepted. And I give talks.
Yet it occurs to me that this is the “if I build it, they will come” approach to speaking. I’m going to turn it around. This is a request for requests. Continue Reading »
Posted in conversation | Tagged Agile, speaking | 4 Comments »
I just published an early relese of my Simulated.FileSystem library. This library makes it easier to separate platform concerns out of my models. It works really well with a hexagonal architecture.
This library will define a set of ports for common external dependencies, with multiple adapters for each port. The initial release just includes a file system port, with two adapters: native file system and in-memory file system. Continue Reading »
Posted in post | Tagged Agile, file system, no mocks, Simulator, tdd | Leave a Comment »
I was calmly reading stuff when someone said something wrong on the internet. I got angry. It touched a common nerve so I got angry out of all proportion. I decided to respond to my anger…by saying stupid stuff on the internet that others can use to make themselves angry.
What made me angry? In the talk about values, the author said the following:
We humans are inherently complex and, while logical thinkers, we are also led by our emotions and some inherent animalistic traits that can’t reasonably be overcome.
Bullshit! I am not logical! How dare you denigrate me so! (as I said, angry.) Continue Reading »
Posted in post | Tagged Agile, brains, culture, feedback, learning | 3 Comments »
December 20, 2011 by Arlo
I am looking for help.
I am project maintainer for the OData client library for iOS. I need to find iOS developers to use this library to build apps. I also need to get more contributors. Continue Reading »
Posted in post | Tagged iOS, Objective C, OData, OSS | 2 Comments »
I am giving a couple of workshops in the next few weeks on refactoring. It’ll be a guided fishbowl experience. I start the pair with code that has specific design problems, then I (and the audience) guide them in ways to refactor those problems away.
I’ve got some of my code to work with, but figured “hey! I should take some suggestions from the audience!” Continue Reading »
Posted in post | Tagged refactoring, workshop | 10 Comments »
In my character printer, at one point I had some code like this monstrosity. I know it’s a monster, because testing it
- Requires at least one test double (the
_character field).
- Involves running a bunch of code not related to the unit test at hand.
Many people don’t think this code is so bad. They discuss various ways to test it, usually involving more mocks.
I’m going to show another way. Since it doesn’t require mocks and this is my blog, it’s a better way. Continue Reading »
Posted in post | Tagged design, example, no mocks | 6 Comments »
I recently posted an entry about replacing mocks with Simulators. That one used a Simulator from my running example code. Here’s another example, which may make the concept more clear.
This is a file system simulator. I’m building it out as a generic simulator, re-usable across projects. Right now, I’m using it Continue Reading »
Posted in post | Tagged design, Simulator, tdd | 1 Comment »
One of the common uses for mocks is to replace expensive or stateful components, such as file systems, networks, GUIs, and databases.
However, I also see a cluster of other problems that arise at interfaces with these types of components, especially when they are system-level services:
- Primitive obsession. Rarely are these APIs written as methods on an abstract object that return other abstractions. Instead, people pass around a lot of strings & things, which become arguments for static methods.
- State. Partly because there isn’t a place to put it, state tracking becomes a mess. For example, you want to ask a web service for something. Are you logged in? Do you have to do something if you aren’t?
- Lack of encapsulation. Those static methods end up everywhere. And often they end up with duplicate patterns everywhere (e.g., check for login before each call).
- The API does not feel natural to the application. It doesn’t follow the project’s idioms, and doesn’t just flow into place.
For this reason, I use an entirely different sort of test double: a system simulator. And often these simulators stop being test doubles Continue Reading »
Posted in post | Tagged design, example, no mocks, Simulator | 4 Comments »
Older Posts »
