Do programmers need to learn to program for multi-core?

Much has been written on the inability of the need for future applications to take advantage of dual-core and multi-core systems. I think most of it is hogwash.

Intel is a big proponent of the argument for more parallel-processing tools for programmers. This is no big surprise - Moore's law has flattened out for the current generation of processors. They are expanding outwards to multiple cores now, no longer upwards to higher CPU speeds. Intel is understandably terrified that their PC CPU market demand is going to dry up. Its all marketing.

I prefer to look at reality.

Looking at whats running on my system, these are the some threading stats:

• Firefox - 18 threads
• Outlook - 31 threads
• Perforce P4V - 8 threads
• Custom .NET application - 13 threads

Seems like plenty of threading goodness is already going on.

Taking the example of the custom .NET application, there is a very noticeable performance hit when I run it within a virtual machine. I attribute this to the virtual environment only making use of a single processing core. Those 13 threads have to fight over the single processor. In addition, the .NET runtime (garbage collection etc) is highly concurrent - when running on a single-processor environment, it is crippled.

I am not arguing that all application threads are particularly busy. Truth be told, of the 13 threads, only one, sometimes 2-3 are ever particularly busy. I'm just saying that there are as many threads as are necessary to get the job done. As programmers, we need not care at all about multi-core, except where there is some advantage to be had in using it.

Applications are written do as many simultaneous things as the user expects. It has nothing to do with multi-core as to whether there are multiple threads - it has to do with what the user expects and what the application needs to do to meet those expectations.

Multiple CPUs are like RAM - you will never have enough for tomorrow's needs. Heck, you can barely run Vista without a dual-core machine - the OS itself has too much going on to leave enough over for decent performance. Multi-core PCs are here to stay, but as programmers it is simply a case of "nothing to see here - move along".

On Values, Principles and Practices, and the suckiness of Project Management

I mentioned a few posts ago that I really liked the quote from Kent Beck

It is about values, out of which flow principles, out of which flow practices.

Some recent online discussions have made it clearer why this is. Values are things that we can all share. As a business analyst or a software architect, I can talk to a client about the value of long-term maintainability of the code, or the value of time-to-market, or the value of high initial quality, or the value of low development cost, or the value of a certain set of core features, or the value of performance measures.

As an experienced software professional, I can choose principles and practices that support the values that a client is interested in. I can explain to a client that there is a cost to applying certain practices, and he may have to weigh one value (e.g. maintainability) against another (e.g. time-to-market).

I use my own judgment in these tradeoffs, but I would much rather use hard-data. I think as an industry, software development can mature if we get serious about identifying the various practices, their relative costs and their relationship with the values that a client is interested in. But that cannot happen yet, and I'll tell you why...

The iron triangle of project management grossly misrepresents the trade-offs, because it only understands the values of Time, Cost and Scope. You want to know why software quality is low? Because it has no choice - simplistic project management will steal from quality to pay scope or cost or time. Developers have very little real control over quality.

Some have suggested adding a fourth "quality" side to the triangle, or turning it into a pyramid. This misses the point. There are things that the client values. These are the things that we have to balance against each other to find the path to a successful project. Sorry, its just not as simple as a polygon of any fixed number of sides.

It has been left to the developers to try and motivate good practices that support other values, but only be able to apply them if they can do so without affecting the golden project management values. The end-result is that less good practices are used, and many developers fight against good practices as much as project managers.

The failure of SQL

I've been using relational databases for some time now - in fact, its the only type of database I've used professionally. I've even had a go at writing my own.

Over the years, relational databases have not substantially changed. Sure, they manage themselves a bit better, and there are a few more data types (xml), but basically the way they expose the data is unchanged.

I would like to suggest that this model (exposed via the SQL language) is missing a major piece. Adding this piece would make the SQL language much more approachable, and make databases more self-documenting.

The missing piece is "relationships". Its hard to believe, but relational database do not treat relationships as first-order objects. How would doing so change things? Well consider the following valid SQL query:

SELECT oi.*
FROM orders o
INNER JOIN orderItems oi ON o.Id = oi.OrderId
WHERE o.Number = 123

Notice how I had to specify the details of the relationship (the INNER JOIN line). Now consider what would happen if SQL had named the the relationship "Items". To be clear, the following SQL is not valid today:

SELECT orders.Items.*
WHERE Number = 123

The above version is far more approachable. Add some intellisense, and even a non-developer could write it.

The simple fact is that the SQL is in need of a major overhaul, but no-one cares. Developers don't care, because we have been ignored by the database vendors for so long that we have built whole mini-industries around abstracting the database. Database vendors don't care, because...well who knows...they live in their own little world. Report tool vendors should probably care, but in my experience, most have a serious lack of imagination.

DSLs - a stupid abstraction of an abstraction

DSLs = Domain Specific Languages. A terrible, misleading buzzword, abused by several vendors.

It implies that if only we could invent a new miracle language for any given problem domain, then we could talk about it (and instruct our computers to deal with it) in a way that gives complete power over that domain.

Abacadabra. Open Sesame. If only I knew the magic words...

MSBuild and dogfood

MSBuild is Microsoft's answer to NAnt. That is, it is an XML scripting language that supports the automation of compilation of .NET solutions.

The theory is, MSBuild is what Visual Studio uses internally to compile solutions, so it should be exactly equivalent to calling MSBuild from a build-server. We are led to believe that Microsoft has "eaten their dogfood" with regard to MSBuild.

The reality is, that is hogwash! If you have Visual Studio 2005, take a look at the MSBuild command line that appears in the output window when you compile a project. It specifies the name of every file in the project. In other words, Visual Studio independently parses the project (which it should not do because that is MSBuild's job), and then calls MSBuild with a highly customized set of parameters that has no doubt been well tested to work in a variety of scenarios.

The point being, it is not feasible to duplicate that command line on a build server. The result is some non-trivial level of frustration! I am sure there are more, but the things I have noticed are:

• MSBuild requires references to projects that Visual Studio does not. Thus, what compiles in Visual Studio will not necessarily compile on the build server
• MSBuild manages project dependencies in a different way than Visual Studio. The result is that it is possible for a full rebuild on the build machine to silently FAIL to build one of the projects.
  

Aaargh!