Everybody working with scrum will be familiar with a burn-down chart. Showing all the work that is not yet DONE, thus pending.

We also tried this at first but soon discovered that it did not show us a lot about progress during the sprint because the burndown chart often looks like this:

Simply put: nothing is done in the beginning of the sprint because the team is busy on all the stuff, and only at the end of the sprint you start to see that things are done. Because only at the end of the sprint, the things are really done.

This is common when you are doing short cycle sprints, that is your sprints only take two or three weeks instead of two months. And you want your sprints to be short, so what is the use of a burndown chart than? Not much. Do we have something else? Sure we do.

The alternative: the burn-up chart.

Have a look at a burnUP chart below, taken from one of our sprints:

The lines on the burnup chart reflect the number of story points right of a particular column on the taskboard.

Monitoring progress goes much better when you measure tasks going through your process! This is as easy as counting the number of cards on your taskboard, or even better, counting the number of story points on the cards for each column you have on your task board.

Please note the small arrows on the taskboard below, at the top of some of the columns. I have added the red arrow, as that one was unfortunately missing in the picture below

Click on image for a larger view.

Cards should go from left to right towards the ‘done’ column. And if that is the case, your burnup will look like the burnup chart above.

However, when developers and testers are moving cards in the opposite direction, from right to left on the teams scrumboard, the graph might surprisingly look something like this:

It’s the green line, -all story points right of the test column- that has been decreasing for three days in a row!

This means that development work was considered done by developers, moved into the test column at first but when tested put back to the dev-column and thus something is going wrong in that process. Maybe the devs and the QA’s did not agree how the work should have been done? Seems that developers think they can put stories to the right from DEV to TEST and the ones who test the work are putting the cards back into the dev column! Above, the black ‘dev-line’ has been increasing as well meaning more work was picked up while earlier work was not approved…

Not good, and something to talk about in the daily standup!

The good news with the burn-up chart is: at least you now know what is happing during the sprint instead of only afterwards when you have your retrospective!

PS: The burnup chart is exactly the same as the CFD (Cumulative Flow Diagram) as discribed on this page but the benefit of drawing it as a burnup next to your scrumboard is that it is in everybodies face

Hi all, I would like to tell something about Scrum and how it is related to quality.

As Uwe Friedrichsen clearly pointed out on codecentric.de

Uwe Friedrichsen on #scrum:

Leider laufen ganz viele selbsternannte agile “Experten” und “Evangelisten” herum, die auf Konferenzen und anderweitig solche “Ihr seid das Team! Es zählt nur, was Ihr wollt! ‘Die’ haben Euch lange genug nicht ernst genommen! Nur Ihr seid wichtig! ‘Die da’ sollen gefälligst still sein und Euch machen lassen!” – Parolen als Opium unter das Entwickler-Volk streuen und sich entsprechender Beliebtheit erfreuen. 

That is, scrum is the opium of the developers community because it promises that we finally get time, as in being left alone, to produce quality software.

It’s a statement that I believe to be true. That is; developers do want to focus on their work to deliver quality software. The reality is that it goes both ways! If you turn the statement around:

If you can’t deliver quality then you can’t do scrum either.

What we realized when trying to introduce a fixed sprint lately is simply that you can not keep working only on the sprint tasks when the live product is not working as expected because of themprevious sprint. In our case it was as bad that it meant we had to do hotfixes and enhancements on the live sites as well as keeping pace on the current sprint. 

The reality is that that’s just not scrum. It’s kanban as best because hotfixes are just tasks that take over the top priority tasks of your current sprint. And that is exactly what happened in our last sprint. Have a look at this imaginary scrum task board.

Image of task board with a hotline on top.

We have got rows on our task board for each user story, sorted on priority.  The realization is that if your previous sprint had quality issues then your current sprint will have to deal with that earlier sprint one way or the other. Usually this involves heavy support patches and hot fixing.

The only way to get out of this loophole is to deliver quality. Only if the stories delivered are fully accepted and fully tested you will have somethig that’s shipable.

If you do not take the time or use the tools to deliver quality shipable software you will not reach scrum nirvana.

