The Wright Brothers and Scrum

July 28, 2015 Leave a comment

I recently read two books that, on the cover have nothing to do with each other, but actually have very much similar lessons.  The first is David MacCullugh’s The Wright Brothers and Jeff Sutherland’s Scrum: The art of doing twice the work in half the time.

imageimage

Although the human-interest side of the story was kind of interesting to me, what really stood out was how the Wright brothers got their machine in the air.  If you are not familiar with the details of how they constructed the Wright Flyer, there are some pretty interesting points:

1) The Wright brothers were a small agile team that comprised of no fewer than two (the brothers themselves) and no more than seven.  I did not realize how important Charlie Taylor and William Tate was to different pieces of the project.

2) The Wright brothers spent the 1st part of their journey doing research, combing all of the scientific literature, and engaging with the current though leaders of the day in a very much open-source style where they would freely share knowledge but retain the final product for themselves.  This was in direct contrast to other teams that operated in silos and secrecy.

3) The Wright Brothers believed in doing one thing at a time well.  They realized that there were two major problems with heavier than air flight –> thrust  and balance.  They separated these two concerns and tackled the balance problem first.  Once they figured out how to make a glider stable in flight, they then tacked how to add a motor to it.

4) The Wright Brothers made hundreds of small incremental changes with each change able to stand for itself.  For example, they went out to Kitty Hawk in the summer of 1900, 1901, and 1902 with gliders before going out the forth time in 1903 with their airplane.  Each time, the designs got bigger and closer to the final goal.

5) The Wright brothers were willing to challenge conventional and commonly accepted “facts” when their evidence did not support it.  The Wright brothers relied heavily on the calculations of Lilienthal and Chanute to measure lift and drag.  After several failed experiments, the Wright brothers ditched those and went with their own, painstakingly researched, measurement tables.

3) The Wright Brothers were in direct competition with Samuel Langley’s airplane.  In contrast to the Wright Brother’s agile approach, Langley had a large team that operated in absolutely secrecy while taking massive (at the time) amounts of public funds.  When Langley finally rolled out his “final product” it failed miserably every time.

So what does the Wright Brother’s methodology have to do with Scrum?  Everything. If you look art the core tenants of Sutherland’s book,  most of them can be found in how the Wrights conquered the air.  I went though the end of each chapter of Scrum and pulled out some of the take-away points that direct match to how Orville and Wilber did things:

image

The Wright brothers were doing scrum a full hundred years before it became a thing. As amazing what they created, how they did it is really remarkable.  Interestingly for me, the “It’s the journey, not the destination” just rang home.  As I write this blog, it is Friday night and I am on my front porch.  A neighbor stopped by to say “hello”.  When  told her I was working on a blog post related to my profession, she said “Oh, I am sorry you are not doing anything fun tonight.”  And I said “But this is fun.”  and internally I was thinking “I wonder why so many people think work is not fun?  Why are some many people socialized that way?  I hope my kids don’t wind up like that.”

Filed under Book Review, Coding Best Practices

The Wright Brothers and Scrum

July 28, 2015 Leave a comment

I recently read two books that, on the cover have nothing to do with each other, but actually have very much similar lessons.  The first is David MacCullugh’s The Wright Brothers and Jeff Sutherland’s Scrum: The art of doing twice the work in half the time.

imageimage

Although the human-interest side of the story was kind of interesting to me, what really stood out was how the Wright brothers got their machine in the air.  If you are not familiar with the details of how they constructed the Write Flyer, there are some pretty interesting points:

1) The Wright brothers were a small agile team that comprised of no fewer than two (the brothers themselves) and no more than seven.  I did not realize how important Charlie Taylor and William Tate was to different pieces of the project.

2) The Write brothers spent the 1st part of their journey doing research, combing all of the scientific literature, and engaging with the current though leaders of the day in a very much open-source style where they would freely share knowledge but retain the final product for themselves.  This was in direct contrast to other teams that operated in silos and secrecy.

3) The Wright Brothers believed in doing one thing at a time well.  They realized that there were two major problems with heavier than air flight –> thrust  and balance.  They separated these two concerns and tackled the balance problem first.  Once they figured out how to make a glider stable in flight, they then tacked how to add a motor to it.

4) The Wright Brothers made hundreds of small incremental changes with each change able to stand for itself.  For example, they went out to Kitty Hawk in the summer of 1900, 1901, and 1902 with gliders before going out the forth time in 1903 with their airplane.  Each time, the designs got bigger and closer to the final goal.

