There is No Homunculus in your Software

§ January 12, 2009 06:52 by beefarino |

I want to refactor some code to a strategy pattern to isolate some complex authentication procedures, rather than have hard-coded behavior that prevents unit, load, and performance testing.  I just had a very frustrating discussion about it ...  

Developers talk about their code as if it were people all the time.  I do it, you do too.  Most of the time it's harmless, as in this little quip I said this morning:

"So when the service wants to authenticate the client, it will ask whatever authentication strategy is available."

Everyone in the conversation obviously knows that the application isn't capable of wanting or asking, and that these are metaphors to hand-wave over the technicalities of calling on an object.  No harm done; but consider the reply:

"But how would the service know that the client was really authenticated unless it does the work itself?"

Both examples show a kind of anthropomorphism ( like when your car won't start because it's upset with you for not changing its oil, or that your laptop doesn't like the couch because it won't connect to your wireless network there ).  Wants and asks describes dependencies and actions of the software - in short, the software's behavior.  Know attributes a conscious state to the software - that it somehow can understand the difference between doing some work and calling someone else to do the same work, which is nothing short of a direct demotion of a functional requirement ( the service MUST authenticate all clients ) into a software implementation ( this class MUST contain all authentication code ).

There is no homunculus in the software.  There is no little dude sitting in a virtual Cartesian Theater watching the bits fly by and getting upset when things don't happen the way he thinks they should.

Software doesn't know anything.  Software does whatever it is told to do.  If the service contains the authentication code, or if it delegates to a strategy that performs the same action, the behavior is the same.  Given that, if the former is prohibitive to testing, I say do the latter and test my heart out!!




Accountability and Software Development

§ January 7, 2009 01:26 by beefarino |

Jay Field today posted The Cost of Net Negative Producing Programmers, where he describes his view of how the software development industry fosters NNPPs via overpromotion and a lack of accountability.  A good read, with some good points, especially about the total cost of keeping NNPPs on a software team.  However, I don't agree that developers are never held to the same legal and financial accountability as, say, doctors or lawyers.  Consider industries I've worked in my career....

Education: producing software that exposes certain identity information of a public school student, such as their SSN, is considered a crime in some states.

Gaming: code up software for a slot machine with a hidden a payout indicator (like a pixel that turns red when the machine is ready to pay out) and you win a nickel in the joint.

Medical: a programmer can be held liable in civil court if the software controlling a medical device causes an accidental death.  A friend of mine likes to relay the story of a programmer who skirted civil liability by proving that a third-party software library had mishandled a divide-by-zero error that ended up killing three people with radiation poisoning before the problem was noticed.  

And the coup de grâce: as a U.S. defense contractor, if you produce software that leaks secret information to an enemy of the state, you could be charged with treason.  If the enemy leverages the information in a way that results in the death of an American citizen, you become eligible for the death penalty.

You're probably thinking that my examples are obtuse, rare or from highly-regulated industries.  So the lack of accountability is isolated to business software...  

