Thursday, November 26, 2015

Book Review: "Venture Deals"

"Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist" by Brad Feld and Jason Mendelson is a fantastic book on getting venture funding for a startup or company. As I listened to the book on Audible for $15 (7.3hrs / 240 pages), I took detailed notes as to how the tips apply to my own business and pitch. It's a highly detailed book describing many of the special terms, skills, and documents you needed to successfully secure venture funding for startup groups. This book imparts many important soft lessons as well, such as how to negotiate, reading personality types, and picking which VCs you want to personally work with. This book is for inventors, hackers, entrepreneurs, founders, CEOs, VCs, lawyers or anyone seeking venture capitol in a project. I give 8 / 10 stars as this book really equips you for exact showdown of negotiating venture deals and has great re-read value because it can be so dense. I've decided to include it in my book reviews as I think it fits excellently as an educational text that can help hackers get the most out of a venture funding challenge and because it fits perfect in series with my other inventor / founder / startup book-reviews, The Phoneix Project and The Lean Startup. The following is the chapter listing to help you get a better idea of the contents of the book:

Introduction: The Art of the Term Sheet

Chapter 1: The Players

The Entrepreneur
The Venture Capitalist
The Angel Investor
The Syndicate
The Lawyer
The Mentor

Chapter 2: How to Raise Money

Do or Do Not; There Is No Try
Determine How Much You Are Raising
Fund-Raising Materials
Due Diligence Materials
Finding the Right VC
Finding a Lead VC
How VCs Decide to Invest
Closing the Deal

Chapter 3: Overview of the Term Sheet

The Key Concepts: Economics and Control

Chapter 4: Economic Terms of the Term Sheet

Liquidation Preference
Employee Pool

Chapter 5: Control Terms of the Term Sheet

Board of Directors
Protective Provisions
Drag-Along Agreement

Chapter 6: Other Terms of the Term Sheet

Redemption Rights
Conditions Precedent to Financing
Information Rights
Registration Rights
Right of First Refusal
Voting Rights
Restriction on Sales
Proprietary Information and Inventions Agreement
Co-Sale Agreement
Founders’ Activities
Initial Public Offering Shares Purchase
No-Shop Agreement

Chapter 7: The Capitalization Table

Chapter 8: Convertible Debt

Arguments For and Against Convertible Debt
The Discount
Valuation Caps
Interest Rate
Conversion Mechanics
Conversion in a Sale of the Company
Other Terms
Early Stage versus Late Stage Dynamics
Can Convertible Debt Be Dangerous?

Chapter 9: How Venture Capital Funds Work

Overview of a Typical Structure
How Firms Raise Money
How Venture Capitalists Make Money
How Time Impacts Fund Activity
Cash Flow
Cross-Fund Investing
Departing Partners
Fiduciary Duties
Implications for the Entrepreneur

Chapter 10: Negotiation Tactics

What Really Matters?
Preparing for the Negotiation
A Brief Introduction to Game Theory
Negotiating in the Game of Financings
Negotiating Styles and Approaches 
Collaborative Negotiation versus Walk-Away Threats
Building Leverage and Getting to Yes
Things Not to Do
Great Lawyers versus Bad Lawyers versus No Lawyers
Can You Make a Bad Deal Better?

Chapter 11: Raising Money the Right Way

Don’t Ask for a Nondisclosure Agreement
Don’t Email Carpet Bomb VCs
No Often Means No
Don’t Ask for a Referral If You Get a No
Don’t Be a Solo Founder
Don’t Overemphasize Patents

Chapter 12: Issues at Different Financing Stages

Seed Deals
Early Stage
Mid and Late Stages
Other Approaches to Early Stage Deals

Chapter 13: Letters of Intent—The Other Term Sheet

Structure of a Deal
Asset Deal versus Stock Deal 
Form of Consideration
Assumption of Stock Options
Representations, Warranties, and Indemnification
Confidentiality/Nondisclosure Agreement
Employee Matters
Conditions to Close
The No-Shop Clause
Fees, Fees, and More Fees
Registration Rights
Shareholder Representatives

Chapter 14: Legal Things Every Entrepreneur Should Know

Intellectual Property
Employment Issues
State of Incorporation
Accredited Investors
Filing an 83(b) Election
Section 409A Valuations

