Thursday, 5 June 2014

Secrets of Success from the Story of Bill Gates - Part 2


Never give up there is always a way out. Do what you are supposed to do; it will lead to bigger opportunities along the way.

If you can make up your mind that you will not settle for less, you will not settle for less. You will keep right on going and you will achieve your goals and dreams. If you convince yourself nothing is impossible, nothing will be impossible for you.

Don't concentrate on how hard it is but focus on the reward and satisfaction you get by achieving your goals.

Always focus on the final outcome from the start, never lose that ability to focus. As the road gets harder, you get harder; as the road gets tougher, you get tougher; as the journey becomes difficult and seems like it’s impossible, just continue to focus and keep going and watch what will happen. The only true failure is when you give up and you stop moving on.

Reward your progress when you reach a milestone.

Bring your best to every situation; you may never know when your breakthrough opportunity presents it to you. Persistence always pays off. Don't take rejections to heart or personally, it’s only a normal process of taking out what is not good for you. Persistence takes action.

The most successful people in life are always persistent. Persistent people are often accused of being cold and heartless, but a careful re-evaluation shows this is not the case at all, they are simply singled minded in their pursuit of their own personal destiny.

Wednesday, 4 June 2014

Secrets of Success from the Story of Bill Gates - Part 1

This is an very inspiring and motivational book: Secrets of Success from the Story of Bill Gates.

Bill Gates is a person that always inspired me and continue to inspired me. 

Bill Gates built Microsoft from scratch – he created the single most influential technology company of our modern age, and it made him so wealthy that he is now able to focus on the eradication of poverty and disease through the work of his charity foundation.

In 1994, Gates and his wife Melinda founded a charitable organisation called the Bill and Melinda Gates Foundation which supports initiatives in global health and education. The aim of the foundation is to eradicate poverty, disease and illiteracy from the world.

Bill Gates has received numerous international and national accolades, and honorary doctorates from the Royal Institute of Technology, Stockholm, Sweden in 2002, Waseda University, Tokyo, Japan in 2005, Harvard University in June 2007, and other universities. He was also made an honorary Knight Commander of the Order of the British Empire (KBE) from Queen Elizabeth II in 2005.

The book describes the key elements of  the history of the Bill Gates but he also introduce a lot of examples from other great people who are equally inspiring.

Tuesday, 3 June 2014

Learnings from software development coaching sessions

Back in November 2013 I wrote a post sharing with you my decision of being mentored by a friend and agile coach Matteo Baglini with the goal of exposing myself to agile engineering practises and become a better developer.

At the time, I promised to write posts about my learning but ultimately I didn't. So, it is time to start now!

First of all, I wish to thanks my manager Dom Smith in Red Gate Software to offer me the opportunity to have these sessions during working hours. This really offers me the ability to have sessions regularly every week.

In this post I will condensate the learning of the last few months of mentoring with links to the various resources that I read since then.

We started discussing TDD and the approach described by Kent beck:
  1. Write new code only if an automated test has failed
  2. Remove duplications
Duplication is the most important code smell and it can be hard to see. For this reason, sometimes it is useful to write verbose code just to help you find duplications.

