Friday, September 30, 2011
Tuesday, September 27, 2011
"I predict that you pretty quickly will get feedback from your teams that the new process is reducing their productivity. They will ask to go back to the old way of working, in which they had the opportunity to “stay efficient” by working in larger batches and passing work between departments."
Ries, Eric (2011-09-13). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (p. 19). Crown Business. Kindle Edition.
On external quality:
Torvalds concludes, “Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.”On tooling:
“I don't think tools are all that fundamentally important.”
“Now, what is important is that there's a good workflow for the project, and tools can certainly help with that,” said Torvalds. “But most projects don't necessarily really need tools. There's a lot of projects that simply don't have enough changes to really require any tools at all for their work flow; [...]"
Monday, September 26, 2011
- The involvement they bring to the session
- The degree to which they both focus on the code instead of each other
- The degree to which each recognizes the contribution of the other
Saturday, September 24, 2011
Even tired, slightly battered, and a little frustrated, I had a wonderful day.
I was pleased to meet up with many great coaches, devs, managers, and non-IT people here. I even have some new "new best friends."
The morning sessions involved growing learning cultures, integrating project teams, and systems thinking. They were had great questions, wonderful discussions, and prankish humor. It was a great morning.
I had intended to participate in the afternoon sessions, but the first one (on complacence, coincidentally) I missed to talk about other passions of mine with some of my coaching friends of old, and some brand new ones. We talked about coaching psychology, whether our coaching was necessarily agile, and how to avoid "going native."
Entirely without any intention to do so, I missed all of the afternoon sessions. It was a really great time, though, and the contacts are very important to me.
Tomorrow I'm running two sessions of the three time slots available, so I guess I can't miss much.
In the morning we're cataloging pair programming patterns, and in the last session of the day we're playtesting an agile version of Eno's "Oblique Strategies."
There is a lot of interest in a new site/blog for posting and analyzing code, in the strategies deck, in Agile In A Flash, and in the new pair programming work that Jim Hood and I are starting to work on. I have great stuff to do and need to get cracking.
I'm hoping to move one of my sessions so I can join George Dinwiddie and friends in a talk about metrics, but we'll see in the morning. I even had a minute or two with Lisa Crispin.
I can recommend ACCUS for everyone in the business or in its periphery as a great meeting of minds. I'm tired, and yet it has kept me energized all day.
Tuesday, September 20, 2011
Here's what I say:
- Never pull from a broken build.
Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem.
- Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way.
- Never push to the CI server if your local build is broken.
If your build is broken, it inconveniences only you. If someone is working on the build and you push a second mistake, they won't know if they fixed it or broke it worse. If the build is not broken, why bother pushing errors to it?
- If you're not fixing the build, never push a working local change to a broken build.
This is a kindness akin to not walking in the dirt your mother is sweeping up. If you push a change while the build is broken, the person fixing the build will have yet another update/build/test cycle on his hands before he can push his fix to the server. Don't punish the volunteer by pushing your changes. Wait, pull, merge, retest.
We have installed annunciators for teams. Sometimes they are flashing lights, sometimes a glowing orb, sometimes speakers playing a particular noise, sometimes it's just a person standing up and yelling that the build is down. Usually there is some electronic communication (jabber message or email) as well.
Why do we all need to know that the build is broken, and how long it is broken? So that we can alter our behavior. Someone needs to jump in and fix the build quickly, and everyone else needs to let them or help them. By leaving the build broken, continuing to build and push code as always, or pushing additional errors into the build, we are just getting in the way of the team.
Build annunciators should let you know when you need to get out of the way. They don't have to be piercing and shrill or overly bright, but they need to keep the team aware that the build is not "green."
It's not just a good idea... well, actually it is.
Friday, September 16, 2011
Wednesday, September 14, 2011
|Annunciator #2 video, woofer, and R/L speakers.|
Our intention is that these sounds, playing through a decent set of speakers, will create an atmosphere of something being "not quite right." With both systems playing test noises, it was a tad eerie. You really felt that there was something different about the space.
It is a bit more subtle than flashing lights, and we're hoping this will be an advantage. Developers will know the build is broken, and will have incentive to get the space back to normal (it is a little annoying) but will still be able to have conversations and won't get headaches associated with flashing lights.
Tuesday, September 13, 2011
- Scrum of Scrums
- Changes embodied in team behavior.
- Status of Kanban boards
- Things missed
if os.path.exists("/tmp/uPlayer"): f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close else: os.mkdir("/tmp/uPlayer") f = open("/tmp/uPlayer/STATUS", "w") f.write("IDLE") f.close
Really, now? We start by duplicating the whole open/write thing in order to create a directory? Maybe one of the problems people have with clean coding is that their examples are poor. If you write, it behooves you to write refrigerator code.
Not to mention that close is a function, so it needs parentheses. This code doesn't even do what it thinks it is doing. It's closing the file when f goes out of scope, not when we reference the f.close bound method.
It makes me sad for the children.
Monday, September 12, 2011
Tuesday, September 6, 2011
You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip.
In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way.
In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating.
If tests were product, then it would make no difference whether you do them first or last, and redundancy would be silly and worth avoiding.
If tests are rightfully seen as process, then redundancy is "coherence" and not worth avoiding. It helps us move forward.
The biggest problem with TDD is that if you're not doing the process, then the product (tests) don't make sense.
Hate TDD? Then there's a good chance you're not actually doing it.