Authors’ Note
Appendix A: Sample Term Sheet
Appendix B: Sample Letter of Intent
Appendix C: Additional Resources
About the Authors
Excerpt from Startup Communities

The book also has a companion site, with tons of resources for your startup! I'de absolutely pick this book up and review it if your seeking funding for your startup or considering pitching your startup at a 'SharkTank' like event. The book really arms the reader to go to toe with an a angel investor, who will likely have the upper hand in such a situation. Further, the book helps founders determine when is the proper time to engage a lawyer, and where to best spend your resources with the lawyer. One of my favorite parts is how he includes game theory in his analysis of striking deals. Whatever you decide, this is a pretty educational book and a great glimpse into the world of venture capitol funding from the perspective of a founder, lawyer, and investor, all wrapped up into one (although not your lawyer or actual legal advice lol).

Tuesday, November 24, 2015

Book review: "The Lean Startup"

"The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses" by Eric Ries is a must read for anyone trying to launch your own small bushiness or startup! This is a book that can help engineers think of a new business more like a product they engineer and test. I listened to the book, again, on Audible for $20; although I had originally read the book back in 2011, I felt it important to go over the lessons again. The version I listened to was recorded by Eric Ries himself, so that was interesting for me to hear the author read their own text (8.5 hrs / ~300 pages). The entire book touts some pretty core philosophies, such as test your assumptions with a minimum viable product, using a build, measure, learn strategy. I also think it builds on The Phoenix Project a bit, by giving us more techniques from the familiar Toyta success stories, such as the method of Five Whys. The examples in the book are all fairly recent and well known successful ventures from the silicon valley, which supports how pragmatic his lean startup philosophies can be. I really liked how his theories revolved around testing products, which resonated with me as a tester and infosec analyst. I would recommend this book to hackers, inventors, founders, CEOs, CTOs, and essentially anyone building or delivering a product or service. Ultimately, I give the book 7 / 10 stars, because I believe it teaches important lessons but can drone on and dons't have too much reread value.

Origins of the Lean Startup
The Lean Startup Method
Why Startups Fail
How This Book is Organized
Management's Second Century

Part One: Vision

Chapter 1: Start
Entrepreneurial Management
The Roots of the Lean Startup

Chapter 2: Define
Who, Exactly, is an Entrepreneur
If I'm an Entrepreneur, What's a Startup?
The Snaptax Story
A Seven-Thousand-Person Lean Startup

Chapter 3: Learn
Validated Learning at IMVU
Brilliant Strategy
Six Months to Launch
Talking to Customers
Throwing My Work Away
Value Vs. Waste
Where Do You Find Validation?
The Audacity of Zero
Lessons Beyond IMVU

Chapter 4: Experiment
From Alchemy To Science
Think Big, Start Small
For Long-Term Change, Experiment Immediately
Break It Down
An Experiment is a Product
The Village Laundry Service
A Lean Startup In Government

Part Two: Steer

Chapter 5: Leap
Strategy is Based on Assumptions
Analogs and Antilogs
Beyond "The Right Place at the Right Time"
Value and Growth
Genchi Gembutsu
Get out of the Building
Design and the Customer Archetype
Analysis Paralysis

Chapter 6: Test
Why First Products Aren't Meant to Be Perfect
The Video Minimum Viable Product
The Concierge Minimum Viable Product
Pay No Attention to the Eight People Behind the Curtain
The Role of Quality and Design in an MVP
Speedbumps in Building an MVP
From the MVP to Innovation Accounting

Chapter 7: Measure
Why Something as Seemingly Dull as Accounting Will Change Your Life
An Accountability Framework that Works Across Industries
How Innovation Accounting Works - Three Learning Milestones
Establish the Baseline
Tuning the Engine
Pivot or Persevere
Innovation Accounting at IMVU
Improving a Product on Five Dollars a Day
Cohort Analysis
Optimization Versus Learning
Vanity Metrics: A Word of Caution
Actionable Metrics Versus Vanity Metrics
Cohorts and Split-tests
Hypothesis Testing at Grockit
The Value of the Three A's

