This video was recorded at Agile Lean Europe (ALE) Unconference 2014 in Krakow.
Olaf talks about how we could increase trust in our organizations by considering that the people we work with are adults. Another topic is de-scaling organizations, so that the people have a happy working place where they can take decisions and further more, they are invited to take decisions.
James Shore is one of the promoters of TDD in Javascript. He is presenting codecasts on his website Let’s Code Javascript about how to work effectively in Javascript.
As James says:
“JavaScript Needs Test-Driven Development
If you’ve programmed in JavaScript, you know that it’s an… interesting… language. Don’t get me wrong: I love JavaScript. I love its first-class functions, the intensive VM competition among browser makers, and how it makes the web come alive. It definitely has its good parts.
It also has some not-so-good parts. Whether it’s browser DOMs, automatic semicolon insertion, or an object model with a split personality, everyone’s had some part of JavaScript bite them in the butt at some point. That’s why using test-driven development is so important.”
During the last five years or so I have been travelling Europe and meeting a lot of people in local communities of practice. My main purpose is to teach the local groups and to learn…
This video is the opening keynote from Agile Lean Europe (ALE) Unconference in 2011, Berlin.
Rachel Davies gives an idea on how Agile works at the moment, and how we cannot really do agile scaling in big enterprises.
Dependency Inversion – code cast Blog post series This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions…
Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk. You are a programmer. Someone from the company…
Basic Rules of Refactoring – code cast Blog post series This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see…
Add feature on legacy code – code cast Blog post series This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to…
This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.
When writing unit tests on legacy code, we often discover behaviours of the system that seem wrong. The main rule is: DO NOT change the production code without being absolutely sure that the change does not introduce defects. Instead we need to mark all the tests that characterize a possible defective behaviour. Let’s look at some ways to document possible defects with tests.
This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.
In the previous episode post we extracted a class. The code we just extracted is tested at this moment only with System Tests. Now it’s the time to start writing unit tests, considering that we already have some system tests in place.
This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.
When working with existing code we need to look at the responsibilities of existing classes. If one class is too big, we need to extract new classes from that initial class. A class too big means that it’s not respecting the Single Responsibility Principle.
This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.
The rule of three says:
Extract duplication only when you see it the third time.
This concept is extremely useful when you want to improve legacy code, refactor in the TDD cycle or just improve existing code that is covered by tests.
The Rule of Three brings higher coherence and more clarity to the system, because the duplicated code starts to be moved into specialized areas. In this way we optimize the code base for changeability.
The Rule of Three prevents from prematurely extracting possible duplication and defers the duplication minimization until we have enough proof.