5) The Wright brothers were willing to challenge conventional and commonly accepted “facts” when their evidence did not support it.  The Wright brothers relied heavily on the calculations of Lilienthal and Chanute to measure lift and drag.  After several failed experiments, the Wright brothers ditched those and went with their own, painstakingly researched, measurement tables.

3) The Wright Brothers were in direct competition with Samuel Langley’s airplane.  In contrast to the Write Brother’s agile approach, Langley had a large team that operated in absolutely secrecy while taking massive (at the time) amounts of public funds.  When Langley finally rolled out his “final product” it failed miserably every time.

So what does the Wright Brother’s methodology have to do with Scrum?  Everything. If you look art the core tenants of Sutherland’s book,  most of them can be found in how the Wrights conquered the air.  I went though the end of each chapter of Scrum and pulled out some of the take-away points that direct match to how Orville and Wilber did things:

image

The Wright brothers were doing scrum a full hundred years before it became a thing. As amazing what they created, how they did it is really remarkable.  Interestingly for me, the “It’s the journey, not the destination” just rang home.  As I write this blog, it is Friday night and I am on my front porch.  A neighbor stopped by to say “hello”.  When  told her I was working on a blog post related to my profession, she said “Oh, I am sorry you are not doing anything fun tonight.”  And I said “But this is fun.”  and internally I was thinking “I wonder why so many people think work is not fun?  Why are some many people socialized that way?  I hope my kids don’t wind up like that.”

Filed under Book Review, Coding Best Practices

Predictive Analytics With Microsoft Azure Machine Learning

March 24, 2015 Leave a comment

(On vacation this week)

Over the Christmas holiday, I had some time to look at some of the books that have been sitting on my bookshelf.  One of these was Predictive Analytics With Microsoft Machine Learning by Barga, Fontama, and Tok. 

image

This book is a great introduction to both analytics and Azure ML.  I really appreciated how the authors started off with a couple of basic experiments to get your feet wet, then moved over to some theory about different ML techniques, and then finished out the rest of the book with some hand-on labs.

I worked through all of the labs (except 1) in about 6 hours.  The labs follow a very nice step-by-step pattern with plenty of screen shots.  My only quibble with the book is that the most interesting lab was Building a Chun Model that relied on data from a third party.  When I went to the 3rd party’s website to download the data, the data had broken links and 404s.  I went to the book’s site at APress and its did not have the data either.  That was kinda frustrating and something that the authors should have considered.

In any event, if you have some time, working through Predictive Analytics With Microsoft Azure Machine Learning is well worth the time and is quite fun.

Filed under Analytics, Book Review

F# For Quantitative Finance

June 10, 2014 3 Comments

I picked up Johan Astborg’s F# for Quantitative Finance a couple of days ago and I thought it was great.  It was a practical hands-on way of working with FSharp.  It is so good, I think I am going to use it as a basis for a couple Triangle .NET User group F# SIGs.  One of the great things about the book are the code samples –they expose features of the F# language in a way that allows beginners to understand.  So in the trade-off between clarity and cleverness, Astborg errs on the side of clarity.   The only thing I think I would change would be to remove Chapter 2.  Chapter 2 suffers the same problem that many “intro to X computer language” books have –> pages of language features  with small independent samples.  This kind of book does not help many (if any) people learn the language easily, and it reads about as well as the MSDN component docs.

I did notice that Astborg did use the typical scientific computing approach to variable naming.  For example, on page 141 he creates a function like this:

  1. member this.black_scholes call_put_flag s x t r v =
  2.     let cnd x =
  3.         let a1 = 0.3198253
  4.         let a2 = -0.35653782
  5.         let a3 = 1.781477937
  6.         let a4 = -1.821255978
  7.         let a5 = 1.330274429
  8.         let pi = 3.141592654
  9.         let l = abs(x)
  10.         let k = 1.0/(1.0 + 0.2316419)
  11.         let w = (1.0)
  12.         if x < 0.0 then 1.0 – w else w
  13.  
  14.     let d1=(log(s/x) + (r*v*v*0.5)*t)/(v*sqrt(t))
  15.     let d2=d1-v*sqrt(t)
  16.     match call_put_flag with
  17.         | Put -> x*exp(-r*t)*cnd(-d2)-s*cnd(-d1)
  18.         | Call ->s*cnd(d1)-x*exp(-r*t)*cnd(d2)