Chapter 8: Pivot (or Persevere)
Innovation Accounting Leads to Faster Pivots
A Startup's Runway is the Number of Pivots it Can Still Make
Pivots Require Courage
The Pivot or Persevere Meeting
Failure To Pivot
A Catalog of Pivots
Zone-in Pivot
Zone-out Pivot
Customer Segment Pivot
Customer Need Pivot
Platform Pivot
Business Architecture Pivot
Value Capture Pivot
Engine of Growth Pivot
Channel Pivot
Technology Pivot
A Pivot is a Strategic Hypothesis

Part Three: Accelerate

Chapter 9: Batch
Small Batches in Entrepreneurship
Small Batches at IMVU
Continuous Deployment Beyond Software
Hardware Becoming Software
Fast Production Changes
3D Pricing and Rapid Prototyping Tools
Small Batches In Action
Small Batches in Education
The Large-Batch Death Spiral
Pull, Don't Push
Hypothesis Pull in Clean Tech

Chapter 10: Grow
Where Does Growth Come From?
Word of Mouth
As a Side Effect of Product Usage
Through Funded Advertising
Through Repeat Purchase or Use
The Three Engines of Growth
The Sticky Engine of Growth
The Viragl Engine of Growth
The Paid Engine of Growth
A Technical Caveat
Engines of Growth Determine Product / Market Fit
When Engines Run Out

Chapter 11: Adapt
Building an Adaptive Organization
Can You Go Too Fast?
The Wisdom of the Five Whys
Make a Proportional Investment
Automatic Speed Regulator
The Curse of the Five Blames
Getting Started
Facing Unpleasant Truths
Start Small, Be Specific
Appoint a Five Whys Master
The Five Whys in Action
Don't Send Your Baggage through the Five Whys Process
Adapting to Smaller Batches
Year One: Achieving Failure
Year Two: Muscle Memory
Year Three: Explosion

Chapter 12: Innovate
How to Disrupt Innovation
Scarce by Secure Resources
Independent Development Authority
A Personal Stake in the Outcome
Creating a Platform for Experimentation
Protecting the Parent Organization
Rational Fears
The Dangers of Hiding Innovation inside the Black Box
Creating an Innovation Sandbox
Holding International Teams Accountable
Cultivating the Management Portfolio
Entrepreneur is a Job Title
Becoming the Status Quo

Chapter 13: Epilogue: Waste Not
Organizational Superpowers
Putting the System First: Some Dangers
Product Development Pseudoscience
A New Research Program
The Long-Term Stock Exchange
In Conclusion

Chapter 14: Join the Movement
Lean Startup Meetups
The Lean Startup Wiki
The Lean Startup Circle
The Startup Lessons LEarned Conference
Required Reading
Further Reading

I like how he emphases validating both value proposition and growth proposition with early adopter data, not intuition or verbal feedback, this makes his philosophies very real. I also like how he puts an emphasis on decreasing the batch size to get development cycles tighter, and thus test new assumptions more rapidly. The book has a companion site, which also includes a wiki and an annual conference!  Despite all my praise, at points the book can drag on, seemingly beating the same ideas in over and over again, although it does this in an entertaining manner, using examples of recent and successful startups. The audio also doesn't have all of the cool graphics like the text, so having the physical copy was refreshing for the graphics. At the end of the day, it's a great book to read if your about to start your business or launch a product!

Saturday, November 14, 2015

Book Review: "Data and Goliath"

"Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World", is the latest book by Bruce Schneier, and generally summarizes what the world learned about NSA data collection in the wake of the Snowden leaks. I listened to the book on Audible for $17 (free w/ my Audible hack;) and it was roughly 9.5hrs (320 pages) long. This is the second Schneier book I've read, the first being his original, "Applied Cryptography", better known as the big red book. I liked this book for similar reasons as it was able to extrapolate very technical subjects into layman's terms, however I actually liked "Applied Cryptography" even more as it was more technically focused.  While some complain that "Data and Goliath" drones on at times, I actually found the arguments distinct and compelling, amassing into a well constructed scenario, problem, and even proposed solutions for the issues of mass data collection and surveillance. At the end of the day, this book is more than an informative piece on modern technology and surveillance, it's a social, ethical, and philosophical take on America's current tech landscape, something I didn't see coming when I picked this book up. Ultimately, I give this book 6 out of 10 stars because it's a compelling and modern philosophical critique of surveillance, but falls short when compared to the depth of Schneier's big red book and presents no real original content of its own. It leaves more to be desired with the technical readers and thus I recommend this book to those interested in information security in general, technology law, or philosophy but not necessarily practitioners. The following is the detailed sections and chapters of the book, to give the reader a better understanding of what it contains:

