Gp's AudioBook Review

My Review of Mindsight by Daniel J. Siegel. Read by the...

Tue, 20 Dec 2011 03:51:57 -0800

My Review of Mindsight by Daniel J. Siegel. Read by the author.

Great By Choice by Jim Collins and Morten T. Hansen. Read...

Mon, 07 Nov 2011 12:28:51 -0800

Great By Choice by Jim Collins and Morten T. Hansen. Read by Jim Collins.

[Off-topic] On Agile

Fri, 04 Nov 2011 06:34:00 -0700

I don’t know why this article by Mike Gualtieri infuriates me (http://blogs.forrester.com/mike_gualtieri/11-10-12-agile_software_is_a_cop_out_heres_whats_next). Is it the fact that this guy is an analyst who has never run a software development shop? Is it because all of his information is second and third hand? Is it because he is right in some respects? Of course the rhetorical answer to all these questions is, YES.

Let me start by saying Agile can work, I know this because I have made it work. My experience of 1 is very biased. But the fact that I have a counter example means that Agile works… BUT, and there is a big one, I have never done scrum or XP. I have done agile development for over 5 years but I have never done a prescriptive version of any agile process. And so I have a problem, on one hand I cannot say that agile works because frankly we cherry-picked the best aspects and threw away the others. I can’t say that agile doesn’t work either. So let me describe the process we ran and then my insights on what I think actually works.

1. Everything is the context of the user
It is way too easy to take a technology and map it to the user needs. The flow needs to go other way. The user needs something and you build the product, the architecture, the user interface around making the users ability to solve that problem as effortless as possible. When every conversation you have is in the context of the user the flow moves so much better. Engineers begin thinking of the user more naturally instead of focusing solely on the technology which they are totally immersed into on a day to day basis.

Designing the user experience from the beginning is the point of what we are building. BUT at the end of the day the code accomplishes the goal. There are engineers out there who will shy away from the “hard” stuff because it is hard. My team has constantly heard me say to them “I don’t care if it is hard for you if it makes the users lives easier. We do the hard stuff so they don’t have to.”

You get here by doing a few things:
- Hire designers or developers, testers, documentation people with an eye for user experience design.
- Have detailed and rich conversations about the users problems before you start any project. Understand every nook and cranny of the user and their context and their problems. You will need this later.
- Design the final product based on all the current assumptions… although they will be wrong. Keep it flexible and light.
- Prototype to find the flaws with the design.
- Iterate the design (this is the one anti-waterfall/pro-agile item)

I have not had all these things all the time in my projects and the results have always shown. Every time we include these aspects we see the benefits. I am sure there is more, but a lot of teams don’t even have this much.

2. Conversations and right-sized artifacts
One aspect of agile that is key is collaboration over contracts. In software there are still companies who create contracts between management and the engineering team to deliver the requirements. And you get exactly what you asked for, what the requirements stated. In a 6 month project the amount of requirements is so fast and the interplaying complexity so intense that it takes almost 6 months to nail requirements that will still be wrong in the end. This relates to something called the Cone of Uncertainty. Basically the larger the project the more unknowns and the more uncertain you are of the timeline, quality, and resource requirements. This is true in any project whether you are building a highway across three towns or building a complex piece of software.

So your requirements are wrong, and the bigger the project the more wrong they will be. Your estimated level of effort required to achieve a specific level of quality is wrong and the longer the project is the more wrong it will be. I have lived these facts in every company I have worked in, whether it was my project or someone else’s.

Agile has the most elegant answer to this, although simplified beyond what Mr. Gualtieri is comfortable acknowledging. Working software over comprehensive documentation. Paired with the collaboration over contracts value we have a powerful concept that is best summed up as conversations and right-sized artifacts. This flows directly from #1 too.

When you are with the engineering team and you are discussing the customer in excruciating detail it is important to write that stuff down. Whether you have a formal documentation called an MRD, PRD, User Stories, Scenarios etc. or some other less formal approach, every topic discussed and planned as part of the conversation needs to be written down in some form to remind everyone about what was discussed. This is as much as is necessary because you will talk about it again in even more detail when it comes time to actually implement the item.

At the time that you actually implement the item there is always going to be new information that will change assumptions in the item you originally wrote down. There is a new context. When you got to implement that thing you must discuss the new context and write down the new assumptions so that you are always working against a set of requirements that has the best knowledge baked into it.

Last, in direct opposition to Mr. Gualtieri, working software is a measure of progress. However, that doesn’t mean you are done. Even though the software works it may not be what you wanted. It may not work right even though it matches the careful designs perfectly. It may be flawed in ways you didn’t anticipate. So throw it away and do it again. This happens, you didn’t mess up, it’s part of the creative process. The willingness to throw away working code is as important as getting working code.

3. Regular check-ins
This one is pretty much a follow-on from #2. If you throw requirements over the fence you are going to get exactly what you asked for… but not what you want. It is important for any product owner, product manager, customer, business analyst, etc. to regularly check in and get demos of the software. This is where sprint-boundaries help. It is a mutually agreed upon time where the non-developers get to but their noses in and help steer the project.

This also means that outside of those boundaries you need to leave the team alone. A well put together team can go for a few weeks without direct monitoring. Giving them time to think and put together their best ideas. The middle of that process can show some pretty ugly children of the mind, but the boundaries are when they show off something they are proud of. Like an artist, you want to see the painting when it is done, not when it is being painted. Anyone who has watched Bob Ross has seen him take his paint knife and ruin a painting only to make happy little trees or mountains. But man do you get nervous on that first swipe of the knife. Step back and let the artist do their work. If they are a good team they will give you something beautiful. Just don’t let them do the entire Sistine Chapel without checking in every few weeks.

4. Finish before you start
The worst software projects I have been on are the ones where too much stuff is going on in parallel. It is by far the buggiest and hardest to integrate when so many things that are interrelated are always in flux. A great engineering team will find the right ways to split the project into parallel and serial streams of work. Within each parallel stream there will probably be a mini-serial stream of work. Before a team goes off and starts something knew they should complete the current work as fully as they can based on the requirements. There are different ways you can approach this and the situation will call for the right thing, but there are some successful tricks my teams have used in the past:

- If you are building a broad API for a group of features. Do it in parallel with 1 of those features and finish them together before working on the next feature that uses that API.
- Database changes always come first
- Multi-sprint items need to be cut up to achievable milestones within the sprint boundaries
- Done means: design, code, unit tests, and functional tests are all closed
- Bugs stay flat or go down from sprint to sprint
- Automated tests increase and the pass rate is as close to 100% as possible

This list is not exhaustive and I have other tricks very specific to the projects that I have worked on. To use a hiking analogy, “you always move from water and not to water.” If you have ever been hiking in the Grand Canyon you will understand this. Every time you move from a stable (or at least known) state to another known state then the in between is not so hard to deal with. If the code base is entirely unstable from sprint to sprint you will find that the end of the project is a very hard road with lots of late nights and emergency re-dos of code. Keeping the bug count as small as possible and automated test case pass rate on an increasing trajectory on the boundaries keeps everything in check. When you move from water, you can always go back if you need to.

5. Minimizing the Test-Dev progress delta
This is the hardest thing in all of engineering. There is always a tendency for development to run ahead and put together tons and tons of code and then leave it on the testing team’s doorstep. This approach will and has always failed. To finish something you need it to be fully tested. Without that, the state is frankly unknown and unstable. Having lots and lots of code in that state is bad. So the dev progress should only be slightly ahead of the test process. In Agile they would say it should be totally in sync, but in practice that is never the case. Test and dev have a back and forth and a natural order that falls into line the same way in every team I have been in. TDD and BDD are great goals but I have seen great software come out of teams that have not followed that practice.

When dev and test are separated by entire sprints or entire milestones, that’s when things get squirrely. The closer you can keep the dev and test work together the higher the code quality on a day-to-day basis. You will move much faster with a tested, bug-free code base then you will with a code base that has a ton of features that haven’t been tested.

6. The team doing the process decides the process
The very last item is the kicker. The team is ultimately the judge of the best process to use. In other words the process needs to be tailored to the needs of the business rather than the other way around. When a team is forming for the first time it is good to use a text book version of a process to get going. But continuous improvement determines that it will not be in that state forever. To get better you need to have a process that works for all the teams involved. You need to have a process that works for the management team, the product managers, the engineers, the testers, the documentation team, the support team. The process doesn’t begin or end with engineering.

The process cannot be handed down from on-high. This gets into the same problems as #2. The assumptions will be wrong. You need to analyze the process and the users of the process as much as you would for the users of the product you are building. Mr Gualtieri came up with his PISS paradigm (which he could have made IPSS if he wanted to), but he is wrong, and scrum is wrong, and XP is wrong, and waterfall is wrong, and feature crews are wrong, and my 5 points above are wrong. They are all wrong for anyone but the people who created them. The process that works is the one that works, not the one in the text book.

Here is my advice. Find a process you think would work for your business. Apply it by the letter, then improve it rapidly at first, maybe even throwing it out entirely and starting again with something else. Once you find the one the works, improving it on a regular interval. Be empirical about it. Make improving the process as much a part of your business as building great products.

An interesting sci-fi book by John Scalzi and read by Wil...

Mon, 31 Oct 2011 03:55:00 -0700

An interesting sci-fi book by John Scalzi and read by Wil Wheaton.

Review of The Game of Thrones, the first book in The Song of...

Sun, 23 Oct 2011 03:50:26 -0700

Review of The Game of Thrones, the first book in The Song of Fire and Ice series by George R.R. Martin. Read by Roy Dotrice.

My Review of Spark by John J. Ratey and read by Walter Dixon.

Sun, 03 Jul 2011 20:09:00 -0700

My Review of Spark by John J. Ratey and read by Walter Dixon.

Review of Echoes of Honor by David Weber. Read by Allyson...

Sat, 25 Jun 2011 07:06:00 -0700

Review of Echoes of Honor by David Weber. Read by Allyson Johnson. The 8th book in the Honor Harrington series.

[Off topic] 24 Hours Later: Switching to android

Thu, 26 May 2011 20:46:54 -0700

Phone: Samsung Nexus S
Carrier: Rogers

I just had to write a post about this. I have heard the theoretical arguments for so long that I wanted to give the practical. Instead of discussing what feature gaps there are between the two, which is exactly how everyone else approaches, I am going to discuss the usefulness of the differentiating android features as well as the things that annoy me since I am coming from iPhone.

Why “Open” is useful:
- It lets you customize the crap out of stuff.
- Download whatever you want, at your own risk. No parents watching over you.

Why “Curated” is useful:
- Way easier path to find things. iTunes, App Store.
- Better protection from rogue apps. I noticed that I wasn’t paying attention to the services that apps were using when I installed them on android. I am sure I am not the only one.

Differentiating features for Android and how they play in my day-to-day:
Flash - Doesn’t play at all. Haven’t even installed it yet.
Widgets - Meh, interesting and fun. Not useful. Why is there no gmail widget from Google?
“Open” - Since I a tech savvy I enjoyed the fact that I could download custom apps like swype off-market. But I can feel the danger of the system immediately. I would never recommend non-technical people to do this kind of thing.
Device Choice - This was nice. For $99 I got a relatively new Nexus S whereas 279 would have bought me the 1+ year old iPhone 4. This ultimately was my buying decision criteria.
Google integration - This is spotty and I might say dreadful. Android and Chrome don’t sync bookmarks. Tell me that doesn’t look like an internal battle between the organizations. Sure Calendar, Mail, and Contacts sync but that isn’t different than the iPhone.
“Real” multitasking - I don’t know how people stand behind this “feature.” It is just another thing that the user has to track and maintain. I would actually say that this is deficiency. People don’t want to manage things, believe me I work in the management software business. Application state should be automatically managed. Rogers recommended to download an app like Juicedefender which does the management for you, seems like Google missed a feature that people need.
Switchable keyboard - I use swype now. Swype itself could be better, but the potential is great.
Built in Navigation - Very useful. I want to buy a dock to take better advantage of this.
Extra hardware buttons (Back, Menu, Search) - I am still having a hard time switching my brain from the iPhone way of doing things. Menu button I think is just bad design.

Things that bug the crap out of me about android:
Mac integration - Doesn’t work out of the box with iTunes or iPhoto. Very painful… very very painful. iPhoto especially.
Hands free calling - Anyone who claims that what android “offers” in the way of voice dialing is any good is just smoking something wacky. Every phone I have used ever (feature phone, BB, or iPhone) has done this better.
Browser - Doesn’t respond to taps appropriately. Doesn’t provide appropriate feedback to the user that something is happening (or not happening). I am constantly tapping, re-tapping, hitting the back button, then tapping again.

Thanks for reading.

Review of Making Money by Terry Pratchett and read by...

Thu, 17 Mar 2011 07:33:50 -0700

Review of Making Money by Terry Pratchett and read by Stephen Briggs.

Review of the Upside of Irrationality by Dan Ariely and read...

Thu, 03 Mar 2011 05:29:32 -0800

Review of the Upside of Irrationality by Dan Ariely and read by SImon Jones.
Bonus points for whoever knows the cover of the book I am reading at the beginning.

Review of the Mercy Thompson series by Patricia Briggs and...

Sun, 20 Feb 2011 22:38:00 -0800

Review of the Mercy Thompson series by Patricia Briggs and read by Lorelei King.

My review of Einstein: His Life and Universe. Written by...

Sun, 16 Jan 2011 14:36:00 -0800

My review of Einstein: His Life and Universe. Written by Walter Isaacson and narrated by Edward Herrmann. IN HD!

Updated all my posts with the new Vimeo embed link. Welcome iOS.

Mon, 23 Aug 2010 22:26:03 -0700

Updated all my posts with the new Vimeo embed link. Welcome iOS.

My review of Heartfire by Orson Scott Card. The 5th book in...

Mon, 23 Aug 2010 22:04:00 -0700

My review of Heartfire by Orson Scott Card. The 5th book in the Alvin Maker series.

WHERE WOULD YOU MOST LIKE TO VISIT ON YOUR PLANET?

Mon, 23 Aug 2010 19:32:02 -0700

Tokyo

No Mr. Schmidt, Anonymity is Obvious

Tue, 10 Aug 2010 00:38:00 -0700

In a recent interview with CNBC, Google CEO Eric Schmidt did a poor job of choosing his words and noted “privacy is not the same thing as anonymity.” The head of Google then goes on to describe when crimes are committed that judges will ask that the suspect be unmasked and that the right of absolute anonymity is not obvious. You can see the interview here.

What is unfortunate is that Eric Schmidt is feeding blood to the sharks. Blood being the fear of rapists and murderers being able to hide their identities online while committing horrendous crimes and the sharks being the legislators of the world. Eric Schmidt and Google are driving a political agenda to rid the world of user anonymity.

In a stroke of human of repetition we see the same tactics that have been used over and over in the past, the underlying implication of the age-old phrase “if you aren’t committing a crime, what do you have to fear?” This, of course, is a noble cause with only the truest of altruistic intentions in mind. Google only wants to make the world safe for everybody, while they milk every byte of your information for every advertising dollar that they can squeeze from it.

The trouble is that in the real world, no one is altruistic. No one is trustworthy, especially the government. To force users into a choice of “technological stone age” vs. “no-anonymity” means that the people who fear organizations, that do no not have their best interests in mind, will be left behind. Whether someone believes that local or foreign governments would abuse access to information or Google’s partners and advertisers of ill-repute would build elaborate phishing scams to rip people off of their money. The people who distrust the large machinations of the business and government will be left without a means of communication, without a means of rebellion, without a means of free speech without persecution.

Then there will be people who choose freely the risks of a non-anonymous internet where every move they make could be used against them with fewer safeguards available to them. They will be the bitter bunch. The Tech workers of the world whose job is to be part of the digital world and accept all of its insane and byzantine rules. Even though they enter with eyes open and believe they have a choice, that choice is just an illusion.

And last will be the ignorant. The poor grandmothers who follow a link from their equally ignorant grandchildren to a website that lets them download a movie. Grandma might realize later what she has done and erase the file before viewing it, but it’s already too late. 3 weeks later the police are knocking on the door and Granny is baking cookies for a woman named Birtha for the next few weeks or going bankrupt from the piracy lawsuit. The ease of information flow without requiring warrants to governments and intellectual property holding organizations is too tempting to believe that an automated “safety-net” meant to capture criminals and property rights violators expeditiously will be anything other than inevitable.

The internet is already a hard place to navigate, the information available about any individual is already easy enough for governments and law enforcement to get what they need to prosecute, using old-fashioned and constitution-approved tools such as warrants. Why do we need to relieve the safeguards that keep information from ending up in the wrong hands?

Anonymity is another layer of security that keeps people’s information from being exposed to those who should not have it. Anonymity, embraces, encompasses, and encircles privacy and is both part of it and greater than it at the same time. It is the foundation of freedom of speech on the internet.

Anonymity is the last freedom left in the world where everything is audited, recorded, reported, and kept forever; it should be kept sacred.

Review of The Logical Leap: Induction in Physics by David...

Sun, 08 Aug 2010 21:41:00 -0700

Review of The Logical Leap: Induction in Physics by David Harriman, read by Erik Singer.

Great book for any technical person. Scientist, biologist, programmer, etc.

How about "Croud Love"

Wed, 04 Aug 2010 22:31:00 -0700

Just watched an interesting thought on garyvaynerchuk.com about the word media being the wrong description of the interactions in “Social Media”. I think Gary has a point. The word media isn’t right, it is both too broad and too narrow for what we consider social media and how personal brand’s (like Gary’s) and companies (like Old Spice) are using it to get back in touch with their customers. It’s about reaching out and caring about the customer and being able to reach customers directly while still scaling. This is the power off the tools like Twitter and Facebook and LinkedIn and blogging and … It lets you get at the individual customer at, for lack of a better word “Cloud Scale”. Hundreds of thousands of users, millions, with only a little extra time spent. And at the end of the day it is about that 1:1 interaction. That connection you are making. So since I am an idea guy, and I love making up new words, such as “April F00lz” (look it up in urban dictionary), I thought I would throw out a new term for the socializing that goes on. You are interacting with the “Croud” (no that isn’t misspelled). A large group of people that are only accessible through the tools of social networking. Now you can attach anything after that. So instead of all the things under “Social Media” you have:

- “Croud Conversation”

- “Croud Marketing”

- “Croud Service” (instead of Customer Service)

- “Croud Media” for the stuff that really is media

Just a thought.

Came up with another

ChatterNet

BTW, I am still getting through the current book. Since moving out west I don’t have the 2 hour per day commute, reduced to 10 minutes per day and it is impeding my reading time. I am about 2/3 through the book. Looking to find another venue to get it kick started. Stay tuned.

Awwww yeah, I'm back!

Wed, 14 Jul 2010 14:42:11 -0700

Got my computer back and I got my first audiobook rolling.

The next review will be: The Logical Leap: Induction in Physics

My short hiatus

Thu, 29 Apr 2010 04:27:02 -0700

Hi everyone. I will be taking about 1 month away from my book reviews as I move out to Seattle, WA.

I have two books in the can already and I may write blog posts to make up for them, or try to find a low budget alternative and post video reviews. But my equipment is being packed and there isn’t going to be a way for me to throw out my standard stuff.

I’ll catch you in a month.