In this article, Adrian Hon, picks up on the idea (originally from Gregory Bateson, I believe) that time pressure creates what Bateson calls false endpoints, that reduce the quality of the final solution. He also proposes that the development process in creative fields should be altered to encourage “play” as a way of generating solutions, even as part of a business.

I believe this is misleading, because it’s partially correct. Time pressure does cause us to make compromises, but those are not necessarily to the detriment of the overall solution, particularly if one takes a long-term view, or if one considers just how unknowable a concept the “best” solution is.

You’re a business guy, a manager, or you’re a developer. You work on a startup, or within a large corporation. You’re about to start on your company’s flagship product, or you’ve been asked to take project X forward. Or you could be anywhere in between those extremes. One question should be worrying you as you take on the noble task of delivering something viable: how tough is your project, and why?

This matters a lot, because if your project is tough, you’re going to need to figure that out quickly and address the things that can go wrong with it. And if your project is really tough, you’ll need to find great developers to work on it.

So how do you figure out how tough your project is? There’s a number of ways. You can ask people, for a start. In aggregate, qualified people who understand the project will have a pretty decent idea of how tough it is. But sometimes you can’t ask, either because there’s no one to ask, or because the politics of the place dictate the wrong answer. What you can use in those cases is a list of criteria, of checkboxes that mean your project is tougher if you tick more of them.

While looking for reviews of productivity tools (task tracking tools, specifically), I stumbled on a great new blog called Put Things Off. I liked the articles - they’re all well written, interesting, and exquisitely illustrated (seriously, I’m not kidding), and since their topic is somewhat related to some of my posts, and they only launched in mid-January this year, I thought I might as well share this discovery.

From their own description: ”PTO helps freelancers, entrepreneurs and busy people work smarter, play harder, and live the lives they love.”

Enjoy!

Over at Business Of Software, there’s an article trying to present some approaches to hiring managers. This struck a chord with me, since I’ve been thinking of whether there was a way to translate my how to recognise a great programmer article into something similar for managers.

The difficulty I’ve hit, and which is not mentioned in the linked article, is that where “great programmer” was a moderately controversial idea (if you read the comments you’ll see what I mean), “good manager” is very subjective and hard to define. This makes it very hard to come up with any clear list of criteria that define what a good manager is.

When building something new, mistakes are unavoidable. To paraphrase the common saying, “if you’re not making any mistakes, you’re not trying hard enough”. There’s another saying which says that the difference between a good carpenter and a bad carpenter is not that the good carpenter doesn’t make any mistakes, but that he’s better at turning them into masterstrokes. You can, and should, try to prevent mistakes from happening, but it’s a fact of project life that things go wrong.

Many books can be filled on the subject of how to deal with the huge variety of project mishaps. In this article, I’ll focus on one specific type of mistake: the big, fundamental mistake.

Great news for everyone who likes to follow this blog. First of all, I’ve hacked my way around wordpress to enable full-text feeds for people using RSS readers. You will now be able to read my posts without having to click on to the site. In a sense, this kinda sucks for me, because I love to see the hits rise up after a good article is posted, but I’ve had some feedback from several people that they’d much prefer full-text feeds, and so I’ve given in to that.

Another thing is, I added AdSense recently, after the slashdotting, to test it out. Turns out that AdSense is really not that great at the moment. I’ve made a whopping $4.56 over the last week. So I’ve made some tweaks to make it less prominent, following this article. Namely, I’ve made it so articles newer than one week won’t get ads at all. I’m also going to make some further tweaks so that people coming from Digg and all those sites won’t see ads either, since they’re unlikely to click on them anyway - but that’s not done yet. Feel free to let me know your thoughts on this in the comments below.

Oh, and there were about 15 minutes of downtime this morning. That’s because the VM that Inter-sections runs on got moved to a new machine about 10x more powerful. Hurray for that :-)

Thanks for reading!

If you’re in the office of a large or medium company right now, stop reading and look around. Chances are, there are a few managers about. Maybe they’re the embedded project manager types, sitting amongst their team. Maybe they’re the senior manager types, ensconced in their offices (or trying to construct one in the corner of the open plan office with the aid of plants and other office artefacts).

Look at these guys carefully, and try to determine if there’s anything that they do that all the rest of your co-workers (perhaps including yourself) don’t. Chances are, although there might be one or two who don’t fit the mould, most of the managers and senior managers in your office have certain common patterns of behaviour. They dress differently, move differently, speak differently.

This is true in all the industries I’ve had any experience in or contact with (which includes architecture, consulting and financial services). I’ve discussed it with people in both the UK and the US, and it applies in both those countries, although my examples will focus on the UK.

Here’s the clincher: if you want to be promoted, you need to learn to do that, too. Read on for more details about how and why.

Phew, what a weekend!

Two of my posts got featured on Slashdot, Digg, Reddit, and a variety of other sites such as YCombinator News, DZone, and, strangely enough, Monitor.hr (yep, that’s a croatian technology news site…). The result? Well, before this happened, I had built up traffic to about 3000-4000 hits per month. Over the weekend, I got about 150 thousand hits, with over 80 thousand on Saturday alone.

Needless to say, I’m very happy about this! However, my host (DreamHost) were less than pleased with the result, particularly since I wasn’t expecting this at all and so didn’t have any caching. So they took down my site temporarily. Now, I can totally understand why they did this, but ultimately, I can’t accept that someone else can turn off my site. Therefore, I’ve decided it’s now time to migrate to a private server. Before that, I didn’t want the overhead, because I just want to write a blog, not administer a blog. However, with this kind of traffic possible, it’s becoming worthwhile to host this on my own server so that I can ensure that it never gets taken down during a traffic spike again.

So, anyway - by the time you see this post, it’ll mean that you’re accessing the new server, which is based in the Netherlands - so it’ll be a tad slower for US folks, but that shouldn’t be too much of a problem. Welcome to all the people who subscribed to the RSS feed after the weekend, too. Have a nice week everyone!

With astonishing regularity, articles or posts come out claiming that Rails sucks in some way or another. People complain that Rails isn’t as easy to deploy as PHP, that Rails just didn’t do it for project XYZ. They range from the articulate and well thought out to the frankly inane and stupid (and wrong). Recently, there’s also of course been the spectacular nuclear rant by Zed Shaw, which was more a rant against random elements of the community than against Rails, but was still presented as a rant against Rails.

These anti-rails rants come in so regularly, and have been doing so for so long, that some people even bothered to write pre-emptive rant responses, like the Six ground rules for rails sucks articles, written all the way back in 2006. RubyInside even has a Troll of the month category that will provide some fun reading.

Perhaps this means that this article is redundant. Oh well. It does get tedious after a while, to read all these rants, and I felt like writing my response to them too.

When designing a feedback system to influence change (for instance, a status report to influence the project progress, or an attempt to lose weight or save money) it’s easy to fall into the trap of going for accuracy first. Countless hours can be wasted designing the perfect measure of progress, making sure it’s accurate as can be, ensuring everyone fills in the data as accurately as possible, etc. Most of that work is, however, pointless, because accuracy is not the name of the game here. Sure, feedback needs to be vaguely accurate, but it doesn’t need to be very accurate to work.

So what is good feedback then? In this post, I’ll look at what constitutes a good feedback system and what doesn’t. Finally I’ll propose a simple framework for figuring out what feedback system to use.