Part 1: The World We're Creating 

Chapter 1: Data as a By-Product of Computing 
Chapter 2: Data as Surveillance 
Chapter 3: Analyzing our Data 
Chapter 4: The Business of Surveillance 
Chapter 5: Government Surveillance and Control 
Chapter 6: Consolidation of Institutional Surveillance

Part 2: What's at Stake 

Chapter 7: Political Liberty and Justice 
Chapter 8: Commercial Fairness and Equality 
Chapter 9: Business Competitiveness 
Chapter 10: Privacy 
Chapter 11: Security

Part 3: What to Do About It 

Chapter 12: Principles 
Chapter 13: Solutions for Government 
Chapter 14: Solutions for Corporations 
Chapter 15: Solutions for the Rest of Us 
Chapter 16: Social Norms and the Big Data Trade-off

My favorite part is certainly Part 3, where Bruce dosn't leave us scratching our head at a messed up world, but rather arms us with various alternatives and solutions to the data guzzling problem he laid out in the first two parts of the book. By far, the most shocking chapter in my opinion is Chapter 13, when Bruce calls for the disbanding of the NSA! He makes a compelling case and backs it up with many alternative view points, making for several interesting and thought provoking topics in the last half of the book. In the end, its a timely, informative, and truly stimulating book, asking us  all to look at our own data use more carefully. Bruce is a wellspring for these philosophical infosec musings and if you enjoy this type of dialog you should check out his writings or presentations. In the following presentation at Google, Bruce covers some of the topics of the book in his own words:

Friday, November 13, 2015

Cooperative Infrastructure for Security and CTF Teams

On the National CCDC Red Team we use a number of different infrastructure tools to help us quickly and effectively share operational notes and goals, such as shells or reports. We use real time document applications to share notes about current vulnerabilities and harvested credentials. Similarly, we use c2 (command and control) and team servers to share shells and various network access with other team mates. This style allows for people to further specialize in operations, such that some people can focus on scanning, some others exploitation and shelling, a different group on planting stage two rootkits and monitoring, other team members could be reporting such exploits in the scoring system, and finally some team members may even be scripting and disseminating new tools they wrote on the fly. The following is a set of infrastructure or tools I have used throughout my security gaming career, which are things I have found beneficial to teams.

Let's start with some general tips before we dive into the helpful infrastructure. Before any CTF make sure you are familiar with the basics and the week before a specific CTF take some time to read writeups of challenges from it's past years. If your totally new to CTFs you should start with this article. Creating your own repository of upcoming CTFs with study material for all interested team members can be a good way to prepare your team in general for the upcoming CTF. Don't use public services like Pastebin, public Github / Gists, VirusTotal, or Malwr!! On the flip-side, you can search these to get counter-intelligence on other teams progress, even find solutions to challenges. If you get stuck on some challenges and find some extra time on your hands, use google dorks to search these sites for content relating to your challenge, where applicable.

Good preparation means make sure everyone has the tools they need beforehand, so there is no waiting for installation and setup time. Make sure people have virtual machines of their favorite tool sets ready and updated. If you don't have a custom deployment, I recommend KaliSIFT, or Santoku, depending on your needs. You can also distribute collections of private tools to do the same functions locally on the local virtual machines, I recommend packages such as ctf-tools or analysis-tools. Having these available in local virtual machines, as well as over VNC can allow for fast analysis and collaboration. Similarly, having a private web application for general / fast data transformations can be a good idea, I like using Pure Funky Magic for this. In this way teammates aren't going to public web applications to do simple data transformations.

For strong chat-ops, Slack is a good idea so you can integrate other collaboration services. Specifically Google Docs and Github are great collaborative integrations to Slack for these exact tasks. If you don't like Slack, another good alternative is Quip, for their real-time interactive documents. Both have excellent mobile applications for keeping players intimately involved throughout the competition. These options also allow for easy file sharing for files related to challenges. If you want to host your real time collaboration document privately on an internal network you can easily stand something like etherpad up. Create channels specific to challenges. Document procedures and progress as you go in the interactive document application you've chosen, always make sure history archiving is enabled.

