Is it safer to have an unreliable build process?

People promote binaries because "it's safer".  "How do I know I've tested the same thing that I'm about to deploy", they say.

What happens when you need to do a production fix or the next deploy?  How do I know you can even produce the same artefact when you have pretty much straight out told me that you don't have a reliable build process?  Am I reduced to patching the running system?

Promoting binaries is a workaround to a fundamental problem with unreliable, unrepeatable builds and poor configuration management.  Use the workaround to survive and focus on improving so that you don't have to do workarounds.

Daily meetings and one-point lessons

I've recently went on Enna's Lean Journey Study Mission to Japan.  There is really too much to write about all at once so I'll break it down into individual points and perhaps stories.  First off...

Every Lean factory that I've visited uses daily meetings.  10 - 15 minutes, all hands, before production starts.  Given that the meeting is held on the factory floor, there are no chairs.

The focus will be on what was learned about defects from the previous production day, the goals for the current day, and perhaps going over what are called single or one-point lessons.

I knew about daily production meetings already from visiting the Australian Toyota plant in Altona but One Point Lessons are new for me.

It's an interesting idea and one that I'll think about introducing to my team.

Copy and paste once; never copy and paste twice

Until it works, you can't be sure that you understand all the variation points between apparently identical code.

Once it works, remove the duplication.  And by duplication, I really mean duplication of effort.

This is how you get faster.

BarCamp Sydney 4 on 15 November

A BarCamp is an ad-hoc gathering born from the desire for people to share and learn in an open environment. It is an intense event with discussions, demos, and interaction from participants.

http://www.barcampsydney.org/2008/10/29/barcampsydney-4-lets-do-it/

Jonathan Drori on science misconceptions

The great thing about TED is that it keeps bringing me back to thinking about fundamentally how things work.

Great talk by Jonathan Drori on 4 questions that you might think you know the answers to but are probably wrong:

Bringing world class health care to the poorest

A TED talk by Ernest Madu on bringing world class health care to the poorest:



What I find interesting about this is the creativity that occurs when you don't accept that cost constraints mean that you can't achieve your objectives.

Dan Gilbert on how to achieve happiness

A conversation with Daniel Gilbert at the New York Times:

We know that the best predictor of human happiness is human relationships and the amount of time that people spend with family and friends.

We know that it’s significantly more important than money and somewhat more important than health. That’s what the data shows. The interesting thing is that people will sacrifice social relationships to get other things that won’t make them as happy — money. That’s what I mean when I say people should do “wise shopping” for happiness.

Another thing we know from studies is that people tend to take more pleasure in experiences than in things. So if you have “x” amount of dollars to spend on a vacation or a good meal or movies, it will get you more happiness than a durable good or an object. One reason for this is that experiences tend to be shared with other people and objects usually aren’t.

 Perhaps a message for the times...

Zombies in plain English

Another example of systematic, objective problem solving:

Understanding respawn waves

Robin Walker blogs about why respawn waves are used in Team Fortress 2.  Even if you're not into PC gaming, I think it's a nice example of being deliberate about problem solving when designing (and most likely evolving) solutions.

The #1 Java programmer excuse for slacking off

 Apologies to the original.

Ensuring visibility is more important than working based on priority

Without visibility of your capacity, knowing that you're working on things in order of priority is next to useless to your customer.

If we ensure visibility of capacity, this naturally encourages working in order of priority. The reverse is not true.

Would you code the system the way you code the automated tests?

I'm implementing a feature.  Done.

I'm implementing another feature but I want to maintain requirements traceability so I'll implement this new feature in complete isolation to the first.  Don't refactor because that will interfere with traceability.

Would you code this way?  What kind of messed up system would result from this kind of behaviour?

Do you write automated tests this way?  What kind of messed up test suite results from this kind of behaviour?

At some point, you need to look at how to do the actual work

Scrum is a nice project management framework.  It isn't complete, but it's a nice start, and frankly provides actual structure that is missing in many places that only have apparent structure.  The whole certification push, despite any misgivings one might have of validity, helps push the population average up in terms of Agile thinking.  So I'm expecting that the higher population average will lead to more opportunity for positive outliers.

However, there's one thing that's typically missing when you only look at leadership and management concepts.  And that is how to actually do the work.

I suspect "actually doing the work" effectively is an important part of any successful endeavour.

Test enough to be confident vs Complete testing in time

Update: More detailed cause and effect analysis

The core conflict:

Some cause and effect analysis:

Method chain and introduce sub-type for clarity of intent

I see two kinds of method calls in our codebase:

page.select(SOME_TAG)
page.select(SOME_TAG, SOME_TOKEN)

After investigating further, I figure the second example should look like this instead.

page.select(SOME_TAG).waitFor(SOME_TOKEN)

Why?
First approach is not as clear in terms of intent. My first thought was that something was being selected using two parameters when in actuality, something was being selected using one parameter and then the system would wait based on the second parameter.

It doesn't matter if the method signature was select(Tag target, Token waitForToken) or something to that effect. When reading code, having to jump to method declarations to understand intent is an unnecessary distraction.

However...
page.select(SOME_TAG) currently returns void. In order to implement the method chaining, this now returns Page. What happens if Page receives waitFor before any Tag has been selected? It never makes sense for waitFor to appear as an available method until after select has been called.

One way to deal with this is to revert to a non method chaining approach:

page.selectTagAndWaitForToken(SOME_TAG, SOME_TOKEN)

Don't particularly care for this kind of multiple responsibility method though.

What I prefer instead is to introduce another type. So page.select(SOME_TAG) does not return a Page but a specialisation of Page (e.g., PageWithSelection) that has the additional waitFor method.

To summarise...

On Page:

PageWithSelection select(Tag target)

and on PageWithSelection:

void waitFor(Token target)

which allows

page.select(SOME_TAG, SOME_TOKEN)

to turn into

page.select(SOME_TAG).waitFor(SOME_TOKEN)