Youtube Video Review: Lean Startup: Why it Rocks Far More than Agile Development - Joshua Kerievsky

Video Url

http://www.youtube.com/watch?v=V5p8m1IjJoA

Synopsis

"Lean Startup is a disciplined, scientific and capital effecient method for discovering and building products and services that people love." (From the video's Description Section on Youtube)

Notes

* Came from Eric Ries' failures (With his book `The Lean Startup`)
    * `The Startup Owner's Manual` - Great book on learning how to start startups
        * What does customer need/want
        * Customer Development is a core part for the lean startup
    * `Implementing Lean Software Development`
    * `Extreme Programming Explained`
    * `Kanban`
        * "How to visualize and limit work-in-progress in software development and information technology work"
        * Catalyzes cultural change and delivers better business agility - Amazon Book Description
* Even Large companies like Intuit can handle using the Lean Startup approach
* Needfeed example
    * Combination of buying and social networks
    * They invalidate their idea
        * Went on rentacoder.com
            * Changed facebook to show fake things that your friends bought
            * 40-50% people hated new stuff, but the company spent close to nothing getting feedback from users to show that
    * Went back to investors and told them the results of invalidating their idea
    * Kept pivoting 'till they found what works
        * Found what gets traction, and went with it
    * Invalidate extremely efficiently
(9:10) "In a startup no facts exist inside the building, only opinions." - Steve Blank
    * Fundamental idea that there's no facts only guesses until you have something to show
(9:35) "Get outside of the building" - Steve Blank
    * Try to see waste and eliminate it
    * "Learning to see waste and then systematically eliminate it has allowed lean companies such as Toyota to dominate entire indeustries." - Eric Ries
(9:55) Feature Fake
    * Thought: We have a guess that people are going to want todo online chat
        * Just an idea until you get users using it
    * Do a feature fake of this by hacking it in
        * 100 people saw it
            * 6/100 said they were likely to use it
        * 1000 people should have probably done it
        * You would think a lot of people would be annoyed by it, but you use it very sparingly
        * Is very fast
    * Eliminates waste
(12:30) Agile: Accepted
    * Agile development style - You want to get "Accepted"
    * Accepted means nothing, it's just accepting a guess that no one knows
    * Lean Startup Style: Validated
        * Want to validate whether something was used by people and it makes things better
    * (13:45) Use "Measure Usage" to see if something was validated
        * Logins with Resume
        * Resumes
        * Non-Resumes
(14:50) Validated Learning
    * Learning validated via data, surveys, interviews.
    * Demonstrated by positive improvements in startup's core metrics
    * Need to be doing experiments in order to validate the stuff you're adding is useful
(15:25) "Agile methods remove waste... yet those [Agile] methods had led me down a road in which the majority of my team's efforts were wasted." - Eric Ries
    * Well-crafted software that nobody wanted to use
    * Should have done minimalistic and tried it out
    * Agile doesn't say anywhere to do minimalistic
    * (16:45) Gave incredible customer service, but weren't watching usage
        * 80% of stuff was untouched
        * Don't have "shelfware" and things that aren't touched
(18:05) "A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty." - Eric Ries
(18:28) Ecosystem Happiness
(19:35) Continuous Deployment
    * Best part about Agile Development
(20:25) Started to deal with low-usage rates
    * Categorize Users
        * Non-Starters
        * Skimmers
        * Dabblers
        * Connectors
        * Finishers
    * Observe data to see how can make the max amount of people Finishers
(21:08) Average Response Time
    * See where bottlenecks for certain customer service questions are
(21:54) Analyze Page Views
    * What happens when you change your site slightly
(22:15) Usage Improvements
    * Completion Rates vs. Starting Rates
(22:45) "In an early stage startup, success is not in a 'to do' list, it's in a 'to learn' list." - Sean Ellis
    * Applies to most things we do
    * What do we need to learn, and how do we do it as rapidly as possible?
(23:15) Tools for planning Agile projects
    * Lean Launch Lab
        * Everything you enter in is all about hypotheses and tracking them
        * Everything is a guess, not really a hypothesis
        * Helps deal with the "Lean Canvas"
        1) Enter Hypothesis
        2) Enter Experiments to Prove/Disprove Hypothesis
        3) Enter key metrics to be measured
        4) Enter tasks to complete
(25:00) Product/Market Fit (diagram)
    * If you have to ask "Have we achieved Product/Market Fit?", then you haven't yet
        * You'll know it when you achieve it
    * The search for a business
(26:00) A Pivot is "a special kind of change designed to test a new fundamental hypothesis about the product, business model or engine of growth." - Eric Ries
    * Focused on these questions:
        * What is the product you're building
        * What are the metrics around it
        * What's your Engine of growth
        * How can I test/optimize it