As I wrote just a few weeks ago in my blogpost going agile with scrum: the taskboard, a very important aspect of being a teamlead, or a ‘manager’ of a team is to be able to monitor the work so that you are able to look back afterwards.

So what does monitoring the work actually mean? Well it is not about letting your team members write their daily hour sheets. That’s just a boring exercise for knowledge workers and does not have any positive effect at all, especially if no feedback whatsoever is returned to the team for the careful registration of those hours.

Monitoring is useful only when the team can look back and have an effective retrospective. This will get the team far more self aware. Before having a retrospective it is important to know a few things about how to have such a meeting. A very good book about this is from Esther Derby and Diana Larsen:

I highly recommend reading it. It tells you how to conduct a retrospective. Set aside enough time for the meeting; get out of the workplace so that you can’t get distracted by the frantic software factory. The book is pact with practical advice and has a full set of examples activities that can be done during a retrospective meeting.

The retrospective….

To summarize, a retrospective has a few stages.
1) Setting the stage
2) Gathering data
3) Generate insights
4) Decide what to do
5) Close the retrospective

In our first retrospective I first set the stage by shortly explaining what the goal of a retrospective is. This can stir some emotions because of people being unclear about the goal; don’t get distracted, repeat the goals and continue

We then used the timeline activity to get a factual look back at what we did during the four weeks since we started an iteration of work. This was to gather the factual data.

a simple timeline, as an example

And because that timeline showed us how much we were actually busy with, namely lots of stuff, trying to handle multiple iterations at the same time as well as fire-fighting daily questions, it quickly made the team aware of the facts. It was hard to be focused as a team on one iteration when the other iterations were not finished yet! It’s hard to deliver quality when you have to jump from creating more features in the current iteration to helping testers getting earlier features out to production.

A good way to get an overview of the feelings was to set-up the next activity. We simply set-up a new flip over chart, divided that into two columns reading ‘glad’ on the left side and ‘mad/sad’ on the right.

What was the team (not) happy about?

The timeline chart -with lots of data scribbled on it- was hanging next to the new flip over for the generate insights activity.

This generated the insights into the feelings we, as a team, were having about looking back at the particular time frame. Starting the activity as a ‘brainstorm activity‘ (see chapter 6.1 of the book) challenging the team to come up with 50 ideas or positive/negative feelings we soon got the flip chart filled with ideas plus emotions about the work that we were doing. This led us to the next stage in the retrospective: Decide what to do. The activity: define some reachable actions.

We did not aim too high with our actions. I pressed that the first actions we wrote down had to be achievable and take away a daily burden that the team felt. The simple actions we took were to
help testers out and improve the standup meeting. Testers need to know what and how to test when issues are assigned to them. Also, we wanted to have a more effective and shorter standup meeting in the morning. This was because our morning meetings were going too far into the details and therefore took too long. The rules we made up for the team were that everybody should answer (only) the three usual standard questions of the daily-scrum, and keep within one minute each.

Retrospective activity: decide what to do.

So, the team decided that if you wanted to say more that is still possible, but only after everybody got to have its turn and the standup meeting was finished when everybody had her say. This means people are free to wander off if the detailed discussions are not relevant for their work that day.

Second thing related to the standup is we decided was that we realised that we need a better room for our taskboard where we were having the daily scrums. The taskboard is currently in a separate room where other people are doing their work. We want our board to be in our development-room, one way or another.

We did not forget the last stage of the retrospective: Closing. Everybody mentioned the ‘return on time invested’ and each individually said it was time very well spent: it’s good that as a team we took time to look back, spent some time on some frustrations and got happiness out of the things that are working well which we cherish, so to speak, like the time we invested in pair programming. In all, a succesfull retrospective it was!

……Seeing the patterns

Of course, the team saw much more that should be achieved than the actions that we choose in the decide what to do part of the retrospective. Some of the actions that are defined are the needs of the team. And those needs can be outside of the teams control. Here is where the teamleads and management gets into play. To get the team work at its full potential we need to get all burdens and obstacles out of the way and have the organisation communicate to the team in a clear way what needs to be the focus for the next iteration.