A good place to start is with CTFs is often recon. One of the communities favorite tools, Maltego, recently offered an XMPP team server capability, which allows people to share mind maps and graphs in a collaborative format. Another good recon tool that can be used like a web application, is Spiderfoot, a revamped Google dorking and scanning tool. This can be a great way to kick off some quick recon, which all team mates will have access to moving forward, and is a well documented tool in this regard.

For attack scenarios, if you don't have a custom c2 server, consider hosting Metasploit team servers or Cobalt Strike team servers. To do this, I like to have various Kali clients connect to a stable Metasploit database server on the web or in a private enclave. If you constantly need new IP addresses consider using init scripts or custom images to quickly deploy your custom clients on the fly to your favorite VPS, such as Amazon or Digital Ocean. Further, if you are doing this type of scenario, you absolutely have to check out Raphael Mudge's Advanced Threat Tactics Course. If you are attacking web applications, PortSwigger (the makers of Burp) recently released the ability to host private Burp Collaboration Severs, which looks really interesting but you need a pro license to use the feature.

For crypto or hash cracking, consider having on demand cracking solutions at hand, such as physical hash cracking rigs or cloud cracking rigs you can spin up. I have an example script for setting up such a cracking server on AWS.

For malware reversing, consider setting up a private sandbox to quickly get dynamic execution information from. Cuckoo would be a cheap great sandbox for internal analysis. Another interesting idea is a team disassemble server, such as a Radare2 web server, for team based annotating binaries (they have a section on this in their book).

For networking challenges you could setup a Cloudshark account for team based annotating pcaps. private sharing of pcaps in a collaborative way. With the ability to tag any single packet or leave general notes and tags, Cloudshark is a great way to share information about network captures, especially because all the other person needs is a browser (no Wireshark necessary).

Private Git repos (such as Github or Bitbucket) or SVNs allow people to collaborate on the exploit development challenges. Further, re-staging code or a target servers in a team accessible location can save others time when moving to these challenges, allow them to dive right into the analysis and development vs setting up the testing environment.

At the end, consider hosting a private wiki for documenting lessons learned and methodologies. This will help new and other team members when you can't be there. Also consider a public blog or Github repository for group CTF writeups, this will encourage others and show expertise.

Checkout this material as a presentation I gave to the CCSF security club on 11/13/15:

Wednesday, November 11, 2015

Book Review: "Red Team"

"Red Team: How to Succeed By Thinking Like The Enemy" by Micah Zenko is an excellent book on the history and art of competitive analysis or red teaming a concept or scenario. I listened to the book on Audible for $15, which was an 11 hour listen (336 page).  The book is a great historical and theoretical look at the activity of Red Teaming, from how the practice of devil's advocate started to how red teaming grew through the United States military, intelligence community, and private sector. It's a great book for any pentester or intelligence analyst looking for a history of the field in terms of major players, groups, and events. Further, it's an excellent book for any CEO or CTO looking to get an objective view of their organization or processes. Overall, I give the book 7 out of 10 stars for history, theory, and perspective, but as good as all of that history is, the book tends to leave something to be desired in technical implementation from people like me, red team practitioners.  That said, the anecdotes and in-depth accounts of real world red team successes and failures really brings home the importance of such a program, as well as its various pitfalls. Zenko even spends a chapter on how red teaming can go horribly wrong, when misdirected, scoped too tightly, or even set up to confirm existing biases. Overall, this was an enlightening and warming book to read, as it codified many of the theories and beliefs red teamers have but have never put into any formal canon. Below I've included the chapters of the book, in my typical review fashion, as I believe this helps prospective readers know exactly what the book covers:


Al Kibar: “Gotta Be Secret, Gotta Be Sure”
Why Organizations Fail, But Can’t Know It
How Red Teams Function
How Red Teams Succeed or Fail
Into the World of Red Teaming


1. The Boss Must Buy In
2. Outside and Objective, While Inside and Aware
3. Fearless Skeptics with Finesse
4. Have a Big Bag of Tricks
5. Be Willing to Hear Bad News and Act on It
6. Red Team Just Enough, But No More
The Overarching Best Practice


