Notes from watching Programming the Feynman Way

Notes from the talk Programming the Feynman Way way by Ben Evans.

Points I found interesting:

The purpose of Agile: give order of magnitude increase in productivity.

Explicit Assumptions and Approximation. State assumptions up front so when gaining data they are confirmed, adjusted, or changed.

Empirical view of the problem.  With data you can start to use the data points to eliminate any conclusion that does not fit the data.  Utilise Occams Razor: the simplest explanation is most likely correct.   The more data the more conclusions you can also discount as not fitting the data.

Hardware people have been doing great strides in computing power but software is getting more complex. Moores law is running out.  Understanding hardware and computing theories such as big-O will be increasingly important.

Blindly using others conclusions is cargo cult.

Follow single responsibility principal for a class. Names of classes are important.

Code reviews are worthwhile and everyone including the senior people should have their code reviewed.

Simple visualisation is one of the best ways to explain something. The more complex a diagram the less it conveys.

Reduce problems to smaller pieces and then tackle them. The smaller the problem the fewer assumptions will be in play.  Assumptions are easier to challenge when you can review a smaller data set about them.

Some people think graphically some via text but both have to be processed and translated by the receiving party.

Everyone should read Why developers keep making bad technology choices.

Basis of being a technology professional is risk reduction. Deliver but do not break what is already there as business continuity is imperative.

Share what you know. Teaching others teaches yourself.

Challenge subject area expert to prove their assertions.  Appeal to authority one of the rhetological fallacies.

45 minutes into the talk he discusses of how the Feynman way is different from Agile.

How it is similar:

Reduce the problem.

Use simple tools.

Visualise the problem.  Via a backlog.

How it is different:

Upfront analysis when confirming results.

What is the size of the problem.  The data and the problem space.

State and document assumptions.

Approximate but document any assumptions.

Conclusions:

I have heard the Agile Manifesto criticised as it was created by 17 developers so does not take into account things like data.

Ben did not go into any detail on how he drew his conclusions on how Agile is different than Feynman other than saying they were his observations.

I find it hard to believe that any project would be funded without having a fair understanding of the problem space and the assumed data being generated, Agile or not.

Ben also makes the point that Agile projects too often goes to story cards too quickly.  That sounded like the trait of an immature team to me not just an Agile one.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s