Think again.  Consider that some states, like Oregon, have inane "anti-hacker" laws that effectively elevate corporate IT policy into state law.  Just ask Randal Schwartz about it (that's his mug along-side this post, BTW).  In these states, someone who writes code that even attempts to access what ACME considers "sensitive data" could go to prison and pay massive fines, even when ACME chooses to place that sensitive data on a public network.  If you've ever had to wade through the corporate IT security policy for a large corporation, you understand why this is so freaking retarted and should scare you out of your khakis.

All that said, I do agree with Jay in that I believe the software industry overall to be a prima donna when it comes to liability and accountability.  In most industries when you produce a product that fails to meet its intended purpose, you can be held accountable.  E.g., when ACME makes a can opener that fails to open cans, they can be held accountable for the cost to the end user.  Software is the only industry I can think of where you can produce a product that is purchased by the end-user to meet a purpose, and then force the end-user to agree to a usage license that alleviates you from having to meet that purpose at all.



Resolution 2009: Be a Beacon, Bypass the Bugzappers

§ December 31, 2008 06:39 by beefarino |

Being the last day of 2008, I thought I would share my professional resolutions for 2009.  First, let me share with you what someone recently said to me during a discussion about leadership:

"Every person shines a light for others to see, and they choose whether that light is a beacon or a bugzapper."

He went on to explain that a beacon uses their experience, passion, and knowledge to to make people better.  A bugzapper uses their experience, passion, and knowledge to bring people down, to make themselves feel bigger by making others feel smaller. 

Now that we're talking the same language, my professional resolution for 2009 is to be a better beacon.  My goal is to be more successful at beaconage by trying some of the following things...

get out of my silo 

My team works fairly independently, along clearly delineated sandboxes defined my expertise.  I hate this - I'm not an expert in anything, so rather than feel useful I feel pigeon-holed, and my projects are usually so isolated that I end up working on them alone.  The work is stagnant, usually off-the-backlog, and I never feel like a "real" contributor.  So, I'm going to start finding ways to help out in other areas of the system, and spiking some projects ideas that touch areas outside of my sandbox. 

I'm not sure how I'll make this happen or how welcome my presence will be, but our team has become a skeleton crew steering a galleon, so I think I can make a few opportunities for myself ...

try more, do more, write more

I feel like I should accomplish more than I do, both professionally and personally.  I'm going to try some modest time management tactics and see how much more stuff I can get done.  E.g., I'm trying out maintaining my away-from-work projects and spike ideas using a backlog, and managing their execution with sprints in the hope that I don't pitter away my free time on endless and unnecessary polish.  

Moreover, I want to update this blog more frequently with details of these projects and spikes.  I love to write, and this blog my primary outlet for it.  

smile more, talk more

I know it sounds silly, but I'm starting to understand that to most people a 6-foot 2-inch 200+ pound barrel-chested dude with hair turning to dreds halfway down his back is scary-looking.  And I'm a thinker, so I tend to be pretty quiet unless I have questions.  The combination can come off ... unwelcoming.  So, I'm going to try to wear a smile and chime in more by default, and see what that gets me.  

cope with the bugzappers

This is, without a doubt, going to be the hardest part of my resolution.  There are (and always will be) people chomping at the bit to shit all over my efforts, and I tend to take that rather personal.  I never enjoy conflict, but I understand conflict is necessary to improve myself or others.  However, being brow-beaten, chided, degraded, or ignored frustrates me to no end and accomplishes nothing beyond making me want to kick the bugzapper in the sack.

That is my biggest obstacle at this point: coping with the bugzappers in a way that doesn't turn me into one of them.

Suggestions welcome.



Effective Retrospectives

§ November 17, 2008 09:29 by beefarino |

Matt Grommes wrote another thought-provoker today on sprint retrospectives; my comments started wandering and found their way into this post...

The few retrospectives I've facilitated have taught me a few tricks.  Matt is correct when he says that a retrospective can turn into monster vetching session if allowed to do so.  In my opinion there are two keys to avoiding this:

  1. provide a structured way for the team to express their input;
  2. timebox everything. 

I've found the following retrospective structure to be effective in producing actionable feedback....

Prerequisites

I show up to facilitate a retrospective armed with the following items:

  • a white board with working markers and an eraser;
  • green, pink, and yellow post-its;
  • pens;
  • a kitchen timer;

Sometimes I bring a yummy treat, but I've had that backfire when the sugar rush ebbs and the team starts to wander mentally.  I also try to schedule the retrospective as the last event in the workday for everybody, but early in the week.  This seems to keep the team at ease, but focused.

First: Establish Trust in the Process

Like confessions extracted under coercion, feedback is worthless when obtained from someone who doesn't feel secure enough to be honest.  Agile processes in general rely heavily on open communication, and I found that my non-agile team displayed a lot of mistrust in the retrospective's goals.  

I begin each retrospective with a technique described in Agile Retrospectives: Making Good Teams Great that is aimed at measuring the willingness of the group to communicate.  Each person writes on a post-it a number between one and five inclusive, indicating their willingness to participate in the discussion to follow:

  1. I will not speak;
  2. I will be quiet and let others talk;
  3. Some things I will discuss, some things I will not;
  4. I'll talk about almost anything;
  5. I'll talk about anything.

The anonymous post-its are collected, tallied, and discussed briefly.  Obviously the goal is to have all fives, maybe one or two fours in the mix.  The times I've seen anything else, it's either because a communication problem exists on the team, or the goal of the retrospective is in question (e.g., QA feels like they will be scapegoated for a missed deadline).  

I keep discussion to five minutes, reiterating the retrospective Prime Directive, making sure that everyone knows they are expected to keep the conversation productive, and that the goal is to make the team work together better.

Second: Discuss Good Things

Next I pass out the green post-its and pens, and ask everyone to write down as many things as they can think of that worked well during the sprint.  I ask them to include team and personal efforts,  new or existing processes, anything they can think of that made a positive contribution to the effort.  I use the timer to box the task to 5 minutes.  

I collect the anonymous post-its and start going through them one at a time, collating as necessary.  I read each Good Thing aloud and open the floor for discussion.  I try my best to categorize them on the whiteboard as we go, so the team can see common trends.  For example, several post-its may comment on positive effects realized in documentation and QA from adding a bit of structure to the developer's subversion commit notes.

This part of the retrospective is generally pretty easy.  There isn't a lot of gray area in terms of choosing to maintain a practice that has a positive effect on the team. In addition, I find that discussing the positives first helps the team open up more during the next task...

Third: Collect and Categorize Bad Things

I pass out the pink post-its, set the timer for 5 minutes, and have the team jot down anything they felt impeded their work.  I emphasize "anything" - I would rather someone write down 10 also-rans and 2 gems than to spend the entire time deliberating on what to write at all.  

Against the advice of most retrospective experts, I ask the team *not* to exclude personal remarks about other team members; however, I do remind them that the remarks should be constructive, and that the retrospective is not a performance review.  For example, I would consider this appropriate:

Jim would benefit from writing more unit tests, having regular peer reviews, and mentoring.

but this inappropriate:

Jim's code sucks and never works.

As usual, I collect the post-its anonymously (I like to use a coffee can with a slit in the lid, BTW), during which time I draw two columns on the whiteboard: "Under Our Control" and "Out of Our Control".  I read each Bad Thing aloud and ask the team a single question:

Do we have control over this?

Their answer is usually unanimous, and it dictates which column the post-it falls on the white board.  There is no discussion of the Bad Thing at the point - the purpose of this task is only to isolate whether the Bad Thing is something team can fix themselves. 

Finally: Discuss Solutions and Take Action

Once the team can see what they can control and what they can't, the discussion can begin.  I spend a few minutes on the "Out of Our Control" items, but only to alleviate fears and to keep the discussion solution-focused and positive; I then remove those items from the board.

Moving on to the remaining post-its classified as "Under Team Control," I align them down the left side of the board in no particular order and draw racing lanes across the board for each.  I then ask the team which Bad Thing they believe had the most negative impact on their work, and we start the discussion there.

This is the part where I find the role of facilitator to be most important. It is very easy for the team to drift off-topic, or for to get bogged down in complicated solutions to simple problems.  I find it helps to focus discussion by reiterating one simple question:

What can we do today to prevent the Bad Thing from happening tomorrow?

Most of the time the team will produce a viable solution.  If the team can't gel on a fix, I pass out the yellow post-its, we storm out fixes for a few minutes, collate them in the racing lane, and then discuss.  The point is to keep the conversation on-target and constantly moving forward.  Once the team settles on a solution, I jot down the actionable items in the racing lane.

I repeat this process for each Bad Thing, allowing the team to choose the ordering, spending at most 10 minutes on each one.  If we get through them all in the retrospective's timebox, I'll open the floor to general discussion; however, my experience is that there is little else to discuss at that point if I've done my job.

Offline: Summarize and Reiterate the Solutions

Once the retrospective is over, I write up a short summary.  I list all the Good Things, and all the Bad Things and their proposed solutions.  I send this out to everyone involved, both pigs and chickens.  I also keep a copy handy to remind myself and others of the specific commitments we made as a team to better ourselves.

So there you have it Matt.  In my limited experience, what I find makes an effective retrospective is lots of structure to focus the team on one thing at a time and curb the naturally vetching tendencies.