Red Team University
Card Tricks: Mitigating Hierarchy and Groupthink
Marine Corps Red Teaming: Challenging Command Climate
Millennium Challenge: “The Significant Butt-Kicking”
Military Red Teaming Abroad


Team B: “Reflecting the World as They Saw It”
Al Shifa: A Missed Opportunity
Inside the CIA Red Cell: “I Wanted My Mind Stirred”
Osama bin Laden’s Compound: From Zero to Fifty Percent


Pre-9/11 FAA Red Team: “A Substantial and Specific Danger to Public Safety”
How to Shoot Down a Plane: MANPADS-Vulnerability Assessments
NYPD Tabletop Exercises: “Never Let the People Believe That They’ve Solved the Problem”
Information Design Assurance Red Team (IDART): Making Red Teaming a Commodity Tool


Simulating Strategic Decision-Making: Business War-Gaming
White-Hat Hackers and Hamster Wheels: Cyber Penetration Tests
I Can Hear You (and Everyone Else) Now: Hacking Verizon
Why Your Secure Building Isn’t: Physical Penetration Tests


Realistic Outcomes of Red Teaming
Red-Teaming Misimpressions and Misuses
Recommendations for Government Red Teams
The Future of Red Teaming

The most shocking chapter for me was in Part 4, where Micah discussed the FAA Red Teaming and the attacks performed on airports all around the US decades before the attacks on September 11th. This really hammered home how important it can be to listen to the red team findings, to me as a reader. Further, the book covers numerous important theories that shouldn't be missed anyone, such as humility, you can't grade your own homework, mitigating group think, challenging assumptions in a strategy, and having a documented alternative analysis performed. Ultimately, this was an enjoyable and educational book, both from the perspective of a professional penetration tester and the perspective of a CEO. Finally, I'de like to reiterate that Micha's six best red team practices are pretty spot on, but don't take from me, here's an interview with him about the book:

Tuesday, November 10, 2015

Escape Review: Exit Game, Lab 51

Just finished playing the room Lab 51 at Exit Game in Monterey Park, Los Angeles and it was excellent! This was the biggest 'room' I've ever played in, branching out into near eight or even nine rooms depending how you divide them. This was also the smallest group I've ever done a Real Escape Game with. We did this one with only a team of four people, and while we missed the hour mark by going over a few minutes, we solved all of the challenges and made it out.

The challenges were complex and kept us on our toes, having to think outside of the box as well as keeping track of already solved challenges. In this room, the path was linear but constantly doubling back on itself, or leaving us with partially unsolved challenges and clues. Despite the low number of people, the team worked amazingly well, we were all engaged and constantly brainstorming and turning our clues over. We were vocal as a group, announcing what we've found and mulling over places we would get stuck. The Exit Game hint system works such that if you only take 1 hint, you can make their leader board, but you get a hint every 10 minutes, so we should have used more hints than we did, after taking our second. We didn't use our pen and paper as much as we thought we would, as most of the puzzle were doable in one's head and the challenges took a fairly straigh forward path. Ultimately, I think what hung us up was our own suspicion and over examination of the surroundings, thinking there was some hidden clues where there wasn't any.

I really enjoyed the setting of Lab 51, from army crawling through tight raised ducts and spaces to rooms filled with alien autopsies and elaborate apparatus. My favorite room looked like a safety deposit box room which led into an even creepier doctors office room, both pitch black. One unique component to this game is we were all given personal flash lights (disguised like fake guns) and helmets for the crawl spaces. After getting through the first room the game became surprisingly dark and ill lit, so the personal flash lights really came in handy, I even ended up carrying around two (and later, a discovered black-light (in the future, bringing our own black-light could save us tons of time!)), and I would often prop a light up in places as we would look at challenges. In the end, I was pretty surprised that the entire challenge ended up being so big and expansive, as I remember thinking how small the first room was. The entire thing was wonderfully constructed and decorated, again this was one of the most elaborate escape game rooms I've been in.

