My 2016 Goals and 2015 Reading List

2015 was a great year! I’ve worked on some of the coolest projects that I know. I’ve learned the internals on Angular 1.X and typescript. I’ve also started a new job (which is awesome) and made a pivot towards mobile development.

I’m certain that 2016 will be even greater!

Now when 2015 is over I’d like to start a personal tradition for myself in the blog. In the end of every year I’ll set personal goals for the year to come. The goals will cover the blog topics and the desired reading list for the next year. In the end of the next year I’ll go over the goals and verify that I’ve accomplished all of them. I will also list all the books I’ve read in that year so that maybe you will find something that suits you.
 
Let’s Start

This year I wrote 20 posts in my blog which are almost 3 times more than last year!

2016 Goal: Write at least 20 post.

I want to focus on mobile, agile and management topics. I will write on any other topic that I think is worth writing about but these topics will be the core.

Here are some ideas about the upcoming posts:

Mobile oriented posts:
1. TDD in IOS
2. IOS and Android best practices

Agile:
1. The psychology of Scrum
2. Retro done right
3. Agile estimations
 

2015 Reading List

Call me old fashioned but I love reading hardcopy books. My dream is to have a huge library filled will all the best books in the world. I always try to diversify and read different types of books.

I think that I did really well this year and picked awesome books. By the way - this is a great website where you can buy books with free shipping worldwide.

2016 Goal: Read books about management, leadership, innovation and at least one tech book. At least 10 books in total.
 

Here are the books I’ve read in 2015.

1. Steve Jobs – on the greatest minds that ever lived. He had an amazing and not ordinary life (the movies don’t get even close to the real deal). You must read this book if you consider yourself a manager or an entrepreneur.


2. The Last Lecture – an amazing book written by a man that was going to die. This is not one of those books about dying. It is about living. Living the life that you will not regret. The book is about the author’s last lecture which you can also watch here.


3. The Lean Startup
This is a must book for every manager and entrepreneur. It is well written, pragmatic and has lots of great real life examples.


4. 4 Hours Work Week
Life hacker Tim Ferriss in a great book about efficiency and building the life you dream about. It shows that your dreams can be accomplished. Just start and stay focused.


5. How Google Works
The managers of Google share the experience that they gained while working in Google.


6. The Leader Who Had No Title
Robin Sharma is one of the best leadership and life improving authors that I’ve encountered. I enjoyed reading all of his books. In my opinion this one is not as good as the “leadership wisdom” but it has lots of great topics in it (just read both).


7. Start-Up Nation
Great book that tries to determine how a tiny country like Israel has the largest amount of successful startups in the world.


8. The Passionate Programmer
Actually that is not a good book. The title doesn’t fit the content. It’s mostly about how not to lose your job. Don’t read it.


9. מחשבות לעט לילה
Haim Shapira writes about three philosophers: Nitsche, Schopenhauer and Kierkegaard. How did they live, what did they believe in and why? Very interesting.


10. High Output Management
Andy Grove’s book that is considered to be the Holy Grail of management books. It was written in 1983 and it is still accurate for this day. He covers all the aspects of being a manager. Great book, it’s a must read.

 

Allow me to repeat the 2016 goals:
1. Write at least 20 blog posts.
2. Read at least 10 books.
 



I like these goals :)

Now it’s time to start working on them.
Have a great year!

Everybody has a plan until they get punched in the face

“A failure” can be a result of a software or hardware problem. A fault tolerance design intends to enable the system to continue operating properly in the event of failure. In this post, I’ll talk about a way to treat a special cause of failure – a timeout using a really cool open source framework named Polly.
We prepare for failures, we put “try catch” blocks and check “if(something == null)” every now and then. We think we’ve got it covered and that we are fully protected.
As Mike Tyson said – that’s our plan. However, we all know that something “unpredictable” will always go wrong, and then we’ll be punched in the face.

Let’s say that you have a DB and you query it to get some data – user’s navigation history for example.

One of your users clicked to get his navigation history and waited for almost a minute (yes – that’s a long time) to get an error that crashes the application!