One of the authors of Agile Retrospectives: Making Good Teams Great Esther Derby, makes a clear point of this in a recent interview:

[...] a critical role for middle managers and working across the organization to make sure that the organizational systems are working. Instead of just looking down at what my individual team needs and looking up to see what my manager needs they need to be looking across the organization looking to the right and left of them and understanding how work flows through the organization and how to create and adjust those systems so the work flows smoothly to the team and the policies and procedures and structures in the company enable the team to self-organize [...]
see full interview on InfoQ

This of course is good stuff. As a teamlead / manager of the developmentteam one of the concrete ways to -at least try- to get more structure in the workflow, and thus iterations, is to be able to have clear ways of iterations, a backlog and make sure that when a new iteration can start, it’s clear what the team should work on. This means that before an iteration even starts we need to:

- Ask upfront priorities to stakeholders

That’s more easily said than done. Especially if the organisation switches its mind now and than about what is the most important thing to get delivered Anyway, whatever the priority that comes out, the team always needs to have clear goals by having:

- An organised backlog, keeping a wishlist of requested features and enhancements
- Up-to-date priorities: Ask the stakeholders to check and sort the backlog scenario’s based on priority, on a regular basis
- Feedback from delivered scenario’s: To keep spirit high the team needs to be energized by stakeholders on what was delivered.

And of course the team itself also wants to have a say on those priority lists; especially about what scenario’s in the backlog are easy to implement and which scenario’s aren’t or are seen as a waste of effort. A developmentteam needs to be part of the results; that’s what inspires and will come back as positive energy in retrospectives. Recognize a pattern already?

A mayor deficiency of our and perhaps any IT software department is that it seems we just can’t make clear to our stakeholders what the !@## we are doing. How familiar do these remarks sound from your business and marketing people to you? It might be the product owner who fires these questions:

- Hi Teamlead, who is going to work on feature X now?
- You want to go live in 6 weeks with this? What about 14 days?
- “But..? That feature should have been finished four weeks ago!”

These three examples are taken from real life; and no, I did not save these up from last few years, it’s just from the last few weeks… Is that a problem? Yes of course it is, and no, it’s not because our business people, marketeers or product owners don’t know anything about software development (well maybe), but the problem here is total lack of communication, publication, presentation and managing expectations about what the !@## it is that we are doing.

Should we make that more clear? Yes of course!

Point made? Great, but now how to solve that? How can you as a teamlead make clear what your team is doing? Here come scrum and agile to the rescue. It was only four weeks ago we decided that we had to change this now. So we finally started.

Looks neat, doesn’t it? And you only need a board and either sticky notes or in our case plastic-magnetic cards where you can write on with markers. Luckily, we had these available so we did not have to ask for any funding to do this. If you don’t have a board: get the physical strongest developers of your team, go round in your office building and just grab a board from someone else Just make it happen; you are the factory of your organisation and if you need it to get your factory going than everyone else will understand, right?

We also asked the whole team to read up on our skills with Kanban and scrum by Kniberg and Skarin. Read it! It’s a very good introduction.

So what do you see on the taskboard? We decided to start with five columns, from left to right these are:
- Analysis and design
- Ready for development
- In development
- Ready for dev-stable
- Ready for staging

To all software developers this will be easy to grasp. The leftmost column contains the items that still need to be thought about ‘how to implement’, and when that is ready we can move the item to ready-for-development. If a developer asks the teamlead for new work: she can pick up the task. Than the column in the middle in development. Here are the tasks that developers are currently working on. Basicly the middle column defines our capacity. When development is ready, we move the card to ready for dev-stable which means the software is to be integrated with other necessary modules and tested by a tester. And only if things have been approved on our dev-environment, we move the task-card to ‘ready for staging’, which is the environment where our stakeholders like marketeers or other business people who asked for the features test our work for the first time.

The last column also defines our definition of done.

Doing the standup at the taskboard helped us moving cards from left to right on the board on a daily basis; if there is no flow for certain work items it immediately can be discussed at the board and help is offered to each other.

Introduction of the taskboard is not really a big change in the way of working but having the work items visible instead of only in a stale issuelist on the screen helped a lot with our communication; also it is now impossible that items stay in the same process step without anyone noticing…

Third thing you need to do to effectively start agile and scrum: Keep track of the number of items in each column. Thus: Monitor progress.

Keeping track enables the team to have a retrospective
afterwards.

Earlier, we also kept track of progress by using the Agile estimation sheet that works very good but having workitems visible on a taskboard works even better!

We suddenly realised that we could not make all items that we thought we would realize. So what we did was: We simply took those off the board and than our bottleneck became very, very clear: integration-testing! Nothing got approved and the business was pressing us to start more work…. but we haven’t finished our current work yet. “We” as in we the organisation. We got that clear to our stakeholders and are pulling them into our testing process because our tester was occupied firefighting live issues. Testing: that’s where the factory needs help from the business!

Next time; a followup.. we have not yet done but will definitely do a retrospective
with the team when the major features of this iteration get released to our live websites….

Een snel javascript paginaatje voor je kind in groep 3:
Letterschuif!

of klik hier op letterschuif!

WII Sports table tennis is way cool! After alot of matches I finally reached the final stage, going crazy against the champion!

Unfortunately, lost the match with 6 to 1.. is it possible to beat the WII Sports table tennis champion?

a month later…

YES! It is possible! Won 7 to 5, it was a close match!

Must say that I did not use any of the tactics that I saw on other video’s on youtube; people who were able to smash the champion around; it was a very tactic game with lots of switches between back- and topspin. Especially the second topspin, totally aimed to the left, right after a few backspins were the trick; the champion could not reach those balls

Source code control is key to an effective team. Having multiple experienced developers in your team will also result in some developers working on different issues, some of which will take some more time to develop. And with the current frantic release pressures in the software factory and the risks involved in building new features you will have different developers work on different branches.

Don’t waste time having developers sit on their hands, just branch and code on! Therefore, branching is cool. Now if you use your source code control system to the full extent like we do, then as a teamlead you will eventually end up having to inform the team about all the branching and merging that goes on.

That’s ok, but how to communicate this effectively to your team? You might try to do that by simply sending an e-mail. Like this..

Hi all,

Kees volunteered to merge the 2.7.3 code changes (including the last 2.7.2 hotfix C changes that are in there) to the trunk. When that is finished, AND the trunk build is GREEN, only then we will create a 2.7.4 branch for the database-split. Meanwhile Henk also fixed a hot-issue on 2.7.3, which is then also to be merged to trunk (2.7.4 if it is there). And now that we are on STAGING with 2.7.3, All the fixes for 2.7.3 that will be needed are then also to be merged to both trunk / 2.7.4. Only if the 2.7.4 branch has been created, Gundi is allowed to change the trunk with all the experiences he has from the 2.8 Refactor branch, not sooner….

Thanks,
Melle
Teamlead

Well if your team of Kees, Henk and Gundi grasp these kinds of quick e-mail notes all praise to your team but it might be better if you take the time to draw a nice diagram with that.

Click on image for a redrawing of this image.

Now be honest: this is much clearer then the email, right?

The above example was used in our SVN based repository, but visibility is universal. You can use it both for a centralized based repository (CVS) like subversion and a decentralized/distributed version control system (DVCS) like Git. Have a look at another beautiful explanation of the git-branching model here. Visibility shows.

Making branching visible to your organisation

As developers we know what branching involves. We are so close to the code that we know from the top of our heads what functionality is in what branch-number. Sometimes developers even know what detailed issue-numbers are (not) in what branch. That’s all cool but we are writing the software for the entire organisation, our clients, not only ourselves. To make branching visible to your organisation it is vital to use clear names for your branches. Not in the version control system, but in the communication. That way it will be clear what functionality a certain branch contains. As an example:

• 2.7.2 hotfix C – CreditCard Entry
• 2.7.3 LowCost
• 2.7.4 database split

As you see, we try to attach a name with the version number that marketing and brand managers might will understand. Especially when a release to live is done the announcement of “2.7.3 is live!” will be too cryptic. “2.7.3 LowCost is live!” at least denotes the functional meaning of the release. Of course, releases often contain more then just one new item or fix. That means that it might be hard to come up with a proper name for a certain release; just pick the main feature in that case.

More links about branching:
Swapping release dates and thus swapping whole API changes is cumbersome. Martin Fowler has already written a very nice no-FeatureBranch article about that.

In an earlier post I already mentioned the importance of looking at the dependencies within your codebase. I used a beautifull small tool from Jamie Penney that could generate a file containing graph-information, that in turn could be used with the open source version of GraphViz to finally get a drawing of the project references.

Of course, that way of investigating your dependencies is quite cumbersome. If you need to look at dependencies for professional software, it’s time to use a professional tool like NDepend.

With NDepend you can add project assemblies by simply dragging them into the tool. For example, here is a picture that shows when I added a subset of projects from a very big framework application that we happen to use at work.

Pressing (F5) or will start the analysis of NDepend.

Now viewing a graph of dependencies does not, at first, show what I want:

Now after we pressed the ‘select graph‘ button you eventually will end up with something like this:

This way, you can actually find out what assemblies are relying on your infrastructure, and thus what domain assemblies still have to change so that those are infrastructure-independent.

Unfortunately, in the above graph there are some domain assemblies (maybe indirectly) dependent on NHibernate. The domain (like airtrade.business) should not depend on the infrastructure as that would give the domain a reason to change if the infrastructure changes as explained by Udi Dahan in his Fetching Strategy Post.

Not what we want. The domain should be able to change totally independent of the infrastructure. Getting out of this mess will mean trying to remove the dependency from the business domain assembly on NHibernate. Before that is possible, we might need to change a LOT of code… For example, as locations is also indirectly coupled with NHibernate, we might need to change code in that assembly as well before we can remove the link from business to NHibernate. Ouch! Luckily NDepend easily uses your PDB (program debug files) to enable clicking directly from NDepend into your source code! That sounds promising, doesn’t it?

Find out more on www.ndepend.com

Fast, less memory footprint. Works faster then XP on a 8 year old Dell Dimension 2400 pentium 4 machine, has sticky notes and a snipping-tool built in. What else do you need? Windows7 is great. No additional comments…

Somewhere in chapter seven of the book Beautiful Code the following challenge is given:

If you have never implemented binary search, or haven’t done so in a few years, I suggest you try that yourself before going forward; it will give you greater appreciation for what follows.

Well, binary search? What was that again? Well, it is explained before the challenge is given, let’s go back and read up:

As a quick refresher, a binary search is a simple and effective algorithm (but, as we’ll see, tricky to implement correctly) to determine whether a presorted array of numbers x[0..n-1] contains a target element t. If the array contains t, the program returns its position in the array; otherwise, it returns -1.

That looks easy. It means that if we have an array of numbers like this:

…let’s suppose our target is 12, the algorithm should return ’1′ as the index-value that contains our targetvalue. If our target was 11, the algorithm to be implemented should return -1, meaning no index could be found because the value could not be found in the sorted array. The problem is easy to describe and follow, indeed.

On with the book, it even describes the algorithm before challenging us:

Binary search solves the problem by keeping track of the range within the array that holds t (if t is anywhere in the array). Initially, the range is the entire array. The range is shrunk by comparing its middle element to t and discarding half the range. The process continues until t is discovered in the array or until the range in which it must lie is known to be empty.

Most programmers think that with the above description in hand, writing the code is easy. They are wrong. The only way to believe this is by putting down this column right now and writing the code yourself. Try it.

If you have never implemented binary search, or haven’t done so in a few years, I suggest you try that yourself before going forward; it will give you greater appreciation for what follows.

What? Not easy to implement? Of course, as an experienced programmer, I took on this challenge. But I’m warned, so I will not write the algorithm from the top-of-my head. I know that off-by-one errors can catch me, so let’s do this by using TDD. That means the first thing we do, is write a simple test that calls the (not yet written) algorithm, and checks if the algorithm works. Here we go with our ‘coding kata‘

Start coding all right!

With TDD, we start easy, so let’s simply start with a list of one item that holds our target.

 [TestFixture]
 public class BinarySearchTest
 {
   [Test]
   public void OneItem_TargetExists_Success()
   {
    int[] sortedArray = new int[1];
    int targetValue = 10; // this is our target
    sortedArray[0] = targetValue; // set value of first item to our target
 
    int targetIndex = MyBinarySearch.Execute(sortedArray, targetValue);
 
    Assert.AreEqual(0, targetIndex, "0 should have been the result!");
   }
}

The first implementation of MyBinarySearch is easy. With TDD, we keep our code as simple as possible to pass the test:

public static class MyBinarySearch
{
    public static int Execute(List<int> arrayList, int targetValue)
    {
        return 0; // just return the first index as result
    }
}

Well, in this case the code is too simple, that did not really do much as we did not even used the inserted array or even the targetValue at all! But that’s how we do it with TDD: start easy. The test is green, so let’s also add another test and refactor the code if necessary:

[Test]
public void OneItem_TargetDoesNotExists_Success()
{
   int[] sortedArray  = new int[1];
   int targetValue = 10; // this is our target
   sortedArray[0] = 20; // value will not be found 
   int targetIndex = MyBinarySearch.Execute(sortedArray, targetValue);
   Assert.AreEqual(-1, targetIndex, "-1 should have been the result!");
}
 
// running the above test results in a failure, so we
// refactor.
// We need to change the binarySearch class,
// to support the case for not-found:
public static class MyBinarySearch
{
    public static int Execute(int[] sortedArray, int targetValue)
    {
        if (sortedArray[0] == targetValue)
        {
            return 0;    
        }
        return -1; // target not found
 
    }
}

This still works, the value is either found or not-found, so it’s time to add some more tests! Let’s start by adding two tests that have lists of more then just one item. We keep it simple and add two tests with just two items:

[Test]
public void TwoItems_TargetExists_Success()
{
   int[] sortedArray = new [] { 10, 20 };
   int targetValue = 20; // this is our target
   int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
   Assert.AreEqual(1, targetIndex, "index 1 should have been the result!");
}
 
[Test]
public void TwoItems_TargetDoesNotExists_Success()
{
   int[] sortedArray = new[] { 10, 20 };
   int targetValue = 15; // this is our target
   int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
   Assert.AreEqual(-1, targetIndex, "-1 should have been the result!");
}

Ok, this is great. Both of these new tests will fail for sure! As you see, I have already prepared to go to a different Entry method, called.. Entry, instead of Execute. This is because our current BinarySearch class only works for lists of one item. Eventually, we have to do something smart anyway, and we already know that we have to dive deep because we need some kind of recursion, so that is why I want to enter the BinarySearch class with a different Entry method.

Let’s also add a third new test that actually uses an array of 100 items, and we want to find one target, something like this:

   [Test]
    public void HundredItems_TargetExists_Success()
    {
        int[] sortedArray = new int[100];
        for(int i=0;i<=99;i++)
        {
            sortedArray[i] = i;
        }
        int targetValue = 39;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(39, targetIndex, "Expected to find the target at index 39");
    }

This last added test will also fail with the current code, and just adding alot of if-statements in the MyBinarySearch class won’t work either. We will really need a recursive method before continuing.

Writing a recursive method to zoom-in

So how to write a recursive method? With recursion, we usually have an entry-method and the recursive method itself that is called from the Entry-method. As the description of binarySearch explains, the recursive method should ‘zoom-in’ into the sub-range of the array where the targetValue should be. To keep track of the subRange, we must have markers that tell us what is the lower-end of the subRange, as well as the higher-end of the subrange.

Also, a recursive method always needs a stop-condition, or else we might end up with an indefinite loop…let’s rewrite the MyBinarySearch class, and after that re-run all of the tests! People who have never seen a recursive method, one that calls into itself, might feel a little awkard reading the next code-bit, but the ones that have already written some recursive methods will not be too surprised with the following first try….

public static class MyBinarySearch
{
    public static int Entry(int[] sortedArray, int targetValue)
    {
        // determine low and high
        int low = 0;
        int high = sortedArray.Length - 1;
        return SearchTarget(sortedArray, targetValue, low, high);
    }
 
    // recursive method:
    // the return is the index of the targetvalue we search for,
    // or -1 if the targetvalue is not found
    public static int SearchTarget(int[] sortedArray, int targetValue, int low, int high)
    {
        // stop condition.. we re-use the earlier code of the Execute method:
        if (high <= low)
        {
            // range has shortened to (almost?) nothing:
            if (sortedArray[low] == targetValue)
            {
                return low; // index found!
            }        
            return -1; // target not found
        }
        // high > low means we can cut the range in half
        // but what half? the peakpoint should be the middle of low and high:
        int currentPeakPoint = (high - low)/2 + low;
        if (sortedArray[currentPeakPoint] < targetValue)
        {
            // we must search upper half:
            low = currentPeakPoint; 
            return SearchTarget(sortedArray, targetValue, low, high);
        }
        else
        {
            // we must search lower half:
            high = currentPeakPoint;
            return SearchTarget(sortedArray, targetValue, low, high);
        }
        // I do not expect we will ever get here:
        throw new Exception("something went wrong!");
    }

Ok, above is a first try. Of course, all tests need to be changed, they should now call the Entry() method instead of the Execute() method, that in turn will call the recursive method SearchTarget()…

So, I run the tests… but when I run my tests, I got a stack-overflow exception for the TwoItems_TargetExists_Success() test! How on earth did that happen?

Let’s debug… The code was continuously trying for the subRange 0..1, and again, 0..1, and again 0..1, the low-high-range was not altered at all. low did not get higher then 0, and high did not get lower then 1. in other words, ‘low’ was never increased. So the easiest thing to fix this is what I did below: I changed that one line of code from:

            low = currentPeakPoint; // <-- goes wrong
// to
            low = currentPeakPoint+1; 

And also added some debugging statements to see what was actually happening in the recursive loop, and found that I could refactor the internal call to SearchTarget at the end of the method a bit. It is not needed to call it in both the internal if…else.. branches, one time at the end is good enough. I ended up with the following recursive method:

 public static int SearchTarget(int[] sortedArray, int targetValue, int low, int high)
    {
        Console.WriteLine(string.Format("target {0}, low {1}, high {2}",targetValue,low,high));
        // stop condition
        if (high <= low)
        {
            if (sortedArray[low] == targetValue)
            {
                return low; // index found!
            }
            Console.WriteLine(string.Format("target {0} does not match value {1} at index {2}", targetValue, sortedArray[low], low));
            return -1; // target not found
        }
        // high > low means we can cut the range in half
        // but what half? the peakpoint should be the middle of low and high:
        int currentPeakPoint = (high - low)/2 + low;
        Console.WriteLine(string.Format("Peaking at:{0}",currentPeakPoint));
        if (sortedArray[currentPeakPoint] < targetValue)
        {
            // we must search upper half:
            low = currentPeakPoint +1; // this +1`I did not have at first.
        }
        else
        {
            // we must search lower half:
            high = currentPeakPoint;
        }
        return SearchTarget(sortedArray, targetValue, low, high);
    }

And, all tests green!

Even more tests!

Of course, I added more tests, this time real tests with larger lists, edge-cases, values that are outside the bounds of the sorted-array… just to be sure the method I wrote worked. But the additional tests never broke the code. I present all the other tests that I wrote here just for completeness-sake…

   [Test]
    public void HundredItems_TargetExists_Success()
    {
        int[] sortedArray = new int[100];
        for(int i=0;i<=99;i++)
        {
            sortedArray[i] = i;
        }
        int targetValue = 39;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(39, targetIndex, "Expected to find the target at index 39");
    }
 
    [Test]
    public void HundredItems_TargetDoesNotExists_Success()
    {
        int[] sortedArray = new int[100];
        for (int i = 0; i <= 99; i++)
        {
            sortedArray[i] = i;
        }
        int targetValue = 139;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(-1, targetIndex, "Expected to not find the target");
    }
 
    [Test]
    public void UnEvenItems_TargetExists_Success()
    {
        int[] sortedArray = new int[99];
        for (int i = 0; i <= 98; i++)
        {
            sortedArray[i] = i;
        }
        int targetValue = 50;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(sortedArray[targetIndex], targetValue, "Expected to find the target");
    }
 
    [Test]
    public void HundredItems_TargetDoesNotExists_ButWithinRange_Success()
    {
        int[] sortedArray = new int[100];
        for (int i = 0; i <= 99; i++)
        {
            sortedArray[i] = i*2;
        }
        int targetValue = 139;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(-1, targetIndex, "Expected to not find the target");
    }
 
 
 
    [Test]
    public void TenThousandItems_TargetExists_Success()
    {
        int[] sortedArray = new int[10000];
        for (int i = 0; i <= 9999; i++)
        {
            sortedArray[i] = i * 3;
        }
        int targetValue = 1234*3;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(sortedArray[targetIndex],targetValue, "Expected to find the target");
    }
 
 
    [Test]
    public void EdgeTargetLow_Success()
    {
        int[] sortedArray = new int[100];
        for (int i = 0; i <= 99; i++)
        {
            sortedArray[i] = i * 2;
        }
        int targetValue = 0;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(sortedArray[0], targetValue, "Expected to find the target");
    }
 
    [Test]
    public void EdgeTargetHigh_Success()
    {
        int[] sortedArray = new int[100];
        for (int i = 0; i <= 99; i++)
        {
            sortedArray[i] = i * 2;
        }
        int targetValue = 99 * 2;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(sortedArray[99], targetValue, "Expected to find the target");
    }
 
 
    [Test]
    public void TargetBelowLowest_DoesNotExist()
    {
        int[] sortedArray = new int[100];
        for (int i = 0; i <= 99; i++)
        {
            sortedArray[i] = i * 2;
        }
        int targetValue = -1;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(targetIndex,-1, "Expected to not find the target");
    }
 
    [Test]
    public void TargetAboveHighest_DoesNotExist()
    {
        int[] sortedArray = new int[100];
        for (int i = 0; i <= 99; i++)
        {
            sortedArray[i] = i * 2;
        }
        int targetValue = 99*2+1;
        int targetIndex = MyBinarySearch.Entry(sortedArray, targetValue);
        Assert.AreEqual(targetIndex, -1, "Expected to not find the target");
    }

And as an example, the satisfying output from the 10.000 search:

target 3702, low 0, high 9999
Peaking at:4999
target 3702, low 0, high 4999
Peaking at:2499
target 3702, low 0, high 2499
Peaking at:1249
target 3702, low 0, high 1249
Peaking at:624
target 3702, low 625, high 1249
Peaking at:937
target 3702, low 938, high 1249
Peaking at:1093
target 3702, low 1094, high 1249
Peaking at:1171
target 3702, low 1172, high 1249
Peaking at:1210
target 3702, low 1211, high 1249
Peaking at:1230
target 3702, low 1231, high 1249
Peaking at:1240
target 3702, low 1231, high 1240
Peaking at:1235
target 3702, low 1231, high 1235
Peaking at:1233
target 3702, low 1234, high 1235
Peaking at:1234
target 3702, low 1234, high 1234

With these tests, I’m pretty confident I was succesfull to the challenge I got from the book, and I’m happy to read on in Beautiful code…

After reading the chapter

I must say I was rather dissapointed. The presented solution was not using a recursive loop at all, but a for loop instead. While recursion is so elegant as you don’t need to take care of a stack yourself… oh well..
must say that except for a few chapters, the rest of the 30 chapters of the book were not that gleaming either. Most of the chapters are clearly from developers who are very proud of their code; that’s ok, but did they always keep their reader in mind?

And with this blog-article, you also have my review about the contents of the book… decide for yourselves! Beautiful Code: Leading Programmers Explain How They Think (Theory in Practice (O’Reilly)) (See all Computer Programmer Books)