In this blog post I interview Davide Varvello, currently working as XP coach at 7Pixel. I’ve had the pleasure to work with Davide for a couple of years during the early 2000’s in Motorola; back then, he first introduced me to the practices of eXtreme Programming and Kent Beck’s books (ironically enough, at the time we were attending an internal training to apply CMM processes to our daily job as Motorola software developers – our center in Turin would have eventually been rated at CMM level 5 years later, long after Davide had left the company).
Stefano: Can you tell our readers a bit about yourself?
Davide: I’ve been fond of computers since the 80s, I had a Commodore 64 and I loved playing and programming with my friends even if they were better than me 
Next I turned my passion into a work, I've been busy with software for about 14 years wearing several hats: programmer, coach, mentor, tester.
The lovely thing about software building is that it's a creative activity like poetry or painting even if it does not follow the same goal. From an external point of view it's difficult to understand it, because a sw developer has always been seen like a guy struggling with weird numbers and cryptic algorithms, instead he is like a child with his modeling clay, taking care of it, pressing a bit, removing a bit to generate something new.
Stefano: How did you first get involved in Agile?
Davide: I think Agile is a forma mentis, it's not only linked to the will you have to improve the way of producing software, but it's the natural tendency to think how you see your life. I've always searched how to work better and I had an "Ah-ha" moment several years ago when I read an article of Bob Martin about changes in software requirements, I believe it was 1999 or 1998, anyway, Martin said requirements change 100% of the times and we, as sw engineer, should address that issue instead of wining. As I was facing a project with al lot of unclear requirements and with many changes, that words had a big impact on me. So I started to improve my technical skills and study more at night after work. At that time there was a lot of hype on XP and it was clear to me XP matched my ideas to build software. Through an ex-colleague of mine I met Francesco Cirillo who gave me a lot of spurs on studying something valuable for my work.
Stefano: What motivated you to become a coach?
Davide: Every Xprogrammer is an XP coach; every single development day you, as a programmer, are facing problems about how to implement some features: "is there a simpler way to do that?" "Is there a better test to implement?" "Ouch, that object doesn't behave in the right way, I have to fix it now." "Can I understand that deploy script?". All these questions rise every minute, what I like as a coach is to help the team to find a way to answer those issues.
Stefano: Can you describe what a typical day of a coach looks like?
Davide: It's like to be an alien on the Earth, you have to see and listen a lot: comments, postures, level of good noise, level of bad noise, flying questions, mechanical typing and… code, of course. I don't have a private office, my work is in the bullpen and I keep attention to that indicators, than I try to help the team to work together. It's not easy because people have consolidated habits and dynamics but, all together, we have to move from a local optima to a better one.
Stefano: What is the single most important factor within an organization to succeed with agile?
Davide: That's a good question. There is a no single answer, but there are four simplicity, communication, feedback and courage i.e. the Values. If a company or a slice of it is not ready to sustain those values, probably it will be precluded to the benefits that agile methods can produce.
Stefano: Have you found any connection between the platform/language a team uses and its success in agile?
Davide: Yep. If you are a professional and can embrace the values above, you are in the right direction, but there are technologies or languages that can match your expectations better than others, so they can make your work easier.
Let's take the value of feedback: you are considering a new language to study, you don't know anything about it, but there is some buzz on the net, so you give it a chance and start downloading the development environment; then you start with a tutorial, but unfortunately you face some show stoppers: you should configure this or that, you are constrained to compile and/or link whatever, you should validate something or throwing some mandatory exceptions to produce your first piece of new software, clearly that scenario does not work in the direction of a fast feedback.
So, it's not a secret I like a lot simple languages like Smalltalk.
Stefano: What final recommendations can you give to team who might want to try or just starting with agile?
Davide: The team members (in the whole) should be professional and disciplined, they should study a lot, start small and ask themselves the whys of every step in their working efforts. Organizing your work this way is a useful path towards improvement and it's fun too
Photo by Varnent
Now that with F# (and .NET 4.0 in general) we have support for big integers through the BigInteger type, Project Euler problem 13 has become a trivial one:
Work out the first ten digits of the sum of the following one-hundred 50-digit numbers.
37107287533902102798797998220837590246510135740250
46376937677490009712648124896970078050417018260538
74324986199524741059474233309513058123726617309629
…
53503534226472524250874054075591789781264330331690
Solution (note that I have removed most of the input numbers to improve readability):
#light
open System.Linq
open System.Numerics
let numbers =
[|37107287533902102798797998220837590246510135740250I;
46376937677490009712648124896970078050417018260538I;
74324986199524741059474233309513058123726617309629I;
...
53503534226472524250874054075591789781264330331690I|]
let solve_problem_13 () =
numbers
.Aggregate(0I, fun (x:BigInteger) (y:BigInteger) -> x + y)
.ToString().Substring(0, 10)
Using Linq, it's easy to compute the solution with a simple aggregation. Note that I couldn't use the Sum function directly because it does not have an overload for BigInteger type.
Without support for such big numbers, one could have reasoned that, in order to calculate the first 10 digits of the result, only the first 11 digits of each number are relevant. With this intuition, the problem would have been tractable using simple longs.
Parallel version
Problem 13 is a classical problem that can be resolved using parallel aggregation: it can be decomposed into many independent sub-tasks (each calculating the sum of 10 numbers, as an example) and the final result can be obtained aggregating the results from each of them.
With Linq AsParallel, scaling this problem on multiple cores is trivial:
let solve_problem_13 () =
numbers
.AsParallel() // MAKE IT PARALLEL!
.Aggregate(0I, fun (x:BigInteger) (y:BigInteger) -> x + y)
.ToString().Substring(0, 10)
Of course, with such a trivial problem, you should not expect big performance improvements with a parallel version (indeed, the overhead of splitting the work into different threads might usually lengthen the time it takes to get to the result).
See all Project Euler problems solutions.
After a brief digression with an RPN Calculator, here we are again with a new Project Euler problem:
The sequence of triangle numbers is generated by adding the natural numbers.
So the 7^(th) triangle number would be 1 + 2 + 3 + 4 + 5 + 6 + 7 = 28.
The first ten terms would be:
1, 3, 6, 10, 15, 21, 28, 36, 45, 55, …Let us list the factors of the first seven triangle numbers:
1: 1
3: 1,3
6: 1,2,3,6
10: 1,2,5,10
15: 1,3,5,15
21: 1,3,7,21
28: 1,2,4,7,14,28We can see that 28 is the first triangle number to have over five divisors.
What is the value of the first triangle number to have over five hundred divisors?
Again, this problem is relatively simple to solve and it's about finding an algorithm with decent performances.
The naive (slow) solution
#light
let triangles =
Seq.unfold (fun (acc, state) -> Some (acc, (state + acc, state + 1))) (0, 1)
|> Seq.skip 1 // skip the initial 0
let divides y x =
x % y = 0
let rec all_factors_slow_rec n i acc =
match i with
| 1 -> 1::acc
| x when divides x n -> all_factors_slow_rec n (x-1) (x::acc)
| _ -> all_factors_slow_rec n (i-1) acc
let all_factors_slow n =
all_factors_slow_rec n n []
let find_index m =
triangles
|> Seq.map all_factors_slow
|> Seq.tryFindIndex (fun x -> List.length x >= m)
let resolve_problem_12 =
let i = find_index 500
match i with
| None -> failwith "Cannot resolve problem"
| Some(i) ->
let list = triangles |> Seq.take (i+1) |> List.ofSeq
list.[i]
- Considering that triangle numbers are a mathematical sequence defined as follows:
where
, then we easily define an F# sequence that yields triangle numbers using
Seq.unfold. - We then define a function
all_factors_slow_recto calculate all factors (not just primes) of a given number. The slow solution presented in the first listing starts from a number n and then by brute force tries all the numbers down to 1 as a candidate factor. - Once we have these two pieces together, it's just a matter of enumerating all possible triangle numbers, finding for each their factors (using
Seq.map) and finally determining the first triangle number having at least 500 factors (usingSeq.tryFindIndex). Ifis the index of such a number, we then go back to the original sequence of triangles to extract the
element.
An improved version
#light
let divides y x =
x % y = 0
let triangles =
Seq.unfold (fun (acc, state) -> Some (acc, (state + acc, state + 1))) (0, 1)
|> Seq.skip 1 // skip the initial 0
let rec all_factors_quick_rec n i factors =
if divides i n then
let y = n / i
if (i < y) then
all_factors_quick_rec n (i + 1) (i::y::factors)
elif (i = y) then
// we have reached the square root value
i::factors
else
factors
elif i > int (sqrt (float n)) then
// we are beyond the square root value
factors
else
// try with the next number
all_factors_quick_rec n (i + 1) factors
let all_factors_quick n =
all_factors_quick_rec n 1 []
let find_index m =
triangles
|> Seq.map all_factors_quick
|> Seq.tryFindIndex (fun x -> List.length x >= m)
let resolve_problem_12 =
let i = find_index 500
match i with
| None -> failwith "Cannot resolve problem"
| Some(i) ->
let list = triangles |> Seq.take (i+1) |> List.ofSeq
list.[i]
The bottleneck of the previous solution is the naive approach to find all the factors of a number. On my machines this solution takes several minutes.
Better performances can be obtained observing that in order to determine all the factors of a number we don't have try all smaller numbers. As a matter of fact, the following is true (considering n the number to be factorized):
- if
, obviously both x and y are factors, so I don't have to probe y anymore
- If I start probing from 2 going up, I can stop probing when I have reached
. In fact, any number bigger than
Suppose for example that we have to factor the number 36 (one of the triangle numbers):
- 1 is always a factor -> factors = {1, 36}
- 2 * 18 = 36 -> factors = {1, 36, 2, 18}
- 3 * 12 = 36 -> factors = {1, 36, 2, 18, 3, 12 }
- 4 * 9 = 36 -> factors = {1, 36, 2, 18, 3, 12, 4, 9}
- 5 does not divide -> factors = {1, 36, 2, 18, 3, 12, 4, 9}
- 6 * 6 = 36 -> factors = {1, 36, 2, 18, 3, 12, 4, 9, 6}
We can stop here because if 7 divided 36 evenly, we would have already found a number x < 6 such that 7 * x = 36.
The improved version runs on my machine in less than 1 second.
See all Project Euler problems solutions.
