Zach wrote at 12/14/2012 1:58 pm:Gmail wasn’t entirely developed and thought out with Paul’s 20% of free “tinker” time. Read:
http://books.google.com/books?id=oFTYD9IHX5YC&pg=PA161&source=gbs_toc_r&cad=4#v=onepage&q&f=false
| « Improve Your PHP Development Skills | In Further Defense Of Avoiding Private Methods » |
Years ago, I worked for a company that had a strictly governed bug fixing process. The bugs to be fixed per release were specifically regimented, right down to the amount of hours available to fix each issue. Developers were expected to meet or beat their estimates, and failing to do so meant overtime (since the deadline was immutable). With effectively every working moment spoken for, there was never any free time for innovation, invention or creativity (at least on the schedule). Developers were effectively bug fixing or feature building machines, with no input into the process or product features.
Unfortunately, this seems to be an all too common trend in the development industry. Employers, who love the ability to measure things, disdain the fact that engineering is first and foremost a creative art, that cannot be effectively measured. They attempt to install artificial measures of productivity like tests written, lines of code added, bugs solved, and number of bugs reopened by the quality assurance team. Sadly, these measures all fail to effectively measure the effectiveness of development teams, because the developers themselves see immediately through the schemes, and learn quickly to game the system.
Years ago, Google famously took a different approach, offering their engineers 20% of their time to tinker, innovate, invent, and otherwise work on something besides their assigned work. The results have been tremendous: most famously Gmail was invented this way. Other companies have since copied this innovation from Google, figuring, “if it worked for them it could work for us.”
More companies should embrace the philosophy of allowing time for innovation and creativity. Because engineers are creative by nature, they are going to want to utilize that creativity and innovate. No explicit company policy is necessary to foster creativity and innovation: on my team at Mozilla, we are encouraged to experiment and learn; there is no penalty for doing so, and there’s rarely a hard deadline. When there are hard deadlines, we often leave time afterwards to go back and incorporate the new innovations we wanted to include, but were unable to complete within the time constraints. This both fulfills the business need to release features quickly, and allows for the creative juices of the engineers to flow.
The truth is, no metrics program is ever going to be effective at stopping your engineers from taking the time to innovate; it will only teach them to game the system and ultimately cost you good engineers. Blocking their time out based on bug fix estimates or requiring a 90% billable week (which is absurd since it leaves only 4 hours for the other tasks a developer must undertake, including rewriting code that was poorly conceived or reworking features that were not spec’ed) only forces the innovation underground. In the job I had that blocked my time down to the number of hours for each bug to be fixed, when faced with a section of the code that I knew needed a rewrite but being told a rewrite wasn’t in the time budget, I did it anyway. I directly disobeyed my boss and rewrote the code, knowing that the innovation I was implementing would be better than trying to patch a broken system. It turned out that I was right: my rewrite fixed numerous bugs that had plagued the product from launch. The improved quality was lauded by everyone in the organization (and my boss took credit, even though my boss didn’t know why it was better). But I could never tell my boss what I did, and I left the company soon after.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 12/14/2012 at 7:00 am
Gmail wasn’t entirely developed and thought out with Paul’s 20% of free “tinker” time. Read:
http://books.google.com/books?id=oFTYD9IHX5YC&pg=PA161&source=gbs_toc_r&cad=4#v=onepage&q&f=false
Sorry, I just read my comment again and it sounded rude – no rudeness intended. I just wanted to correct the story about Gmail, but I completely agree with the point of your post. If I ran the world, everyone would have “tinker” time to work on the things they want to work on.
Brandon Savage (@brandonsavage) wrote at 12/14/2012 9:51 pm:
No worries. I realize that my statement is an oversimplification of how Gmail came to be. The point was to encourage innovation. I haven’t read the book but I wonder if Gmail might exist had it not been for the work that was done in the 20% time. We may never know.
| « Improve Your PHP Development Skills | In Further Defense Of Avoiding Private Methods » |