I did the full Money example in the book TDD By Example exactly how Kent did it (with few changes as I did in C#) and deeply reflected on each step. I spent a full day to do it but it was worth the effort.

Learning well a refactoring tool like ReSharper is very important. However it is important to consider that the biggest advantages of a refactoring tool is not merely productivity:
  • Avoid the human error
  • Remove the context switch between using keyboard and mouse
  • Shorten the feedback loop by decreasing the time needed to refactor a piece of code
  • You can answer quickly questions like: Is the new design better?
Doing a kata multiple times without changing the solution to just focus in how you code and use refactoring tools is a very useful technique.

Here is a collection of very useful advices:

  • Check the error message when a test fail
  • Run tests often
  • After a refactoring run the tests
  • Avoid copy & paste as much as possible
  • When you find something to do, don't stop your current task. Add a note and do it later.
  • Don't stop the flow only to rename a method or a property! Add a note and do it later.
  • Primitive obsession can be often removed by introducing Value Objects
  • Sometimes you can add a test and comment it out in order to do necessary refactoring
  • Don't be too confident! Always use tests to validate what you are doing
  • Keep tests as stupid as possible. Limit test logic as much as possible!
  • In case of regression (red bar) never change test logic otherwise you won't know what was right
  • If you lose control, just slow down or discard changes and restart
  • Don't restrict yourself in a Top Down or Button up approach.
  • The code guides you. TDD is a feedback tool.
  • Consider adding code even if it is not strictly required to improve readability or simply to add symmetry
  • Some tests are simply tests to support you during development. You can remove them when other tests cover the same functionalities. Don't be afraid. 
  • Consider the "Copy Type" ReSharper command
  • The production code tests the tests!
  • Extract Method is a powerful refactoring tool
  • It is sometimes useful to make a private internal method public just for the sake of temporary writing unit tests but don't submit that code! Use it only to increase your knowledge about the problem.
  • Learn how to do small steps when needed.
  • A test is done only when duplication is eliminated!
  • Consider writing a test to force the creation of an object that we expect to need late but attention of not doing upfront design
  • Relying on the compiler can be a useful technique
  • If it takes a lot of time to make a test green... reflect!
  • Prefer static methods to factory classes when implementing the factory pattern
  • Getters are smells. Pay attention to not use objects as mere data structure.
  • Resist the temptation of not creating new classes... try, get feedback and see!
  • Observe the frequency of change. Change should be distributed among classes.
  • Use the Single Responsibility Principle to see pattern of change
  • The class who own the data should do the operation: Tell, Don't Ask!
  • In designing API it is best to offer a single way to do something. Make it simple!
  • Use the history in SCM to get insight about your project
  • Analyse temporal correlation of class changes
  • If you feel that something is annoying in the code base that is a sign of poor design.
  • Remain at the same level of abstraction within a test
  • Write a high level test and when you see the need to cover a lot of cases go down of one level of abstraction and write more specific unit tests.
  • You will often be pushing tests up and down between different levels of abstraction
  • Remember to not look inside the object when you do testing even on individual classes! Test the behaviour so that you can easily change the instance of the class with a new class but keep the tests intact.
  • Do not use TDD as a way to get permissions to write production code (that is cheating).
  • Do not be too enthusiastic about new technologies or methodologies. Slow down and reflect. There will be always a hype and later a fall. If you are pragmatic you can fall less.
  • Consider writing the assertion first

The essence of object orientation is thinking about behaviours

TDD test are always behavioural and at different level of abstraction. TDD can be done at different levels of zoom: it is sort of a dance between them. Unfortunately TDD has been often misunderstood and even attempts were made to fix this with ATDD and BDD. But these methods have often been identified with tools and things like Cucumber only create a new layer without bringing much value: having the on-site customer is far better than executable requirements that are a dream.

Pair programming helps a lot to keep focused and the role of navigators is supporting drivers in maintaining discipline and avoiding distractions

I and my mentor discussed many times about the Theory of Constraints and the importance of identifying bottlenecks in order to remove them. It is quite interesting to note that also humans can be a bottleneck and therefore an issue that can be addressed by increasing sharing. This can be done both with pair programming or with the Expert in Earshot pattern.

I never known exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests, Kent Beck
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it. I do tend to make sense of test errors, so I’m extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong. Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we’ll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order. Kent Beck

Monday, 2 June 2014

Stored Procedure to Calculate Expressions

I was reading the section Character Functions in the Chapter 2 of the book Querying Microsoft SQL Server 2012 and pretty soon I get bored of trying individually the various functions on strings available in T-SQL.

Then, I challenged myself to write a stored procedure (this is my first one) to evaluate an arithmetic expression with parenthesis and show the individual steps of the calculation. I wanted something generic but I added some restrictions to it after seeing how crazy is to implement a split function in T-SQL.

This is the stored procedure. I know, it is crazy and I am sure there are much better way of doing it. Remember that my goal was to just get confidence with the T-SQL functions on strings. Anyway, I am happy to receive feedback on it and see different way of implementing this behaviour.

This is the result of the execution.

It was fun :)