40 things all working together

A friend of mine is a high school inner city principal.  Inner city meaning Newark, NJ, a pretty tough area.

We were discussing what works at his school, and I asked him whether uniforms had an effect, given the studies that showed that they didn't.  He replied, "Uniforms by themselves don't do anything, but as part of the overall picture, they're vital.  They're one of 40 things that you have to do right.  Working together, they make all the difference."

That reminded me of Agile practices.  I've known several teams where a decision was made to hold a daily scrum.  Didn't do a lot.  People grumbled about the pointlessness and hype.

Like many big institutions, my bank is not Agile, and so I introduced pieces of it slowly.  I found weak to no benefit until I had a decent list in place:

* daily scrum
* strictly focused discussion during scrum
* burndown charts
* self-organized teams of 3 to 4 developers
* 2- to 3-week sprints
* automated daily builds and at check-in
* product backlog
* iteration planning with the product manager
* team iteration reviews
* product demos with the product manager and users
* decision to have release or another sprint after each iteration
* cross-functional skills

Once I had these things in place, I really noticed clear improvement.

But if you had added any one or two of them to our previous team and structure, no, it wouldn't have made any difference.

*Nudge* by Thaler and Sunstein

Without being aware of it, I seem to be very concerned about my or (maybe others's?) decision making skills.  Several books I've read lately deal with improving decisions.

Nudge takes an interesting approach.  Instead of questioning how people decide, it asks how decisions can be organized in a way that helps people make a wise decision.  Some might debate what makes one decision wise compared to another, but the authors point out that often people would make a choice except that they are forgetful or find the options too complex.

A simple example: defaulting 401k enrollment instead of forcing people to opt-in.  People can opt out if they so desire, but usually don't. 

The areas they discuss relate to government and institutional programs -- health insurance, charitable donations, marriage.

The theory applies very directly to software and software management.  Much of good management involves getting people to do the right thing -- and in this case, the "right thing" is more easily defined -- without using a heavy hand.  Sometimes micromanagement is required, but it should be a last resort.

Test driven development strikes me as a good way to encourage good practices.  You encourage testing and more up-front analysis by making the former easier and the latter part of the process.  Domain driven design provides tools to express the business more accurately.  You also encourage developer involvement in the business by easing the barriers to understanding.  Just working to get the developers in front of the users goes along way to this goal, as well.

Many other agile practices are less about software development per se, and more about putting people in the right spot and frame of mind to make the right decisions.

It's great to hire people who self-start and need no guidance.  Most of us, however, need a little nudge.

Clean code = clean hands

Here's a situation you surely have seen in the past:

You're building a new app, and your code starts out pretty uniform.  You follow some basic coding conventions.  You need to bring in another pair of hands, so you hire someone.  He does good work -- but all his code completely ignores the existing coding conventions. You've prodded him about coding conventions, but to no avail.  Now you've got database columns of TradeId in 5 tables, but trade_id in his new table.

What do you do with this guy?  Like I said, his work is otherwise good.  There's a good chance that a replacement would not be as good as him.  In baseball statistics, you'd say he has a solid VORP.

Do you micro-manage him?  Make his life hell?  Or, on the other hand, should you just accept this flaw as part of the package?  Perhaps his brain does not accommodate thoughts of coding conventions, and to impose it would greatly affect his productivity.  Some people could be like that.

Code reviews might catch these kinds of problems.  But, every place I've ever worked had such extreme deadline pressure that code reviews always got chopped.  I don't think they're a long term solution.

Perhaps a code czar can be appointed to to make sure all code fits in with the master plan, like George Lucas does to ensure consistency in the Star Wars canon?  Almost always, such a czar is disdained by the other coders, or gets carried away and becomes a bottleneck.  People you'd want to have in that role smell the no-win nature of it and avoid it.

My usual solution has been to prod as much as possible, using all the motivational tools in my belt, but ultimately letting it go if that all proves useless.

But, today I witnessed something that totally changed my mind.  This event had nothing to do with code.

In the bathroom, someone was in the stall doing their thing, using the toilet paper.  As I was washing my hands, this person came out of their stall and then proceeded to walk straight out to the work area. 

Yes, I was disgusted.  I was also shocked, because this person was a fairly high member of the department, and known to be a good guy, excellent worker, etc.  I don't know if I can look at this guy the same way now.

Strange mind that I have, I immediately related this to coding conventions. 

Would I eventually get rid of someone who consistently refused to wash their hands after, you know, using the toilet paper?  Absolutely.  Social pressure should work (and probably would in this case).  But if he didn't, he's gone.

You might argue that clean code is not as big a deal as clean hands.  But, as far as your code is concerned, it is.  If one person's code sticks out so clearly, then he's creating a bigger problem.  Like a virus, it will indeed degenerate your code into unmaintainable, unreadable goop.

Clean code = clean hands.  This basic level of social behavior and decency should be expected.  There's no excuse for doing otherwise.

Marshmallows predict coding skills

Have you heard about how marshmallows can predict SAT scores?

A study done in the 70s tested the self-control of 4 year-olds. Each was left in a room alone with some marshmallows they were told not to eat until the researcher came back. Some kids couldn't even wait a minute before caving in and eating the marshmallows. Some covered their eyes or looked away or kicked the table. The more self-controlled kids waited over 15 minutes.

Thirteen years later, the researchers looked at these same kids' SAT scores. Those who waited longer had, on average, better scores by a couple hundred points than those who caved in quickly. The marshmallow predicted SAT scores more accurately than IQ tests that the kids had taken. Kids who demonstrated weak self-control with the marshmallows as 4 year-olds also experienced more behavioral problems.

I read about this research study in a few books, and I always interpreted it simply as a lesson about the importance of self-control, which is how the authors present it.

But here's an important factor that I just realized: the successful kids didn't just show self-control. They didn't sit and stare at the marshmallows and then demonstrate amazing willpower. They knew they'd be weak, so they took actions (covering their eyes, doing something else) to help them focus on the correct things (or, more accurately, not focus on the wrong thing).

Many times in software development, we rely on self-control to do the right thing. "After you code, refactor and clean it up." "While you're testing, make sure you come up with all the business cases."

The coding is treated as the main piece of business, and then when that's done, the developer should demonstrate amazing willpower, push through their fatigue and relief at finishing, and focus on quality.

Instead, we should know that we're weak, and make sure the focus on quality is built deeply into our routines. Practices like automated builds, daily production-quality check-ins, TDD help us address the important aspects of functional and structural quality, while eliminating the need for willpower.

Similarly, if certain activities make you less productive, don't just rely on personal determination to avoid them. Address the problem directly. If checking your email is a big distraction, then decide you will only do it once every half hour and set an alarm. Same goes for your blackberry. Most managers will readily accept any reasonable work pattern as long as you let them know, especially as your intention is to improve productivity.

Backgammon and good code

I'm not yet done with How We Decide, but this example of deliberate practice jumped out at me.

Robartie didn't become a world champion just by playing a lot of backgammon. "It's not the quantity of practice, it's the quality," he says. According to Robertie, the most effective way to get better is to focus on your mistakes.

You might recall that deliberate practice appears in Talent Is Overrated as the key to high performance. Focusing on one's mistakes reminds me, again, of Test Driven Development. I'm not a TDD nut -- I have never personally worked on a devoted TDD team -- I'm just pulling these threads together. TDD focuses on your mistakes before you make them. You'll still make some, and so your TDD gets better and better, along with your results and productivity.

This sentence also struck me:

After a few years of intense practice, Robertie had turned himself into one of the best backgammon players in the world. "I knew I was good when I could just glance at a board and know what I should do," Robertie says. "The game started to become very much a matter of aesthetics. My decisions increasingly depended on the look of things, so that I could contemplate a move and see right away if it made my position look better or worse."

I have long believed that good code is clean code, exemplified by Joshua Bloch's axiom that good code reads like prose.

Concern for aesthetically-pleasing code strikes some coders as just unnecessary housekeeping chore. But I think programmers who consistently produce solid code write clean and organized code as a matter of routine. And those who don't do it routinely, but have to go back after the fact and clean things up, maybe refactor a bit, will improve over time and eventually get to the point of routine. It no longer becomes a chore, but just a standard way of doing it.

The counter-argument is a whistle-clean, beautifully modular code that fails miserably at what the users wanted. That's actually a different problem: bad communication or bad specs. But I bet that code did exactly what the programmer wanted it to do.

Pair programming vs autonomy

Pair programming has gone mainstream when you can read about it in gory detail in the NY Times:

Once two of our programmers had a falling out over a keyboard function. The navigator wanted to remap the caps lock key as a control key for when they switched roles.

Nothing ground-breaking here, but an example of the article's detail -- pretty geeky stuff. Soon, we'll be able to talk about the pros and cons of it with our parents.

I've never worked in a pair programming shop, and have always been suspicious about how well it would work.

My basic suspicion about it boils down to this: Dan Pink argues forcefully that the future of workforce motivation for creative professions involves granting lots of autonomy -- including locational and temporal. His argument is pretty convincing.

If people should be given the ability to choose their own work hours and location, how can pair programming survive?

Other agile practices can be constraining also, such as the daily scrum or a physical Kanban board, but none as deeply as pair programming. These guys have a daily 9 am meeting where they figure out who they'll work with and, presumably, what they'll be working on. Then they adhere to a fairly strict work pattern -- 25 mins on, 5 mins off.

The writer indicates all participants are pretty happy about it. I liked this article particularly because he went into such detail about their implementation at a personal level. Indeed, it sounded inviting to me.

But, I can't both be a fan of pair programming and also Dan Pink's research on motivation, can I? They seem inherently at odds.

A different kind of software virus

Turns out if your friend's wife starts putting on more pounds, chances increase that you will too, even if you never met her:

A Framingham resident was roughly 20 percent more likely to become obese if the friend of a friend became obese — even if the connecting friend didn’t put on a single pound. Indeed, a person’s risk of obesity went up about 10 percent even if a friend of a friend of a friend gained weight.

Same pattern occurs for other behaviors like smoking, eating healthy, feeling happiness, etc. Behavior spreads like a virus, like a germ.

The conclusion remains controversial, but it makes sense intuitively, which explains why most of the scientists in the article say things like, "It's still being researched, but I believe it."

It's the same reason why we believe:
* senior managers should effuse optimism at all times.
* a good worker put in a dead-beat group will soon become a dead-beat.
* a co-worker's problems at home will affect the workplace; as a result, people are very hesitant to hire someone having personal problems.
* one bad apple can spoil the barrel.

It also means that if you are following good coding practices and doing great work, but find yourself surrounded by sub-par quality, your efforts will raise everyone else's game. Of course, odds are that you will be affected negatively -- infected, as it were -- but now that you know that, you can focus on preventing that. A little like washing your hands frequently.

Metaphor of the day: antibiotics and software bugs

If you assume your app will have bugs -- a wise assumption, I would say -- how should you respond? Hire a lot more debuggers? Budget longer testing cycles?

As a metaphor, ask yourself this: if we assume everyone gets sick, what should we do? Invest in researching stronger drugs? This post argues that doing so may solve the short term problem, but makes things worse in the long run:

[Modern medicine] tried to deal with a too-fragile system by killing bacteria. Bacteria, like financial bubbles and fads, are part of life. We need to make our bodies more robust to them. Fermented foods do that. By killing off bacteria inside our bodies, antibiotics do the opposite: Make us even more fragile.

Eating healthier (this doctor suggests specifically fermented foods) is a systemic, pre-emptive effort to minimize the effect of getting sick.

When I read that, I thought, "Agile processes!"

So much of Agile practices are oriented to creating systemic, preemptive efforts to minimize the risk of bad code. The aim is to stop bad code is stopped at the door, when it's cheap. Automated builds, automated tests, daily scrum -- the list goes on -- all work together to create a robust ecosystem that produces good code.

Agile doesn't have a lot to say about the actual QA cycle, except in how it impacts development. That's not an accident.

It's no surprise that the metaphor is apt. A software application is an organic, breathing thing in many ways.

Swimming is Agile

I've now swam 1 mile -- 32 times up and back in a half-Olympic sized pool -- 3 times in the last week. Today I realized that I organized my swimming routine iteratively: each set builds on the last and accomplishes something new.

1. 5 laps doing the breast stroke (aka frog kick) with little effort. The main point is to limber up.
2. 5 laps doing the breast stroke with effort.
3. 5 laps doing the crawl (aka freestyle) with only leg effort. I keep my fingers separated to minimize any temptation to pull and don't do any reaching with my arms, focusing totally on leg technique. Some people use a kickboard for this kind of practice, but I'm too lazy to stop.
4. 5 laps doing the crawl with leg effort and arm technique. I add arm technique, but my arms don't really do any pulling, just go through the proper motions.
5. 5 laps doing the crawl with leg effort and arm pulling. This might be called real swimming.
6. 5 laps doing the crawl with leg effort and fast arm pulling. My arms are a blur (I like to think), pulling non-stop.
7. 2 laps of my choice: either continue with the crawl or backstroke.

Two advantages become apparent. First, the last two laps are a freebie, even though they're not; the fact that I choose keeps them from being a chore. Second, breaking it up makes it feasible; if I started on set one and had to count to 32, the goal would be too far ahead to mentally grasp. I can count up to 5 comfortably. I never, ever think during my 5th set, "Wow, this is my 25th lap!"

Note that I didn't plan it that way. Before I reached a mile, I had similar divisions, with fewer laps.

Perhaps iterative development infects everything you do, or some people just think that way.