(26:25) New Yorker Cartoon - "I'm not leaving you. I'm pivoting to another man."
(26:40) Eric's Catalog of Pivots
    * Zoom-In Pivot
        * Build on what users actually use
    * Zoom-Out Pivot
        * Build more stuff so more users use product
    * Customer Segment Pivot
        * Go to different segment/audience
        * Going from building for users to building for businesses
    * Customer Need Pivot
        * Change product to your customers
        * (Roast Beef story)
    * Platform Pivot
        * Change platforms completely
        * Move from one technology to another
(28:25) Votizen
    * Went through a lot of pivoting to find product
        * 1st MVP: Initial Product
        * 2nd MVP: Zoom-In Pivot
        * 3rd MVP: Customer Segment Pivot
        * 4th MVP: Platform Pivot
(29:45) Can't do well with MVP if you don't do innovation accounting
    * Innovation Accounting is when you account for: "Is my MVP any good?"
        * What metrics are telling me that my MVP is any good?
        * Track your numbers
            * Engine of growth
            * Registration rate
            * Activation
            * Retention
            * Referral
            * Revenue
            * Lifetime Value
(30:15) AARRR: Metrics for Pirates
    * Acquisition: users come to the product/site
    * Activation: users "use" the product/site
    * Retention: users use the site/product
    * Referral: users like product enough to refer others (Net promoter score)
    * Revenue: users conduct some monetization behavior