Concentrating only on the function’s arguments, what is s,x,t,r, and v?  It is not immediately apparent and you have to read the comments above the function to discover that s is the stockprice, etc…  I think there is a better way and I wonder if FxCop (if it ever comes to F#) would agree with me..  For example, this is a slightly better version

  1. member this.black_scholes call_put_flag stockPrice strikePriceOfPotion timeToExpierationInYears riskFreeInterestRate volatility =
  2.     let cnd x =

The problem is that the number of arguments makes the naming unwieldy.  A third, and much preferred option is to pass in a data structure:

  1. type PutCallFlag = Put | Call
  2.  
  3. type black_scholes_input_data =
  4.     {stockPrice:float;
  5.     strikePriceOfPotion:float;
  6.     timeToExpierationInYears:int;
  7.     riskFreeInterestRate:float;
  8.     volatility:float}
  9.  
  10. type StockAnalyzer() =
  11.     member this.black_scholes (call_put_flag:PutCallFlag,inputData:black_scholes_input_data) =
  12.         let cnd x =
  13.             let a1 = 0.3198253
  14.             let a2 = -0.35653782
  15.             let a3 = 1.781477937
  16.             let a4 = -1.821255978
  17.             let a5 = 1.330274429
  18.             let pi = 3.141592654
  19.             let l = abs(x)
  20.             let k = 1.0/(1.0 + 0.2316419)
  21.             let w = (1.0)
  22.             if x < 0.0 then 1.0 – w else w
  23.  
  24.         let d1=(log(inputData.stockPrice/inputData.strikePriceOfPotion)

I doubt there is a performance hit and the code becomes much more readable.  It also forces the really long functions to be broken up and each piece becomes more testable.I  f there is not a corresponding domain for the input_arguments, then that naming will have to do.

 

Filed under Book Review, F#

F# Books

May 28, 2013 1 Comment

As part of my quest to learn a functional language, I picked 4 books about F#.  Being that I am a beginner, I dove right into this one:

image

Instead of the ‘hello world’ examples that you normally expect with a beginning book, it was a survey of the language constructs – and the code examples were not designed to teach rather they were used to illustrate a point –a subtle but important distinction.

After 3 chapters, I put that book down and picked up this book:

image

Now this is a great book.  It explains things in a progressive and hands-on fashion.  It’s too bad they called it “Expert” in the title – because it is actually a beginning book.  In fact, I would recommend ditching the Beginning F# book completely and diving right into the Expert F# book if you want to learn the language.

Filed under Book Review, F#

Machine Learning For Hackers: Using MSFT technologies

April 16, 2013 Leave a comment

So I picked up Machine Learning for Hackers and started going though the 1st couple of chapters last night.  I love the premise that developers can learn something about machine learning using some easily-understood examples.  Why I didn’t love was that it used R.  After reading the 1st chapter, I said to myself, “self, everything they do in this chapter you can do in MSFT office.”  Now I get that this is supposed to be a simple example to get the reader up and running with R, but I thought, “Hey, I wonder how much of this book can I do using the MSFT stack?”

Chapter 1 was all about cleaning up data to get it ready for analysis.  This brought me back to my 1st job out of school (marketing analyst) when I spent more time collecting and cleaning the data than actually analyzing the data.

My 1st stop was to download the sample UFO dataset from the publisher site and save it locally with a .txt extension.  I then imported the data into Microsoft access: Note that I assigned column names and made sure that the Long Description is memo:

image

 

Note that there were

With that base data imported, I then added an additional field to the table called valid.  The book follows the process of analyzing each column’s data and removing rows that are not analyzable.  I learned the hard way many years ago that you should never permanently remove data because you need to be able to trace the data set back to its initial state for audit purposes.  I like the ability to make queries upon queries in Access to layer up data validation steps.

For example, in the book, the first validation is to parse the DateOccured field into year/month/columns – the problem is that some columns don’t have valid data.  To this 2 step process, the first is to aggregate the values in the column and see what the valid values look like:

imageimage

 

Sure enough, there are over 250 rows of data that cannot be used.  I created a table of the aggregate dates and the inner joined that table back to the base datatable.  Rows with invalid data was flagged as Invalid:

imageimage

I then divided the Location field into City, State:

image

And then created table for valid states – the same way I did for the valid DateOccured.  I had to remove about 10% of the dataset – because of both malformed data and the fact that the dataset is world-wide and the book’s example is only interested in the USA.  The fact that 90% of the world’s UFO sightings is in America probably says something, though I am not sure what.

In any event,  then exported the data into Excel, threw a pivot table on the data and added some conditional formatting:

image

Note that some malformed data slipped in (“NT”, “NE”, etc…) but I was too lazy to go back and clean it up.

Note that this is total sightings, not per-capita so you would expect that the states with larger populations to have more sightings (assuming that UFOs are targeting the USA evenly).  I think the color presentation is more effective and really draw your eye to CA and WA much more than the 50 histogram display that is found in the book.

I then filtered the data to only greater than 1990 like the book did and changed the pivot table to filter on state.  Here is California:

imageimage

The color really shows how the number of sightings are increasing in CA and seem to be more consistent in WA.  I do wonder what happened in 1995 in WA to cause that spike?

The next chapter is about regression analysis, so I assume that I can use the built-in functions of Excel for that too…

Filed under Book Review, Machine Learning, MS Office

Book Review: Head First Design Patterns

January 15, 2013 Leave a comment

So I understand now why java developers are often accused of spending more time doing mental gymnastics then writing working code.  I am working through Head First Design Patterns as sort of a break from the projects I have been coding (on the advice of Steve Suing) and I am running into some interesting questions.

First,  I like how the authors have taken the Gang Of Four patterns and made them much more accessible.  Not that I like running through academic-prose and small talk examples (I don’t) like in Design Patterns, but the way the Head First books deliver content is great. 

Second, the examples they pick for a given pattern are really well thought-out.  Faster than your can say “Liskov Substitution Principle”, the first chapters explanation of the limitations of inheritance using ducks was spot on. 

Third (notice 2 nice things before 1 not-nice?  They teach that at the positive coaching alliance), I am disappointed that their idea of a “test harness” is a console app.  The next version of the book should use unit tests.

Finally, some code.  I was working though the examples when I got to chapter 3 (I am using C# and not java because I value secure software):

Base Class:

public abstract class Beverage
{
    public Beverage()
    {
        Description = "Unknown Beverage";
    }
    public String Description { get; internal set; }

    public abstract double Cost();
}

(I changed the Description from a field and getter method to a property.  The IL effect is the same, I believe)

The Decorator:

public abstract class CondimentDecorator: Beverage
{
    public new abstract String Description { get; }
}

And example Beverage:

public class Espresso: Beverage
{
    public Espresso()
    {
        this.Description = this.GetType().Name;
    }

    public override double Cost()
    {
        return 1.99;
    }
}

(I changed the Description setter from a hard-coded string to a method assuming the class name is the same.  And yes, ToString() should be overridden also)

And Example Condiment:

public class Mocha: CondimentDecorator
{
    Beverage _beverage;

    public Mocha(Beverage beverage)
    {
        _beverage = beverage;
    }

    public override string Description
    {
        get
        {
            return _beverage.Description + ", " + this.GetType().Name;
        }
    }

    public override double Cost()
    {
        return .20 + _beverage.Cost();
    }
}

So what is wrong?  Well, are you asking or telling Mocha?  If you are asking, then the method should be CalcualteCost().  If you are asking, then you should call GetCost() or its syntactical equivalent Cost{Get;} so you   really have a POCO.  And if you are doing a calculation in a POCO, you are doing something wrong.  So the method should be CalculateCost().  Syntax aside, that means that the Description should be CalculateDescription().  So this looks like a clear violation of command/query separation.  Is this violations the pattern’s fault or the authors?  I don’t know.  I don’t really care.  I guess I “get” the decorator pattern enough so I can have this conversation:

Jamie: Hey, how would you architect an application that needs pluggable components?

Some architect: What about using the Decorator Pattern?

Jamie: Have you ever implemented that, like, for real?

Some architect: Oh, I don’t implement.  I just design.  Want to see the UML?

Jamie: No Thanks.

This brings me to the next part of the book that I am still thinking whether I like or not.  As Bob Martin explains, software has 2 values: the primary value and the secondary value.  The primary is how well the software changes, the secondary is how well it meets the current requirements.  Quite often I see line developers with immediate deadlines looking to solve the secondary value talking to the architect who is interested in  the primary.  Who is right?  Does it matter?  Until technical debt is put on the balance sheet, I fear that secondary will always be put in the back-seat.  I guess code re-work is good for consultants.

Finally, the one thing I really disagree with the book are these captions:

imageimage

I disagree that they put in this global assumption that is a hold-over from the mainframe programming days.  Duplicate code is better than code that has to be changed.  With modern source control and refactoring tools used correctly, duplicate code is not bad.  In fact, if you duplicate code to make sure your follow the Single Responsibility Principle, that is OK.  If you want to refactor later to consolidate, that is fine as long as the unit tests still run green. 

And I think that is the conclusion that I have to my 1st sentence.  Design Patterns are not the end of themselves (most people agree in theory).  They are not even the beginning (Too many architects that I know disagree with that).   Patterns are what you back into and refactor to, not the other way around.  Not really this books fault – after all it is a book about design patterns – not writing working software.  To this end, I think you need to look at Refactoring to Patterns.

Thanks to this clip which I listened to 5 times repeatedly when doing this blog post):

Filed under Book Review

Object Oriented Software Construction && Design Patterns

October 2, 2012 Leave a comment

I was watching some of Uncle Bob’s clean coder video casts when he mentioned this book in the ISP one:image

I picked up used copy for $5 on Amazon marketplace and dug in.  Perhaps the markup ($140 new, $.99 used) should have tipped me off that this was a text book, but I didn’t realize that until reading the first couple of paragraphs.  This is a text book, and reads like one.  There might be some good information in it, but the dense prose and concept-first organization makes it really hard to get through – and you certainly can’t skim it.  After reading the first couple of chapters, I realized that most of what he is saying is already out there in the public domain (in much more accessible form) so I put it up on the bookshelf.

Also, Uncle Bob mentioned a couple of patterns in the DI video cast: Visitor Pattern and Adapter Pattern.  I grabbed my Gof4 book Design Patterns and starting digging in. 

image

I quickly noticed that the way that the Gof4 present these patterns and the way Uncle Bob describes them are very different – and not in a good way.  I then stopped reading the Gof4 book and will try a couple of other resources like Pluralsite to help me here.

All in all, I didn’t really enjoy either exercise.  I am going to put The Annotated Turning back on my nightstand….

Filed under Book Review

HTML5 24-Hour Trainer Book Review

February 21, 2012 Leave a comment

I just finished HTML5 24-hour trainer.

clip_image001

About 85% of the book had nothing to do with HTML5 specifically. Rather, it was about learning basic HTML with some CSS thrown in. If you are complete novice in HTML, this is a good book to get you up and running. If you have coded in HTML for more than a couple of months, the book is of limited value. At the end, around chapter 26, Lowrey starts digging into HTML5 specifically and he presented the new tags well. Chapter 27 is particularly important because of the focus on HTML5 semantics. I think the book should be retitled “Learn HTML and CSS” with a byline of “including HTML5”.

On a side note, how excited are people that code for a living about HTML5? By reemphasizing java script and deemphasizing Flash/Silverlight, the amount of code for a Rich Internet Application will go up dramatically and require many more developer hours. Debugging massive amounts of JavaScript when a couple of lines of C# would have done the trick might seem frustrating, but at least the meter will be running…

Filed under Book Review

Illustrated WPF and WPF Programmer’s Reference

March 29, 2011 Leave a comment

I am studying for my MCPD exams, which I am taking in 2 weeks.  Because the official exam guide is so horrible, I picked up a couple more more books.  The first is Illustrated WPF by Solis.  I made it through page 141 before giving up.  I then opened WPF Programmer’s Reference by Stephens.  I made it through page 178.  Both books suffer from the same problem – they don’t teach WPF.  Rather, they introduce all of the concepts of WPF in a subject-specific way.  For example in Solis, Chapter 5 Layout, then Panels, then the StackPanel, then the wrapPanel, etc…  Each section has an illustration or two with a basic code snippet that you can read.  The problem is that I (and most people) don’t learn computer languages like this – it is equivalent to reading MSDN cover to cover.  I draw on my experience from Ivor Horton’s Beginning C++ or Doug Wright’s Beginning VB6.  Those books were more tutorial based with exercises to encourage the reader to have his/her hands on the keyboard.

 

I have one more book WPF4 Unleashed by Nathan.  I am not optimistic.  I’ll give the book a creditable try but I am already thinking about an application I can write to teach myself the concepts.  I hope I can get it done by my self-imposed exam deadline.

Filed under Book Review

← Older posts