Software professionals usually can’t stand financial engineers. It’s not just that their code is bad and their manner strange, they are also pompous and often arrogant. The feeling of course is utterly mutual but in return the financial engineer throws derision into his hatred: he knows it’s harder to become a financial engineer than a software engineer and he knows he earns more. Continue reading

# Category Archives: software

# It's Not a Computer

Back in the day we had big computers, expensive things, and users took turns with them. For example, users – you could call them programmers – would gather their ideas on punch cards, patiently wait their turn, feed the cards into the computer and wait for the results. This time share may same strange to us, old fashioned, yet I’ve seen this pattern twice in my own lifetime. Firstly, Brendan, my brother, and I shared a Commodore 64. Our programs, collected on tapes this time, could only be fed into the machine one at a time. Secondly, as a student in Edinburgh, I shared a super computer with other students in exactly the same manner. Continue reading

# Trophic Taxonomy Of Testing

When I was doing my master’s degree in High Performance Computing, we knocked up a predator-prey simulation and connected it to a screen. Each prey was a green square, the predators were red, and I would guess that they were stored in a two-dimensional array, but I can’t actually remember. Continue reading

# Measure of Exploration

A quick note. Jorrit and I run a very (very!) successful company called Ugly Duckling. We run the company in the same way we help clients run their companies and teams. We use iterations, feedback analysis, have a strong focus on personal development, we set our moral compasses (although that can only ever be based on a personal sense of right and wrong), etc. Continue reading

# Quick Kata

I was messing about this morning and came across a Kata by Robert Martin. I am not sure about Katas. On the one hand, they are mechanical, teaching one to follow rules. You may be a black belt in doing Katas, for example, but come to my home town of Hull and that is meaningless in a town full of people who can fight. Katas also defy the heuristic that we should not program by coincidence. But, the Prime Factor Kata does show you how to improve the design of an algorithm and also how to move step-wise through the design space. I also didn’t really understand the algorithm but, after doing it a few times, I now do - it was a cheap and fun way to learn about integer factorisation. I suppose the trick is to do what works for you and don’t be afraid to mix things up. Remember, best practice is dogma, so use your own judgment. Continue reading

# Reflection on Software Engineering Metrics

Yesterday I discussed some ideas on software metrics and statistics with Michael Bolton. He suggested reading the Kaner and Bond (2004) paper on the subject. The paper asks many questions, it gets the reader thinking. It points out, rightfully, that the key question in any data gathering and processing quest is “What are we measuring?”. Although the paper is critical about the effectiveness of metrics, it does offer an example where gathering data proves to be useful:

