Saturday, July 30, 2011

The geekiest CAPTCHA ever

I ran across the geekiest CAPTCHA on Adafruit Industrials blog.  Thought I'd share.


CAPTCHA an acronym: Completely Automated Public Turing Test to Tell Computers and Humans Apart.  A good article on the invention in 2000 of some of the fist.

For me, just seeing a resistor brings back a rhyme from 9th grade electronic class that runs in my head uncontrollably.

Bad boys rape our young girls but Violet gives willingly

A mnemonic for the resistor color code that matches the first letter of the color code, by order of increasing magnitude.

Monday, July 25, 2011

How to launch a corporate Agile library

One simple initiative each Agile Transformation can make is to create a book lending library focused on Agile processes, organizational change, learning organizations, best engineering practices in software development and other topics.  Since this topic of "what books would you recommend" comes up quite a lot, perhaps it is time for me to join the ranks of hundreds of people making their top 10 Agile books list.



Top 100 Agile Books (Edition 2012) by Jurgen Appelo

But no that's not what this post will be.  It is something much more useful.  Instructions on creating your very own lending library.

  1. Get funding - about $1000 for the first quarter.
  2. Find a book shelf and a reading room with comfortable chairs.
  3. Purchase 3 copies of each book on the short list - these books are the seed stock.
  4. Make a company logo sticker for the back of each book and inside cover.
  5. Make signs and hall way posters to advertise your new library.
  6. Make a book list to hang on the wall, listing all titles, authors, and number of copies.
  7. Upon arrival of a majority of your new (used) books - sticker the spines and inside cover and place them on the shelf.
  8. Open the library - send email, put up posters, invite people to read your books.
  9. In one month look at the shelf - compare it to the book list - purchase more of the books that are missing from the shelf (celebrate - they are being used).
  10. In month number two - send out a reminder email, and posters in the hall to return the book after they are read - give someone else a chance to enjoy such wonderful knowledge that has just been collecting dust on your night stand.
  11. In month three, work up a new list and purchase more books.
  12. Repeat until the whole organization knows everything.
I am constantly amazed at the looks I get from managers that can't image a lending library without a complicate check-out procedure to insure we get the books back.  I remind them that these are our trusted employees.  The ones with the keys to the client's kingdoms.  The same employees that could launch Thermonuclear War with just a key stroke.  So maybe we can trust them to return the books.  And hey, if they forget, then it cost us a few dollars to educate them in some new technique.  Compare that cost to sending them to a training session that they are planning to take their phone and TXT with their BFF the whole time.

Some further recommendation:
  • purchase used book - many great books have been in print for a while
  • don't worry about returns - consider it a bonus plan for employees that can read
  • add a wish-list to your book shelf
  • add a donation can to the shelf - to defray the cost of forgetful patrons
  • add a list of YouTube video links, and other resources on paper
  • add a general reading shelf - give-one & take-one shelf
  • don't forget the differenator between the library and the book store - comfortable sitting & coffee
  • see also: http://littlefreelibrary.org 
Here's a short list of Agile books to add to the library.

Or just buy any book on the Pragmatic Book Shelf.

Methodologies and Principles
Development Practices
Management and Other Practices

Sunday, July 24, 2011

Camera lens are getting cheeper

I have always wanted a Canon Pro Lens, one of those white and black lens that sets the serious photographer apart from the amateur.  A few years ago I rented one for an Alaska cruise we did.  Hoping to get images of big horn sheep or bear - something one typically needs a long lens to capture.

In actual practice the people with the regular lens got as good of images as I did with the super fast long lens.  Why - because they could find the target faster with the wider angle.  When I started thinking about this, it made me question the need for a 35 mm camera.  Would a typical point and shoot give me just as good vacation photos for the scrap book or slide show?

I tested this primise out on a European vacation.  I carried the pocket sized point and shoot Canon Power Shot SD1100 IS (8 Mpix with image stabilization).  While my wife carried a Canon 20D (35mm with various lens).  We shot many of the same scenes and typical tourist images, and while it is possible to see differences in the images upon inspection.  All the finner details are lost when the image ends up in a iMovie slide show and the Ken Burns effect pans across the image in 4 seconds, then transitions to the next slide.  However the different camera solutions are telling in the candid photos sitting around the table in a cafe, or standing around a town square of the images of "Man on a Horse" or "Pigeon on a Statue".  The small form factor of the pocket camera makes for easier capturing of these images and situations.  This is a large advantage for this solution.

