Xeno's Paradox and Software Delivery

Achilles
Originally uploaded by Jennifurr-Jinx

The ancient Greek philosopher Zeno of Elea composed a paradox to support his teacher, Parmenides's view of motion and change in the universe. His story is about a race between Achilles and a turtle. The turtle gets a small head start, but before Achilles can overtake the turtle, he must catchup with the turtle. Once Achilles has caught up, the turtle has moved forward, so Achilles must move a little further to where the turtle is now. But by now the turtle is ahead and Achilles must again catchup etc... so Achilles never really reaches the turtle.

I've noticed this same phenomenon in software development with regard to last minute features being requested to be thrown into the release. With three days to go before release, we get a small 4-hour feature request to be added. Then two days before the release another smaller item - really tiny, wouldn't take much effort at all - just two hours. One day to go, and another almost infinitesimally small item to be added - it will just delay the release by one hour and it's really needed.
In Zeno's world, the software will never get released.

Last Night's Lean Software Group Meeting

Not knowing a "Value Stream Mapping" from an old tire (don't think too much about the analogy), I drove down to last night's Lean Software Group meeting at the Overwatch offices to join 27 other people and to try an tease some meaning out of all this Lean hype.
Scott Bellware gave a welcome message.
Andrew Cahoon gave an introduction of VSM and then Gary ? gave a compelling real world example of a Value Stream Mapping.

My notes:
* Value Stream Mapping is more an analysis and planning tool than a prescriptive activity.
* Don't make a perfect model, it's not worth the effort - just get a good enough model to do your work.
* Customers care about Quality, Cost, and Delivery.
* Kaizen is about continuous improvement and Value Stream Mapping is a tool to get to the next level.

15 Helpful Tips from Scott Bellware's Behavior Driven Class

On March 24th, last Tuesday, I attended Scott Bellware's helpful seminar on "Test-Driven Development and Behavior-Driven Development". A few of my take-aways:

1. One bug takes a unit of time to fix, but with multiple bugs the time goes up exponentially since the bugs can interact. Moral: Code in steps and only introduce one bug at a time.
   
2. Ask if the test you are about to write is a valuable test.
   
3. Code-DB impendence mismatch example: If orders have links to customer in the db, in code the customer has links to the orders.
   
4. Using "static" methods between layers is bad, it's like welding the objects together.
   
5. Inheritance is strong coupling, to be used as a last resort.
   
6. Scott and his team removed an entire layer of testing when they realized it provided less value than it took to maintain.
   
7. Databases are places for dead objects, not logic.
   
8. Someone at the meeting said Microsoft doesn't really do domain applications like we do, so they cannot really offer much advice on how to code.
   
9. "Reuse" is not a good goal.
   
10. You can overwrite tests, simple things are tested in more complicated tests.
    
11. Don't use prepopulated databases with test data. Start with an empty database, and end with an empty database.
    
12. When Scott asked the participants "Who does unit testing?" 80% of the 25 people raised their hands. "Who uses MSTest?", one hand.
    
13. Regression tests are a side effect of Test Driven Development, not the primary goal.
    
14. Doing traditional OO analysis (nouns, verbs,...) creates more objects than needed.
    
15. Don't directly expose an object's collections; use helper functions on the object. (Use Customer.Add(obj) instead of do Customer.list.add(obj))
    
    

PeopleWare by DeMarco and Lister

I've just finished reading Peopleware by DeMarco and Lister and have put it on my Recommended Reading list. Buy one and read it.

This is a great book, it's 20 years old, but still relevant. I thought the highlights were these:

1. Projects fail not for technical reasons, but for sociological reasons.
   
2. Our successes stem from good human interactions, not from incremental technical improvements.
   
3. Making errors should be encouraged - everyone should have a few mistakes during the project when we tried something and it didn't work. When the answer to "How many mistakes did you make?" is "none"; that's a bad sign people aren't trying enough new things.
   
4. We need people who make the team "jell" - they are worth more than coders.
   
5. We spend too much time trying to get things done, and not enough time asking if the thing is worth doing.
   
6. People really like to make very high quality stuff, but the market wants high quantity.
   
7. Parkinson's law, "work expands to fill the alloted time", doesn't apply well to software developers.
   
8. Beware of claims to increase software productivity by 100% because most time is not spent programming.
   
9. When testing productivity of programmers, some were 10 times more productive than others. This is not quite what it sounds like since not all a person's time is taken with programming.
   
10. During "programming games", language did not affect the outcome (except assembly language) and experience didn't matter (if they had more than six months experience).
    
11. Quiet places for work are extremely important to allow programmers to get in the "flow" of their work. (This agrees with Joel Spolsky, but not the Agile wing of development).
    
12. Corporations have entropy. Differences, and creativity, in departments are slowly ground out of them to create a flat, bleak landscape of sameness.
    
13. Big Methodologies don't work; better to use training, tools, and peer reviews.
    
14. Fujitsu encourages all projects to do some aspect in a nonstandard way.
    
15. Letting teams strive for less than perfect quality is the "death knell" for the team. Teams really want to do high quality work.
    
16. "Sociology matters more than technology or even money."
    
17. Overtime is destructive and counter-productive.
    
18. People hate change. We are agents of change.
    
19. Try to keep people on one project at a time, not spread over several at one time. They are less efficient and more frustrated.
    
20. Don't waste your peoples time in meetings and overstaffing projects early.
    
21. Create a fun, creative, productive team environment - somehow.
    

Their recommendation for having quiet offices struck me. As a result we got the loud cell phone in the office turned down and I bought one of my people, who is affected by the noise, some noise-canceling headphones to see if that would help with the noise. It didn't.