One of the key release criteria for a project is an acceptably low count of significant, unfixed bugs. It is common, over the course of the project, for testers to find a few bugs at the start (while they're getting oriented), then lots of bugs, then fewer and fewer as the program stabilizes. The pattern is common enough that bug curves—graphs showing how many new bugs were found week by week, or how many bugs are unresolved week by week, or some other weekly variant—are in common use in the field.

-Kaner C., Bond W. (2004)

# Problem 8

I have just solved problem 8, I think, by cheating. Here it is:

Find the greatest product of five consecutive digits in the 1000-digit number. Continue reading

# Problem with this Design

I am working through 343 mathematical problems that are collected and presented as ‘Project Euler’. I had a quick look at them on Thursday evening. By Saturday evening, I realised that the puzzles come in (at least) two variations. Firstly, they are to do with asking a question of a number. For example, puzzle three:

The prime factors of 13195 are 5, 7, 13 and 29.

What is the largest prime factor of the number 600851475143? Continue reading

# Problem 2

Yesterday I found a collection of puzzles. I wondered what would happen if I worked through them all, one by one, with only 55 minutes - the time it takes for Dire Straits’ Brother in Arms to play - to solve them. Today, I am on problem two, which goes something like this:

Each new term in the Fibonacci sequence is generated by adding the previous two terms. By starting with 1 and 2, the first 10 terms will be:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...

By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.

The first thing that springs to mind is this: the conditional logic for this problem is to do with finding numbers that can be divided by two. Yesterday, I had to find numbers that could be divided by three or five. So, in my mind, some duplication is arising before I even start to type, which makes me think I will need some code that is an abstraction of ‘can be divided by X’. I will put that on my list (which is also in my head).

I start with trying to get a test passing for the first 10 numbers. From the sequence given - 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 - there are 3 even numbers: 2, 8, 34. If I add these together, I get 44. So my test looks like this:

@Test public void sumOfEvenNumbersInFibonacciSeriesTest() { assertEquals(44, sumOfEvenNumbersInFibonacciSeries(10)); }

I realise that if the series is only one long, the result will be 0, and so I add that test, too.

@Test public void sumOfEvenNumbersInFibonacciSeriesTest() { assertEquals(0, sumOfEvenNumbersInFibonacciSeries(1)); assertEquals(44, sumOfEvenNumbersInFibonacciSeries(10)); }

And off I go, generating the sequence, thinking about how the last two values should be added together. I get it working for the two cases. I change the test, randomly setting the size of the set to 1000.

@Test public void sumOfEvenNumbersInFibonacciSeriesTest() { assertEquals(0, sumOfEvenNumbersInFibonacciSeries(1)); assertEquals(44, sumOfEvenNumbersInFibonacciSeries(1000)); }

I get the following assertion error: java.lang.AssertionError: expected:<44> but was:<4613732>.

I submit to the website and:

Yeah! Now let’s look at the horror show that is my code.

private long sumOfEvenNumbersInFibonacciSeries(int sizeOfSeries) { if(sizeOfSeries==1) { return 0; } long sum = 2; int previous = 1; int current = 2; int i=2; while (i<sizeOfSeries) { if((current+previous) %2==0 && (current+previous < 4000000)) { sum = sum + current + previous; } else if (current+previous > 4000000) { break; } int temp = current; current = current + previous; previous = temp; i++; } return sum; }

The first things that jumps out are the break and return statements; these were me thinking out loud. Then there is the duplication of the summation of ‘current’ and ‘previous’. I clean up. (It is a truism of design that you can’t do it without a suit of tests, so I’ll try not to mention that too often.)

private long sumOfEvenNumbersInFibonacciSeries(int sizeOfSeries) { int sum = 0; if (sizeOfSeries > 1) { sum = 2; int previous = 1; int current = 2; int sumOfLastTwo = current + previous; for (int i = 2; i < sizeOfSeries && sumOfLastTwo < 4000000; i++) { if (sumOfLastTwo % 2 == 0) { sum = sum + sumOfLastTwo; } previous = current; current = sumOfLastTwo; sumOfLastTwo = current + previous; } } return sum; }

(I think this code is tidier, but certainly no work of art, there is too much lost information in the conditionals and even at the end where previous becomes current and current becomes the sum of the last two.)

**Conclusion
**The code works, I submitted it to the Project Euler website and it passed. But, as usual, getting code working is much more easier than getting it designed. When placed next to yesterday’s code, duplication is arising around loops and conditionals. I already suspected this. Project Euler was designed to make each problem a little bit harder than the last. This holds for design, too. As we pass through each problem, as we get the code to work, we can also pass through a number of phases of design as we remove duplication and tidy up the algorithms.

I got a solution today in about 15 or 20 minutes. But, as I reach the limits of my maths knowledge, I wonder if I can do it again tomorrow. To be continued.

# Problem 1

It’s 18:40. I was just about to wrap up for the day. I was scrolling through my twitter feed, said hello to @LisaCrispin, and then followed a link from @michaelbolton to an article called ‘How I Failed, Failed, and Finally Succeeded at Learning How to Code’. It spoke about a web-site called Project Euler, which was is a series of problems that a registered user can solve. Continue reading