Imagine the advantage of an ubiquitous camera solution by putting the camera in a cell phone (the iPhone rocks this solution) and the days of the amateur with a 35mm and a pro lens are all but gone.  There is no need for that pro lens unless you get paid for images.  I don't get paid for images.  So in fulfilling my childish needs - I bought a Canon Pro Lens coffee mug.

iPhone image of a fleeting moment at sunset, no time to run get the big camera.


Now I can look like the serious photographer, drink my coffee and pull out my iPhone for that candid shot without any scene prep time required.  I'll be able to get rid of this expensive setup.


So where is the value in the camera lens solutions?  Having a set of interchangeable lens is a great solution to one problem.  When you want a photograph it might be the wrong solution, the great solution that is in search of the problem.  Will this solution allow for a disruption solution to sneak into the industry or eco-system.  Perhaps a camera made into you cell phone.  Is a camera in the hand worth a wide angle lens and a telephoto lens in the bag?  If you manage a product or product portfolio you may want to think along these lines from time to time...  What is the alternative product to your baby?


No test - inconceivable. Not Technical Debt.

Technical Debt

The software term "technical debt" is getting a lot of play on the air waves.  But I do not think we are using it the way Ward was when he invented the term (a metaphor) to explain to his buisiness team why creating software fast to get feedback was a good thing.  But that they had to be willing and able to sustain a pace of repayment on the debt of doing just good enough design to get product feedback.  Their form of repayment was constant refactoring.  Always keeping the software model moving toward the best possible business model, which modeled the real world.  Using many XP practices to enable the repayment plan of the debt they were consciously assuming.

In this vain, technical debt does not cover the process of writing bad code, of poor design, of skipping steps (such as testing).  Those behaviors would be considered to be incompetent design and implementation.  That behavior results not in debt at all but a breach of the inherent contract between development team and the business. The warranty of merchantability.


The warranty of merchantability is implied, unless expressly disclaimed by name, or the sale is identified with the phrase "as is" or "with all faults." To be "merchantable", the goods must reasonably conform to an ordinary buyer's expectations, i.e., they are what they say they are. For example, a fruit that looks and smells good but has hidden defects would violate the implied warranty of merchantability if its quality does not meet the standards for such fruit "as passes ordinarily in the trade".

This industry (software development) is deceiving its customers and pass off bad products as if they just have a little bit of debt to be repaid.  As if the product was a 3 year old car with a 5 year loan.  One purchases the car and the debt.  But I suggest that is not the same thing as purchasing software the has been created in such a poor fashion as to have no unit test, or no acceptance test. Little if any way to become the application it appears to be.  A car on the outside but with a faulty electrical system, blown engine, and bad transmission, but really good tires and paint.

A case in point - a team wishes to upgrade the compiler that produces their application.  They have little to no tests for the application - it just works.  They then ask for a test group to provide the effort required to prove that the compiler upgrade doesn't cause any bugs.  I do not think one can pass off the warranty of merchantability to the test team and expect good things to come from this - pass the hot potato behavior.  This is not technical debt - it is incompetency - it is inconceivable.

"You keep using that word. I do not think it means what you think it means."
-- Inigo Montoya


Ward Cunningham on the creation of the "Technical Debt" metaphor.


I think we keep using the phrase technical debt - but it doesn't mean what we think it means.  Technical debt means a conscious decision to defer up-front design and research in the product development, in order to get to market with a model that is capable of becoming the the desired solution, and capable of eliciting the customer feedback that we desire, which proves that the product is evolving in the proper direction.  And provide return on investment earlier.

See Also:

A Technical Debit - Collateralized Debt Obligation you should not invest in

The SQALE method is particularly devoted to the management of the Technical Debt (or Design Debt) of software developments. It allows:
  • To define clearly what creates the technical debt
  • To estimate correctly this debt
  • To analyse this debt upon technical and business perspective
  • To offer different prioritisation strategies allowing establishing optimised payback plan.
Managing Software Debt - by Chris Sterling