(BTW This not a great error page – read here about the importance of error pages that make your user smile.)
You guessed right – that was a timeout to the DB. Why did it happen? Who cares? It made your user wait and eventually it crashed the application. This is unacceptable!

How can we handle it?

There are two problems in this scenario: the first is that the application crashed and the second is that the user waited a minute for a response.
Let’s start from the crash. The navigation history is a cool and useful feature but it’s not the core of your system. The core feature is the navigation itself. You have to identify the core features of your application and make them work, even if some other features fail.
In this example, the application should have displayed an error message saying something like “History is currently unavailable – try to remember where you went” and allow the user to use its core features any way.
Now let’s deal with the fact that the user had to wait for a whole minute before he saw the error. That’s a horrible user experience. A timeout might happen due to many reasons in any sort of client server communication (no more available connections, waiting for a really long operation to finish or simply a stuck component).
The bottom line is that someday it will definitely happen to you! Furthermore it will cause all your users to wait until they receive the error. A timeout may accrue just once due to a race condition that only a single user will get. However, sometimes the timeout will remain until you manually fix the problem - which can take a while.
You can lower the timeout limit to a second or even 100ms - and indeed no user will wait longer than 100ms - but all the users will wait for 100ms and eventually fail, while choking your servers.
Your goal is to prevent users from waiting at all when you know they will definitely receive a timeout. In other words, if a system component has a timeout,  you don’t want the application to try to communicate with it. You want it to fail fast.

Fail Fast

Fail fast is a concept in fault tolerance systems that is designed to stop flows and normal operations when a possible failure might accrue. Such design will add check points before operations execution, which will check if the operation is “healthy”. Using “health indicators”, the system will know if a certain operation will most likely fail. If an operation isn’t healthy, then there’s no need to execute it and we’d rather call a fallback behavior.

This way, we may give the users a better experience then waiting for an error.
Let’s examine our case: the application shouldn’t try to execute the query unless the connection to the DB is “healthy”. So the system will check the “health indicator” before the execution, and if it returns false then it should immediately turn to the fallback and display the error page without even trying to connect to the DB.
You can take it even further – if such health indicators exist, then why can’t we check them on the application startup? If there’s a problem with the feature, then let’s disable it and even not show it to the user. Perhaps it’s better to make the feature “disappear” then exposing the user to a poor experience. That of course is a pure business decision (it might be a really poor experience if the messages tab in Facebook suddenly “disappears”).
Allowing your system automatically to disable features must be done extremely carefully. You don’t want to disable a feature for all of your users if for some reason a timeout has accrued just once. If it happened 10 times in a row, then most likely there is a real problem and only then should the feature be disabled.
 

Polly

Polly is a really cool and useful open source that helps you create a fault tolerant system using policies for handling exceptions and creating fallback solutions. Let’s see how we can use Polly to handle our timeout scenario and allow your application to fail fast.

NavigationHistoryController has a dependency to the database where the navigation history is stored.
It has a single public method, which provides the history by calling the INavigationHistoryProvider.
We have a try-catch surrounding the provider call. As we know this catch will eventually handle the timeout exception, but it won’t fail fast.

We have created a circuit breaker policy on the timeout exception (error code -2) setting the count to 10 and the policy duration for 10 minutes. In other words, our policy will be triggered if a SqlException will accrue 10 times and in the next 10 minutes every call to the provider will not be executed. BrokenCircuitException will be triggered instead, allowing us to quickly fallback and return an error without waiting for the timeout.

 

Let’s test it

We’ll mock the NavigationHistoryProvider and raise an exception for every single call to it “Get” method.
We’ll call it 10 times and then another time to check if the policy was activated.

Works like a charm. The code is available on GitHub.
 

Conclusion

The applications that we build will have failures. We must recognize that things won’t always fail nicely. We must be prepared for all the possible scenarios and edge cases. The sooner we start thinking about them in our development process – the better.
I encourage you to think about it from the beginning. Start using FDD – Fail-Driven Development.

Best of luck.