In the second half of April I got an Email from Patrick Smacchia. I was very surprised, I mean, I’ve follow Patrick’s blog for some time and I though “this guy is really smart” so I was excited about getting in touch with him (starting from his side by the way), and while I’ve heard of his product Visual NDepend, I’ve actually never tried it and neither paid too much attention about the product itself. It was embarrassing because he was kind enough to offer me a Pro License to try it, evaluate it and see if it was functional and useful for me.

Recently I have been involved in scaling Hadoop for our Chip Multi-Threading (CMT) machines (e.g., systems running up to 256 threads per node.) Hadoop is a Java-based open-source MapReduce framework that enables users to deploy their cloud-friendly workloads across many computing nodes.

Subtractive design is the process of removing imperfections and extraneous parts in order to strengthen the core elements. You can think of a design as something you build up, construct and let grow, but it’s pruning away the excess that gives a design a sense of simplicity, elegance, and power.

The risks of Big Design Up Front isn't the "Up Front" part, it's the "Big" part. Doing too much design without validating it inevitably drives a good bit of the productivity loss that continues to hamper software projects.

The other day I had a look at NDepend website visits by countries statistics (produced by Google Analytics). Despite some important bias the result were pretty interesting, enough to be published publicly.

More than just designing the software, technical leadership must also design the work of implementing those designs. Taking the shape of the work into consideration along with the shaping of software modules serves the goal of predictability that comes from leveled production, and the awareness of trouble spots. Designing the work serves human and organizational concerns, and predictable manageability.

Here's an expansive archive of tasty programming quotes. Someplace to come for inspirations, or when you need a pithy line to drop and just can't put it into words yourself.

Something which constantly surprises me about Domain Driven Design is how there is a pattern described in the book for just about every possible situation you find yourself in when coding on projects.

Now I am no project planning expert but maybe this will help out some beginners and get them pointed in the right direction. I am going to break this up into a few different sections and try to keep it as general as possible to cut back on confusion.

You can be doing agile without performing any of the current recommended practices and you can perform all the recommended practices and still not be agile.

Over at Gantt Head Dr. Andrew Markar has a column titled "Debunking Agile Myths." Andrew's article makes some good points, so please sign up and read this and other articles. I'm always troubled though by some items that are missing from discussions like these. So here's my additions to Andrew's good content.

In many ways, the problems presented by camera navigation have parallels within the domain of artificial intelligence (AI). The camera may be thought of as an AI character, at the very least in terms of the determination of its position and orientation within the game world.

Unit is an atomic entity of any program which performs a specific task and can be tested independently (well almost). To test that unit of a program for its correct functionality is called as unit testing. For unit tests we have to write unit test cases. Developer themselves write unit test cases for their unit and run those against developed units. Typically, a unit test can be divided into three parts.

Signed Distance Functions are a pretty simple concept. Basically for each point in the world, you return a distance to the nearest surface, negative distances are inside geometry. One neat application of them to represent scene geometry, and ray trace into the SDF. Why would anyone do such a thing? Well, it turns out that when marching along a ray looking for intersections (which is obviously not the only way to trace rays), it’s jolly useful to know a minimum bound on when you might expect to encounter a surface. This way you can keep taking large jumps along the ray, using the SDF to figure out how large, until you finally reach some threshold distance. Here’s the end result of the code I’m presenting in this blog post.

If you're refactoring, you're not fixing bugs, you're not improving performance and you not increasing robustness. Refactoring is simply improving the design of the code, while ensuring that it still works the same, warts and all.

So what’s my point? Twofold really, firstly, just because you are not co-located does not mean that you can’t work in an agile manor. Secondly, XAF is a cracking prototyping tool! So if you have XAF, even if you have no intention of using it to build your finished product for whatever reason, don’t forget that you can use it to build a prototype, in real time, whilst you sit down with your subject matter expert.

I was fortunate enough to be featured in the July issue of Inc. magazine’s “The Way I Work” column. (Page 114, the one with Paul Graham on the cover.) The article is great and the photography very flattering, but it’s a little misleading. All TWIW articles are written in the first person, but not directly authored by the subjects, and we’re not allowed to see them before they’re published. These bizarre rules have some unexpected outcomes, and I’ve taken the liberty of rewriting the article in my own words and with lots of extra links.

New York Times techonology writer David Pogue, a writer I admire, recently listed some of his best productivity tips — and it’s a good list. One thing I noted with interest is that he uses his email inbox as a to-do list, which is a fairly common practice.