Mitch Lacey provides a video retrospective on a failed project. You always learn more from mistakes than successes, perhaps you can learn some interesting things from his mistakes.
Note: There’s a slideshow that goes along with it, but he covers the gist of the slideshow pretty well, so you can just listen to the video like a podcast while you do other things.
Mostly for my own benefit, but it is a good list, in any case.
And you thought Cobol was a dead language with no future 
As long as it has a Make file or other command-line compiler interface, you too can build Cobol systems via a CI system.
Autobiography is only to be trusted when it reveals something disgraceful. A man who gives a good account of himself is probably lying, since any life when viewed from the inside is simply a series of defeats.
You may find your attempts to introduce technologies or ideas to be frustrating and the path littered with failures. The important thing, I think, is to remember that you are not alone in that feeling.
Also, if you find people who are absurdedly self-confident and self-aggrandizing, they are probably blustering to cover up some significant weaknesses.
Read both the article and the comments. Then come back here. Don’t worry, the browser will wait patiently for you.
My thoghts:
It’s clear from the article that Tony wrote these in a hurry, and I don’t want to sound like I think he’s a bad programmer or a bad person because I disagree with him about the ‘lesson’.
What is interesting is that Tony wrote the code with a certain mental model of what ’success’ meant. And the comments exploded with people coming up with different definitions of success, and different ways to succeed.
As an Agile Project Manager, if I can define success the right way (for me): “I want a balanced token matcher, that’s easy to maintain“, then I can step out of the way, and let the developers figure out how to meet that goal.
Kudos to Tony for bringing up this interesting discussion.
(Hat Tip: Ragenwald)
I was able to write a working Monte Carlo Project Simulation prototype in less than 24 hours. Here’s a screenshot of the relevant portion:
Manifest:
In the process of building a Monte Carlo simulation engine, I stumbled across Eastwood, and the Google Chart API.
Diving in, I’ve discovered that the Google Chart API is pretty solid for simple charts - easy to get started, and fairly simple to experiment with by manipulating the URL.
And, if you’re using Grails, Eastwood is a plugin that converts JFreeChart to use the Google Charts API. Very nice.
Over the summer, I was tasked to put together a ‘Build Metrics Dashboard’ - a piece of software that could parse the XML reports from a bunch of common code and automated testing analysis tools, and produce a comprehensive report.
We’ve been sitting on it for a few weeks, but the website is up and running, and it’s time to announce: FuseMetrics
FuseMetrics is written in Groovy, and can parse the reports of many of the most common analysis tools:
And, because of a basic plugin architecture, it can be extended to support just about any other tool, as long as the output is well-formed.
What does it do? It produces summary metrics and graphs - sparkline graphs of various metrics-over-time, and histograms, which profile the population of a set of code files. The histograms are more powerful with bigger codebases, but the sparklines are useful for just about anyone.
Here’s a screenshot of FuseMetrics running on my test data
It’s completely open source - you can get the code here. Try it out, let me know what you think!