(31:05) Love Metrics (Intuit's metrics)
    * Delivered customer benefit?
    * Customers actively using it?
    * Customers telling others about it?
(31:45) Goto the Monkeys for Lean Insights
    * SurveyMonkey
    * MailChimp
    * Angry Monkeys
(32:05) Split (A/B) Testing
    * Different versions of a product offered to customers at the same time
         * Champion and Contender
    * Refine understanding of what customers want
    * Measure productivity via validated learning, not production of features
         * Stops arguing, just do experiments and make changes based on real data
(33:00) Mailchimp Email A/B testing
    * Paragraph difference (VIP vs. Not VIP)
(35:00) Collect as much data about your customers as possible
    * Don't make assumptions
(35:35) Usability data
    * Constant testing of UI
    * Where users click
(39:20) Concurrent Set Based Design
    * Combine many people's designs
    * 99 designs
(41:15) Heat/Click/Scroll Mapping
    * Create fake page and can Pre-Order for half price
    * Can see new/returning users
    * Can see if scroll down
(42:30) All tools shown are to see if we should build something
(42:45) Agile vs. Lean Startup
    * Most things are built upon Lean Startup idea
    * Lean Startup Ideas
        * Business Model Canvas
        * Product Market Fit
        * Minimum Viable Product
        * Learn/Measure/Build
        * "Get out of The Building"
            * No facts in the building, go find the facts
            * Always learning about the customer
        * Hypothesis
        * To Learn List
        * Customer Validation
        * Split (A/B) Test
        * Continuous Deployment
        * AARRR
        * Five Whys
        * Innovation Accounting
        * Led by Successful Entrepreneurs

Rating: 5/5

Review
I think this is a fantastic overview of the ideas of a Lean Startup and the differences between a Lean Startup and Agile Development. Joshua goes through in a high level what each idea means and follows them up with real-life examples of when companies, like his own, practiced these ideas. It's a great video to watch if you're interested in this topic and how to practice it.

Youtube Video Review: UrbanCode Video Blog 2 - Continuous Delivery and DevOps

Video Link: http://www.youtube.com/watch?v=IVnaRI2jOp8

Description
Goes through the difference between what Continuous Delivery does and what DevOps does

Synopsis
Continuous Delivery handles all the steps before pushing to the production servers, while DevOps handles pushing from one server to the production server.

Rating: 3/5

Review:

• It doesn't seem to go through the subject in enough detail, and their definition seems to be slightly off from the programming community's definition.
• It gives a really dumbed down definition of both
• If you're new to the subject, it'd be good to watch, but don't trust all the information contained in this video.
• It's great how short the video

Youtube Video Synopsis and Review - Introduction to Continuous Delivery by Rolf Russell

Video Link: http://www.youtube.com/watch?v=t6XUVaPQkKE

Synopsis:
Test everything fast and only change things on servers through automation. Continuous Delivery is awesome, and the benefits you get from implementing it outweigh the costs.

Notes (Taken halfway through 'till the end)

• You want to check-in code once a day to develop, and develop to master frequently
• Trunk Based Development rather than Branch Based Development
• Do this because it's tough to refactor with Branch Based Development
• Merges take time, no one wants todo them
• How to write features this way 
• Feature Toggles (Flag in .ini file)
• Most common mistake: People don't delete their old toggle (The previous code), but you need todo this
• Consistency from Development to Production
• Be consistent in the deployment process (Automating)
• Environment Configuration (Keep the OS and Packages the same)
• Testing Tools (Developers should use the same testing tools. QA should be using same tools)
• IT/Ops/QA/DEVs should be sitting together
• Work together
• Share KPIs (Key Performance Indicators)
• Stability and Change
• The nature of itops is changing
• The needs not consistent, so need generalists that can do a little of everything
• Concerns for moving to Continuous Delivery
• Reliability & Stability: Move to smaller chunks
• Compliance & Traceability: Automation provides great compliance and traceability
• Releasing 10 times/day: Not necessary, but you want to always have production releasable code
• Complexity of my systems: It's about continuous improvement. Start with low hanging fruit. Low cycle times.
• It will take investment: Yes, but it will also start paying dividends fairly quickly
• Question to ask about your Organization:
• How long would it take to get a one line code change into production using the normal process?

Rating: 5/5

Review

I thought this was a fantastic, first introduction into what continuous delivery was. It didn't give any details on the software to use or how exactly to implement, but it did provide an overview of what to think about and how your organization could benefit from continuous delivery

/usr/bin/env: Bad Interpreter

If you've corrupted or deleted your /usr/bin/env file, you'll most certainly brake a lot of your installed packages. You'll probably see errors like:

/usr/bin/env: bad interpreter: No such file or directory

The way to fix this issue is to reinstall coreutils:

        sudo aptitude reinstall coreutils


Don't have aptitude? Just install it:

       sudo apt-get install aptitude

Learning Rails - Practice Makes Perfect

Overview
Learning how to program is like learning how to play a sport or learning an instrument. It's a dynamic process that has a lot of different patterns that are used consistently. These patterns include:

• Opening/Editing/Closing files
• Adding files in certain locations
• Setting up and editing database configuration and such
• Using the debugger to fix runtime errors
• etc.

When learning to play a sport or an instrument, you practice the fundamentals of the patterns you use that you can then use in a game/performance.

Take Baseball as an example. To get better in Baseball, you practice. During practice you go over things like:

• Sprints to get faster at running the bases or running after the baseball
• Catching Fly-Balls to improve at focusing on the ball and catching it
• Taking Ground-Balls to improve at catching grounders
• Throwing to improve at accuracy and strength or throwing the baseball
• Batting to improve on hitting the ball with the bat

These things are repetitive things you practice to get better so that when you're thrown into a game situation, you are ready for whatever comes your way.

What most programmers do

Programmers don't tend to like to practice. They tend to just dive in and handle whatever comes their way. This is completely fine, because even though they never "practice", they get all the practice they need during game-time. They aren't being quizzed and no one is judging them for making a poor decision on the fly. 

However, I still think there's a lot of value in practicing correctly with programming. Without the proper repetition, you don't learn as effectively. Even after years of programming, I'm not as fast as I could be when developing a new application or debugging an application. What practicing allows you todo is develop reactive memory that will allow you to, with little to no thinking, sprint out many lines of code without doing much thinking. This allows you to build more over time and be more productive with your time.

What you should do

What should generally happen is you should set out for incremental learning over a long period of time. I'd say try to focus 30 minutes a day on practicing programming something that starts out very small. An example would be build a website from scratch that displays "Hello World" on the home page. This example may only take 5 minutes on the first day, and that's completely fine. You want to build up, adding something small each day. On the 2nd Day you could add css to that Hello World, making it blue instead of black. On the third day you could add a header. The important to note that every single day you start from scratch. You create a whole new rails application every single day that you will know how to build, so that process of building is reactive, and you can use that for building other applications very fast.

I like to think of this type of learning like a video game that you replay over and over again. Over time you get really fast at doing the commands, and so you're able to beat each level extremely quickly, and it builds your overall gameplay. With this style of learning, it's best to time yourself everyday to see how fast you can complete the application up to that point in. You should be getting faster, or remaining at a similar time if it's your computer that is the bottleneck, with each sequential day.

Overview

Do it, it will help

How Many Tests Should You Have in Your Python Program?

Overview:

Tests are one of the most crucial things in programming, but very few programmers write enough tests. One of the beginning obstacles to writing tests is how to write proper, fast tests.

Idea behind tests:

Tests should be extremely fast and should cover as much of your program as possible (100% is always preferred). Rule of thumb is if you have an if statement, you should have at least 2 tests.

Reason for Having 100% test coverge:

The more code you write, the higher chance of things to go wrong. If you write 10 lines of code, that's at least 10 spots where you can have an unexpected error in your code.

I think it would be a little excessive to have a test for each line of code in your program, but it's reasonable to have at least 2 tests for each if statement in your program. Why this number? Because the complexity of your program comes mainly from conditional logic (Or if statements). Take these lines of code:

if input == 'cat':

  a = 'meow'

else:

  a = 'woof'

Here, our program has 2 things that could happen: `a` can either be 'meow' or 'woof'. So we'd have 2 tests here: a test with input == 'cat', and a test where input != 'cat'. By having these 2 tests, we have 100% code coverage. By having this, it saves us from 2 potential fatal flaws in our program.

Lets look at a slightly more difficult example:

if input == 'cat':

  a = 'meow'

elif input == 'dog':

  a = 'woof'

else:

  a = "Hello kind sir"

Here, our program has 3 things that could happen: `a` can either be 'meow', 'woof', or 'Hello kind sir'. So, instead of 2 tests, we'd have 3 tests: a test with input == 'cat', a test with input == 'dog' and a test that doesn't equal 'cat' or 'dog'.

So lets go into a slightly harder example with if statements inside if statements:

if input == 'cat':

  if input2 == 'siemese':

    a = 'mawww'

  else:

    a = 'meow'

elif input == 'cat2':

  if input2 == 'siemese':

    a = 'mawww'

  else:

    a = 'meow'

else:

  a = "Hello kind sir"

Now the calculation of complexity is slightly harder. We need to take into account the if statement inside the first if statement, so the calculation will be about 7, because we have 5 possible different things that could be set, but also have to be sure the outer if statements (`if input == 'cat'` and `if input == 'cat2'`) are true ever. The important thing to note is that we have written the inner if statement logic twice, so we can simplify this to this:

def output_on_cat_type(cat_type):

  if input2 == 'siemese':

    return 'mawww'

  return 'meow'

if input == 'cat':

  a = output_on_cat_type(input2)

elif input == 'cat2':

  a = output_on_cat_type(input2)

else:

  a = "Hello kind sir"

Our new calculation is now 5 because we need to test the 3 if statements in the regular code, and test the 2 conditions in the `output_on_cat_type` function. This is one of the reasons why it's so important to refactor out if statements within if statements: It gets increasingly more difficult to have 100% test coverage with every if statement.

Writing Comments in Python

Overview
I think writing comments in python is grossly under-utilized and under appreciated. Many programmers say that your code should always be readable, thus they do not need comments. Others say that you don't need comments because you should have tests that show what the function is doing. While I think both are valid, comments are still necessary.

Why Comments are Needed
    Comments allow you to explain everything at a higher, deeper level. It gives other programmers who need to work on your code context to what the function they're working on is supposed to do. It also allows these programmers to refactor any poorly written code you wrote because they'll know for sure what the function is supposed to do. It prevents the "hacky" fixes and allows people to develop for what the function needs to do.
    They also allow you to have a deeper knowledge of what you need to do to write your function. If you write the comment before you write your function, then you don't get held up by uncertainty when writing it in python code.
    It allows you to develop an api for other programmers to use. An api without comments is like buying a do-it-yourself kit without instructions. Yes, other programmers can probably figure out what to do eventually, but they won't be happy doing it if they have to stumble over everything.

Why we don't put comments

• We are lazy
• Our current code isn't commented, so don't have the will to start
• We don't feel like we have time

    I've certainly experienced all of these reasons. The first step is to realize you have a problem. The second step is to start writing comments.

How to write comments

Docstrings

    The best way to write comments in python is to use docstrings. Docstrings allow programmers to see the comments of a function while running python by doing `help(<function_name>)`. They are also conveniently always right under the function declaration, which is very helpful for programmers looking for function comments. This is how to write a docstring:

    def function_name(param1, param2):

        """your_comments

        ...

        """

        <rest_of_your_function>

    As you can see, it's a pretty standard python comment, except that it is always placed right underneath the python declaration. If it's not placed there, then it's not a docstring.

Comment Design Patterns

    We want to provide other programmers with the most understandable, standardized comments possible, so lets take a look at what these comments should have and where they should have them.

    def function_name(param1, param2):

        """<What_Your_Function_Returns>

        

        <More_In_Depth_Of_What_Your_Function_Does_and_Returns>

        

        <Your_Function_API>

        

        <Examples_Of_How_To_Call_Your_Function_And_What_It_Returns>

        

        <And_Special_Case_Examples_Like_Errors>

        

        <Anything_Extra_You_Want_To_Add>

        """