Andrea Angella, Software is my passion.: June 2014

Persistence

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.

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:

Write new code only if an automated test has failed
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.

Quotations:

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

Resources: