Blog has moved to softwareramblings.com

This blog has relocated to its new home at http://softwareramblings.com. The move should be transparent to subscribers of the feedburner feed. Please update bookmarks etc. to point to the new location.

Thread Affinity on OS X

My first experience in developing software to run on OS X has been a disappointing one. Previously, I have written software to run on Windows and Linux and in general I have found library or system API calls that provide me with the ability to access the services that I expect to be provided by the operating system. One such service is thread affinity - i.e. the ability to tie a particular thread to a given core. This is achieved using SetThreadAffinityMask() on Windows and sched_setaffinity() on Linux. However, I was very surprised to find that it does not appear to be possible to do this on OS X! 

OS X Leopard introduced a thread affinity API which provides the ability to provide affinity hints to the scheduler to improve data locality in caches. Unfortunately this API does not provide the ability to tie a thread to a core. This is a major gap, especially now that all new PCs and laptops are multi-core. 

So why do I want to be able to tie a thread to a core? I want to benchmark a piece of code and one of the data points of interest is to benchmark this code on a single core. With the current Mac OS X thread affinity API, this is not possible!

I'm finding it hard to believe that this service does not exist on OS X - I mean surely somebody must have wanted to run a single core benchmark on OS X running on a multi-core system. But after a couple of hours of googling and reading through the OS X APIs I have been unable to find out how to do this.

Coding The Architecture

I stumbled upon Coding the Architecture and found it to be a very refreshing and pragmatic view to software architecture and to the role of a software architect. I generally find that sites, blogs and articles on software architecture tend to focus on presenting a specific architectural process, modeling tool or on the latest trend in software architecture. Trying to find down to earth, practical advice on how to set oneself up for success as a software architect has proven difficult - until now. 

After browsing through some of the blog entries on the site and from one of its user groups, I am reminded of the resonant style of the Pragmatic Programmer book. It has the same practical and pragmatic feel. 

Some entries / articles that I found interesting:

• What is a Software Architect?
• Role profile for software architects
• Sharing Architectures
• Software Architecture Document Guidelines

ToDo Lists

Where would we be without ToDo lists? They have found their use in everything from keeping track of simple errands to keeping track of outstanding tasks in large scale projects. I find them an integral part of my day to day work and so over the years, I've tried out various ToDo list applications to try and find the one that the right fit for me.

I am constantly amazed by the vast number of different applications for managing ToDo lists that have emerged. They range from very simple single list tools, to complex tools that are more suited towards project management than they are for keeping track of what to get during the next visit to the shops.

ToDo list applications need to feel right when you are using them. I have all too often had the experience of trying out a particular ToDo list application only to find that it constrains my usage model in some way. I then spend a couple of days/weeks trying to adapt my usage model to the constraints and model offered by the application. I eventually get too frustrated and give up. I am convinced at this stage that different people are tuned to different ToDo list application features and that there is no one "ToDo list model" that fits all. In spite of this, I believe that I have found the magic ToDo list application that seems to fit most usage models - or at least it doesn't provide any constraints about how to manage your ToDo lists so you have the freedom to manage them whatever way you like.

After trying 20+ different applications over the past 10 or so years, I constantly return to Abstract Spoon's ToDoList application. This is without doubt one of the most flexible ToDo list managers out there and it acquires new features at a fast pace. This application really defines the meaning of feature rich. I have used it successfully for managing simple lists, project scheduling, time tracking, and SCRUM backlogs, burndown charts and even for online SCRUM boards. It is difficult to describe its feature list in a simple blog post so I encourage you to download it and give it a twirl.

The only downside that I have encountered with this particular application is that it is Windows specific. I'm sure that ports of this application to different OSes will occur with time but for the moment the cost of its excellent flexibility is only being able to use it on your Windows box(es).

Visual C++ 2008 Feature Pack Released

Previous posts have mentioned the Visual C++ 2008 feature pack which was available as a beta release. The full version has been released and is available for download. 

The previously reported bug with array::max_size() has now been fixed.

Some TR1 related resources from Microsoft:

• TR1 documentation
• Channel 9: Digging into TR1
• TR1 slide decks

C++ Lambda Functions

A previous post showed a code snippet for dumping the contents of an STL container using an ostream_iterator. Things have now gotten a little bit easier with the introduction of lambda functions into the upcoming C++0x standard. Lambda functions allow pieces of code to be passed around as if they were ordinary objects. Applying lambda functions for dumping the contents of an STL container gives:



vector<int> v(10);
generate(v.begin(), v.end(), rand);
for_each(v.begin(), v.end(), 
    [](int& x){ cout << x << " ";}); 

OK, so the syntax looks a bit strange at first, but it does add a powerful construct to the language.

Lambdas have only just been added to the C++0x standard and support for lambdas are not included in the beta version of the Visual Studio 2008 TR1 feature pack.

For more details and examples of lambda functions, check out Herb Sutter's recent trip report from the February/March ISO C++ standards meeting.

C++ TR1: stdint.h still missing from Visual Studio

stdint.h is a disappointing absence from both Visual Studio 2008 and the TR1 feature pack. This header was introduced in the C99 standard library to allow programmers to write more portable code by providing a set of typedefs that specify exact-width integer types, together with the defined minimum and maximum allowable values for each type. This standardized the approach for writing such things as uint32_t and should save countless hours of needless duplication for projects that like to define their own variants such as uint32, UINT32, u32, Xyz32U, etc.

Since the C++ standard was finalized in 1998, it missed this standard header by a year. In the latest update to the C++ standard (namely those extensions covered in TR1), support for this header has been added in the form of the cstdint header.

It is astonishing to find that a header that was standardized 9 years ago has still not made its way into Visual Studio 2008. Not even the recent feature pack beta which included support for most of the TR1 extensions, contained stdint.h! The lack of support for this header was logged as a bug with Microsoft way back in 2005 but is still in the "postponed" bucket.

Thankfully, there are a number of implementations of stdint.h available, the most notable being Paul Hsieh's cross-platform free implementation and also a Microsoft compiler specific implementation. Simply place one of these implementations into the Visual Studio standard include paths and stdint.h support magically appears ... now why can't Microsoft do something like that!

C++ TR1: array VS 2008 Bug

Microsoft have recently released a Beta version of the Visual Studio 2008 Feature Pack which includes support for most of the C++ standard library extensions described in TR1. Alas, the beta sticker is appropriate as there are still some bugs to be ironed out.

The TR1 array container template provides functionality for implementing a fixed size array. This is a halfway point between plain old C style arrays and C++ STL vectors. The defining property of the array container is that its size is fixed. Consider and example of an array of 4 integers:

array<int,4> = { 0, 1, 2, 3 };

Since it adheres to the STL container rules, it must implement methods such as size(), and max_size(). For the array container, both of these should return the size of the array, which is fixed. In the above example, both should return 4. However, when using the VS 2008 TR1 implementation of array, a bug appears. The code:

#include <iostream>
#include <array>
using namespace std;
using namespace std::tr1;
int main()
{
    array<int, 4> arr = {1, 2, 3, 4};

    cout << "size: " << arr.size() << endl;
    cout << "max_size: " << arr.max_size() 
         << endl;
    return 0;
}

Produces the output:

size: 4
max_size: 1073741823

instead of:

size: 4
max_size: 4

If we take a look at the implementation of max_size() we can see the problem

size_type max_size() const
{    // return maximum possible length of sequence
    size_type _Count = (size_type)(-1) / sizeof(_Ty);

    return (0 < _Count ? _Count : 1);
}

Instead of simply retuning N (the size of the array), it performs the same computation as if this was a vector.

This issue has been logged as a bug with Microsoft and will hopefully be fixed before the "Gold" release of the feature pack.

C++ TR1

Effective C++, Third Edition summarizes TR1 this way:

TR1 ("Technical Report 1") is a specification for new functionality being added to C++'s standard library. This functionality takes the form of new class and function templates for things like hash tables, reference-counting smart pointers, regular expressions, and more. TR1 itself is just a document.

The TR1 draft does not contain any background information on the functionality it provides and doesn't contain any examples for how it should be used. For this sort of information refer to the proposal documents which were used to define the TR1 functionality. The relevant proposal documents are nicely catalogued by Scott Myers.

Microsoft have recently released a Beta version of the Visual Studio 2008 Feature Pack which includes support for most of the C++ standard library extensions described in TR1.

GCC v4.x also provides support for most of the extensions.

Over the next few weeks (more likely months) I plan on playing with the new TR1 features and I will add thoughts, learnings and code snippets to this blog.

Effective Concurrency ... so far

Following on from a previous post about The Pillars of Concurrency, here are links to the full set of Herb Sutters "Effective Concurrency" column topics (as of Feb 2008) ...

The Pillars of Concurrency
How Much Scalability Do You Have or Need?
Use Critical Sections (Preferably Locks) to Eliminate Races
Apply Critical Sections Consistently Avoid Calling Unknown Code While Inside a Critical Section
Use Lock Hierarchies to Avoid Deadlock
Break Amdahl's Law!
Going Superlinear

These are an excellent set of articles on the subject of concurrency and programming for multi-core that analyzes the many facets of the subject - from background theory, to locking and on to achieving scalability and performance.

Hiring Good Programmers

The company that I work for is currently embarking on a hiring spree. So I thought it would be a good idea to refresh my interviewing skills before I launch myself into the hiring process.

A recent Coding Horror entry highlights "The Years of experience myth" which is the inadequacy of trying to "match-- exactly and to the letter-- some highly specific laundry list of skills". Unfortunately when dealing with some recruitment agencies, I find this an all too common practice. Instead it is vital to remember that "... what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language -- and serving them up interesting projects they can engage with."

Joel Spolsky sums up the characteristics that employers should be looking for in future employees as "Smart and Gets Things Done".

So, now that we've figured out what to look for in a candidate, lets look at some resources that give tips for screening CVs, conducting phone screens or face to face interviews.

• The Guerilla Guide To Interviewing - Joel Spolsky gives practical and pragmatic advice on the whole process.
• Getting the Interview Phone Screen Right - because its very expensive to get it wrong.
• The Five Essential Phone-Screen Questions

And finally since the phone screen is probably the most important stage, it's worth highlighting the two common critical mistakes that an interviewer could make in the phone screen:

1. Don't let the candidate drive the interview. The interviewer should do most of the talking, guiding the conversation along until they're satisfied the candidate knows the answers to the questions (or has given up).
2. Watch out for one-trick ponies. Candidates who only know one particular language or programming environment, and protest complete ignorance of everything else, are a giant red warning flag.

» 10 techniques for gathering requirements | 10 Things | TechRepublic.com

A nice concise list of various ways to gather requirements:
» 10 techniques for gathering requirements 10 Things TechRepublic.com

When doing interviews of JAD sessions for the purposes of gathering requirements, try to ensure that you are in the same meeting room as the participants. This helps to build up a raport with the participants which generally leads to a more open dicussion which helps to produce better requirements.

Don't forget the 5 whys approach when gathering requirements. Often what a customer says he wants is different to what he needs. Dig into each requirement to fully understand why this is valuable to the customer and then ensure that the requirement is aimed at solving the root cause of the customers problem.

Is Java becoming the new Cobol?

Apparently Java is becoming the new Cobol. It comes as no surprise that .Net has emerged as the contender to to Java's throne - especially given the Miucrosoft muscle supporting and driving it. It is also pleasing to see that Ruby and Rails is emerging as a contender also. It is also pleasing to see that Microsoft are supporting the development of Ruby with its IronRuby effort to allow Ruby to run on a .Net platform.

However, Java like Cobol has built a lot of infrastructure in enterprise environments and I'm sure that this will give Java some stickiness for considerable time yet.

Reading that article makes me wonder if it will become harder and harder for new languages and computing paradigms to emerge as time goes on? Does each new language or platform need to build a weight of infrastructural components in order for it to be a successful contender for the throne? I hope not and hopefully Ruby is the latest example of a language that works and is popularised simply because developers love it!

5 Generic Debugging Tips

These are some practical tips to help maximise your chances of success when debugging software problems - especially those hard to isolate problems. Most of these tips will seem like common sense but I am constantly amazed at how often they are overlooked! I've deliberately tried to keep these at a generic level and not tie them to a specific language so that they may be of relevance to most people.

1. Think: If you can quickly build and test your application there is often the temptation to keep trying things until the bug goes away. It is easy to get caught up in a cycle of "make a change - build - test (fail) - make another change ..." without really stopping to catch your breath. The danger with this approach is that when the bug goes away it is sometimes difficult to tell if the bug is fixed or if you have just solved a symptom. Although frustrating, it is sometimes a learning experience to have to debug an application or system that takes a long time to rebuild and test. This forces you to take a step back and to think carefully about what you can glean from your current data and what the next step should be. This will help you to better understand the nature of the problem and in doing so it will help to find the root cause more quickly.
2. Baby Steps: This is a really obvious but often overlooked practice. When debugging always take baby steps and only change one thing between tests. It is often very tempting to make a couple of changes or to skip a step, but this invariably results in an inconclusive test result and you will end up backtracking to figure out which change caused a change in behavior.
3. Simplify: Try and reproduce a suspect piece of code in a stand-alone environment. For example if a particular algorithm is miss-behaving, try and replicate this behavior in a simple application that only contains the algorithm and may be easier to control and debug. Similarly, if debugging issues in a kernel, it is often possible to replicate the code at a user level which is a much more friendly debug environment.
4. Tools: Become intimately familiar with your tool chain. Take time to learn the power and quirks of your unit test environment, debugger, memory leak checker, compiler, etc. If you develop on multiple platforms and use different tool chains on those platforms then learn them all!
5. Challenge Assumptions: Assumptions can be dangerous. How many times have you assumed that a particular piece of code is working only to find you many hours later that it contained the bug that was the root cause of the issue you were debugging or that it behaved subtly different than what you expected? In general it is good practice to assume nothing and to challenge all assumptions that you find yourself making.

Splitting large Scrum teams

Once upon a time we decided to use SCRUM as part of our development process. Since its introduction in our team, we have had a number of successful projects and we all think its the best thing since sliced bread. We love the fact that the entire team meet for a few minutes each day and think that it provides an effective means of communication between the team members.

Over time our team size has increased from about 4-5 to a whopping 15. We still practice SCRUM but I don't get as much out of it as I did when we had a smaller team size. Apart from the fact that it's difficult to get a space for our stand up meetings that can accomodate the entire team and still be able to hear everybody, I find it hard to keep tuned in to what everybody is saying. There is some pressure to stick to a single SCRUM for the entire team and not split into sub-teams. The rationale is to keep the daily stand up meeting as a communication channel between the entire team. So there are two problems:

1. How to improve the communication within the single large team to make it more effective
2. How to keep good communication across sub-teams and multiple SCRUM groups

Here is what I found from researching the problem:

How to improve the communication within a large SCRUM team?

• Hyperproductivity In Large Projects Though Distributed Scrum - relates to SCRUMs between distributed team members but the team size was 59!!!!
• Hmmm, there seems to be a lack of advice here! The only advice that I could find was to split the team into smaller sub-teams - the "scrum of scrums"!

How to keep good communication across sub-teams and multiple SCRUM groups?

• Historical data that suggests keeping the SCRUM team size under under 7
• The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information
• Inefficiencies and large teams - "Two common pitfalls for crowded teams: miscommunication and lack of motivation"
• How to organize work and structure a project with multiple teams: Let small teams focus on solutions to specific problems and coordinate activity between teams.
• Scrum of Scrums

I guess the tactical approach to convincing the team to move towards smaller sub-teams and multiple SCRUMs is to point out that the larger team size is reducing the effectiveness of communication within the team. However, this must quickly be followed up with evidence that co-ordination and interaction between the smaller teams can address the communication gap caused by the split. To this end, I think I like the idea of the scrum of scrums approach where there are multiple scrum teams, and one member of each team attends a SCRUM with one member from each of the other teams. In effect this one team member becomes the communication channel between the teams.

Always an apprentice?

With the rate at which new software languages and technologies are appearing, its a tough job for a software engineer to keep up with the latest developments and trends as well as keeping existing skills sharp. Just as you feel you master one language or technology, a new one comes along and your apprenticeship starts over in this new field.

One of the best ways that I have found to both learn new languages/skills and to keep existing skills sharp is to practice each skill as much as possible. For programming languages this means regularly writing pieces of code in each language in the toolbox. I try to use each language that I know at least once a month for languages that I have become proficient in and at least once a week for languages that I am learning.

Dave Thomas describes this concept in greater detail in his CodeKata series.

I find the use of programming puzzles and challenges as excellent ways to find concise coding exercises that don't soak up to much time but yet provide opportunities to hone & develop skills as well as often providing opportunities to learn about new libraries, packages, algorithms etc.

Some of the best coding problem / challenge sites that I use are:
http://codekata.pragprog.com/
http://www.pythonchallenge.com/
http://www.topcoder.com/

Simple container dump using STL iterator

Quick and dirty printing of containers contents in C++ using STL ostream_iterator ...

#include <iostream>
#include <algorithm>
#include <vector>

using namespace std;

int main()
{
    vector<int> v(10);
    generate(v.begin(), v.end(), rand);

    copy(v.begin(), v.end(), 
        ostream_iterator<int>(cout, "\n"));
    return 0;
}

Pillars of Concurrency

Excellent article on decomposing and categorizing concurrency traits by Herb Sutter ... http://www.ddj.com/dept/cpp/200001985

The three "pillars" identified in the article:

1. Responsiveness and Isolation Via Asynchronous Agents
2. Throughput and Scalability Via Concurrent Collections
3. Consistency Via Safely Shared Resources

An interesting reference from this article is to an earlier article from Herb illustrating why lock based programming is hard and insufficient: http://www.ddj.com/dept/cpp/184401930