This game was also interesting because we weren't allowed to bring phones in, and further we were scanned with a metal detector before to make sure weren't sneaking anything in. Despite the metal detector, we were able to sneak some lock picks in and the rules said nothing about non-destructive circumvention of the locks. This is an approach I've wanted to take to real escape games for awhile, reminding me of the Black Bag Challenge at Defcon, where escaping the room involves a combination of lock picking and computer based skills. Similarly, I'de really like to play a real life escape game with one or two members of the team being skilled at lock picking, to see if we can't circumvent large portions of the game that the game masters had not intended. All that said, due to the linear nature of this game we were unable to bypass any specific lock before we solved the challenge as intended. This is a strategy I will be attempting more in the future, so stay tuned for that!

Overall, Exit Game was a amazing! Further, while we were there I saw an engineer working on a number of Raspberry Pi systems for electronic elements of a new room they are working on. When you see people building cool tech and applying it to fun and educational events, you just know it's going to be a good time!

Sunday, November 1, 2015

Book Review: "The Phoenix Project"

"The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win" by Gene Kim, Kevin Behr, and George Spafford is a fictional, non-technical book about an IT operations lead who inherits a poor IT infrastructure, needs to save a dying company, and does so through applying DevOps philosophies. While the book isn't directly technical, I don't think a non-technical audience would enjoy it as it deals almost exclusively with the trials of a corporate IT team. The book is roughly 350 pages and ranges anywhere from $16-$60, although I listened to it for free on Audible. Ross and I listened to the book on a road trip through California and he provides his thoughts as a DevOps guy in the review below!  The book describes every IT employee's worst nightmare and often times reality, a dysfunctional enterprise who's various IT downtime and missed deliverable are effecting the rest of the company in a noticeable way. The major issues of the book are then solved though various workflow management and DevOps theories, bringing the whole company back into profitability though optimizing IT operations. In my opinion, the book is more for IT managers or directors, covering technical topics from a mile high, rather than for those executing technical operations. I found it great from the perspective of a CEO, specifically the analogies to getting work done as an entire company and dealing with the many unforeseen issues that crop up as you attempt to charter your once clearly set business goals. The book focuses on the IT issues larger organizations tend to see and is scoped for enterprise or corporate groups as opposed to small businesses. The fictional plot reminded me of the IT version of Way of The Peaceful Warrior, with the narrator finding an enigmatic mentor who imparts many of the lessons learned, although many people have referred to it as a modern IT version of The Goal. Overall, I give it 6/10 stars because I think the theories and methodologies are important and I found the story entertaining but I thought it could have gone deeper into those theories, as opposed to it's mile high fly over of the DevOps solutions which solved their long described issues.

The book shows how to direct internal IT systems synergistically by analyzing and optimizing the development and operation of services, through the fictitious example of a car parts manufacturer. I really liked the various workflow management and DevOps theories discussed throughout the book, such as the theory of constraints, continuous integration, delivery, change management, lean manufacturing, Kanban and general team work. I especially appreciated the focus on change management and work in progress. The parts I didn't like were the constant, drawn out and dramatic fictitious conflicts that set the stage for the DevOps solutions. I also didn't appreciate how information security seemed to 'get in the way' at every turn, but appreciated its role in the larger story and life cycle of development. Normally, my reviews include the chapters of the book, to help the reader get a handle on the technology it covers in more detail, but I don't think that will help here, so instead Ross (a DevOps engineer) will provide a paragraph on his thoughts on the book!!

Ross's thoughts: "Throughout the Phoenix Project, as the main character Bill overcame problems with his team, I thought back to my previous jobs at various companies. Big, medium and small companies all had various levels of IT competency, a term used in the book to describe the ability a company had to execute on its business goals. The author highlights classic system engineering principles of bottleneck identification and common-case optimization to show how the main DevOps practices of continuous integration, deployment and automation could naturally arise as solutions. One topic the book does not dive into is the immense details on how those components come together, or how to gather support for such projects when there is too much technical debt."

In conclusion, it's a great and entertaining book, as well as thought provoking and providing inspiration for some really excellent theories. After the first chapter, the pace kept me on the edge of my seat and I couldn't wait to find out more, but towards the end it seemed long winded. If this review sounds intriguing to you, you can check out a sample of the book on their site, which is actually the entire first half of the story, or chapters 1-16 (out of 35). Enjoy the story, personally the fiction was a nice break from the standard IT book for me!