Ruby on Rails
Ta-da List


November 29, 16:21 | Comments (0)

Fowler explains refactoring, principles, all

I find idols very useful in learning. Idols keep you humble. There will always be someone who knows or have tried more and tells it or does it better. One my current idols in the software world is Martin Fowler. He wrote the defining book on refactoring that I'm currently reading (again) and two books on patterns that I'm very much looking forward to read.

Now he has been extensively grilled on his views on extreme programming, refactoring, design principles, and more in a four-pieced interview (1, 2, 3, 4) that has two more installments coming shortly. He's even more of an idol now.

November 29, 15:15 | Comments (4)

The business case for better tools

After recommending IDEA to a friend, I got him hooked and now he wants to convince the management at his firm to buy him a copy. IDEA costs $599 with one year of service and support. The place he works already bought licenses for JBuilder and TogetherJ. Two other IDE's for developing Java code.

How should my friend convince his manager that he needs yet another IDE? Simple. Tell a tale of good economics and productivity. Let's imagine my friend is payed the median salary of $76,000 and works the median 1,689 hours a year ($76,000 in yearly pay / $45 in hourly rate) for a senior developer in the U.S. A rough cut says that 50% of his time is actually spend programming and the rest is meetings, designing, courses, etc.

You could then argue that his company spends $76,000 to get the 834.5 programming hours by claiming that the rest of his time (the other %50) is spend in support costs to the actual programming. That puts a price tag of $91 per programming hour.

Now for the more serious leap of faith. How much time will my friend save by switching to IDEA? That's a pretty big unknown, so let's try to go around it. How much time must my friend at least save over the course of a year in order get a return on the investment?

The answer: $599 / $91 = 6.6 hours. That's over the course of a year. In productivity terms that 0,8% (6.6 / 834.5).

There are no silver bullets, but there's plenty of 0,8% productivity gains to be had.

November 29, 14:23 | Comments (0)

Developer's pay is over-emphasized

Finding and adjusting the important cost variables in software development is a lot harder than doing the same in old school manufactoring. As a consequence, many organizations that deal in software give up and chose to focus almost exclusively on the one variable that's easy: Developer's Pay. That's too bad because it lets a binded view drives important decisions that are critical in determining the company's performance.

Exclusive focus on developer's pay neglects the big picture in favor of a small corner. Questions on reducing costs become focused entirely on the "Could I hire cheaper developers?" kind. It's based on the falsity that developers with an equal laundry list of skills are roughly interchangable (they both know ASP, so I'll take the one that asks for $500 less a month).

A look at the big picture would include more encompassing questions, such as "How do I get my product for the least amount of resources?". Phrased like that many other variables become at least as important as developer's pay.

Considering performance
Let's just consider one of these variables for now: Performance. Numerous studies have shown that a single developer can be up to ten times more effective than another when timed working on a single task. In the extreme (and over-simplified) example, where developer efficiancy is the only bottleneck, you can afford to pay a grade 10 developer $50,000 a month instead of hiring ten grade 1 developers at $5,000 a month.

That sounds pretty extreme — and it is. The cost of a development project depends on far more than coding efficiancy and design skill. But what if we considered cases with at less than 1000% difference in developer skill? Let's just stay small and say 100%. That's just 1/10 of the theoritical possibilities

Developer A is twice as efficient as developer B. Let's keep it simple and say that this difference includes the plentitude of costs associated with having developers on board -- even the communication and cordination costs (that explode as you add more developers).

A simple cost equation
Consider the cost equation for a simple project. Five type B developers working for $5000 a month for five months: 5B x $5,000 x 5 months = $125,000.

Suppose you were able to replace all the type B developers with type A. You had to pay twice as much, but they would also get done twice as fast, leading to this cost equation: 5A x $10,000 x 2.5 months = $125,000.

Even this incredibly simplified contrast opens a world of variations in between. Hiring half as many type A developers will still get us done to the original deadline. And what if we only had to pay 50% more to get type A instead of type B developers?

Anecdotal evidence
Of all the development shops I've worked, all of them had star developers that were at least twice (and likely three or four) times as effective as the worst developers. None of them had a pay-scale that matched that fact. Most had a difference up to 25%. The best developer would get 25% more than the worst, despite being 100-300% more valuable.

Instead of making sure that they only hired star developers (by applying more rigorous hiring procedures) they would all of them argue pay as the primary deciding factor in new hires. A difference of $500 between two developers could easily decide which got hired. Considering a monthly pay of $5,000, the more expensive developer would only have to be 10% more effective to be worth it. 10%. That's just 1/100 of the theoretical potential. And that could be a deal breaker.

In face of the incredible difference between developers, managers should think less of cost of each individual, but at the cost of the total throughput.

November 27, 20:41 | Comments (15)

The arch-PHP apologists

PHP or Java? by Harry Fuecks commits a discussion in separation. It completely ignores the cumulative effect a world of kludges brings on the programming experience as a whole. He represents the arch-PHP apologist down to the last "but interfaces are possible, if you just..." excuse.

The impressive amount of work arounds for object-oriented constructs in PHP is just that. Work arounds. In all their non-standard, patch-requiring shades of grey. They're not the equivilent to Java's consistent and thorough solution to OOP.

The point is that they don't have to be. It's okay that PHP isn't Java. It's good that PHP isn't Java. It's different tools for different jobs and different types of people. I would never think to recommend Java for web developers just starting out. It's a jungle of standards, open source projects, patterns, and abstractions. That doesn't make Java better. Just different.

November 27, 18:19 | Comments (11)

Lucrative Investment!

No, I don't have a minimum of $10,000 in available funds for investment. And even if I did, I highly doubt I would hand it over to a random telemarketer calling out of Switzerland and speaking with a thick Indian accent.

Particularly not when she opens the pitching in classic spam style: "We have a lucrative offer for you!". And when she can't even tell me where she got my home phone number from.

So I don't sweat being having been labelled "unqualified" too much after explaining that I don't have $10,000. Or anything close to that. Despite the fact that kind of funds apparently is "...nothing is you're serious about making money!". Uhm, okay. Whatever you say, Mrs. Livingstone Assest Management.

November 27, 13:50 | Comments (6)

Scope, Resources, Quality, and Time

Unaware of the laws of nature, plenty project managers decide to change one of the four basic development aspects without recognizing the effect it will have on one or more of the remaining aspects.

Five weeks, you say? Give me the same in three (just work harder)! And, of course, I can't pay any more or have any bugs.

Familiar? Have your king read about The King's Dinner.

November 24, 22:18 | Comments (2)

Slashing prices on gadget sale

I cleared out around half of the items on my initial gadget sale, and now I've reduced the prices on much of the rest to get that out as well. My ultra-sleek and slim Sony Vaio can now be had for 11.000 DKR. (down from 13k), my Dreamcast with a ton of games is yours for 900,- (down from 1k), and the GBA is down to 800,- (from 1k). The mini-disc is available again (after the first buyer decided to go dark) and the Panasonic DVD is also available.

Go gadget at the Loud Thinking Gadget Sale.

November 22, 15:08 | Comments (8)

Fear, change and a language called Java

A short ecstatic tale of how I feel today after spending the last couple of days discovering Java for web application development (and neglecting responsibilities). It strays in PHP vs Java, using an IDE, initial complexities, and needing the final push to pick up something new.


November 19, 13:09 | Comments (2)

Major paper features emboss on front page

Jyllands-Posten couldn't care less about their website. It's all about dead trees to them. The smoking gun:

This is murder. A perfectly good portrait shot and left publicly bleeding by one of most dreaded effects ever to grace the world of computer visuals: emboss. No one with even a shred of aesthetic sense would have allowed such an atrocity.

Especially not on the front page.
Especially not on the cover shot.
Especially not in red.

Someone should be fired. Or at least seriously reprimanded. This is an outrage.

November 15, 16:56 | Comments (87)

That's just who I am

Is your idiosyncratic behavior annoying other people? Are you way of telling people what you think of them mean or offensive? Do you act a certain way to a certain situation without explicitly knowing why? Don't bother changing. Don't even bother considering changing. Just grab another favorite escapisms: "That's just who I am".

It's the easy way out. Never mind that it's based on the falsity that people will accept you for who you are — annoying behavior notwithstanding — and that you should always try to be yourself (at all costs).

Especially the latter of the two is interesting. Why is it that once we've acquired a certain trait or behavioral pattern we should be forced to keep it? We're being fed this nonsense since early childhood and it tends to stick stronger than the contradictions we receive along with it (you should always be nice to other people).

Convincing yourself that there's nothing to do about your present traits or behavioral patterns is a self-fulfilling prophecy. And it's being given all the help it can get from the taboo of personal development.

It's taboo to want to change something about your personality. It's okay to want to loose five pounds, but wishing to be a kinder person is looked down upon.

On my bookshelf there's a single title that gathers more interest than any other: How to influence people and win friends. It's a book about how to be nicer, a more attentive listener, and generally a better person. It's a book on personal development that I've much enjoyed reading and try (however hard it is at times) to live by in a lot of situations.

But apparently, it's also a book of desperation. The comments I've received have mainly centered about that fact. You have to be desperate to get friends/change yourself if you want to read a book about it. (Bonus implication is that the commenter is fully satisfied with her- or himself).


You can be however you want to be. You can change. You can learn. The only thing holding you back is a misconceived sense of identity (if I'm not an ass, who am I?) and a fear of what's going to happened after you change. Break free of that. Change.

November 15, 16:12 | Comments (2)

That's just the way it is

I can't stand "that's just the way it is". It's the worst of argumentative escapisms. It's also a red flag alerting signaling a either silly, irrational, ego-loaded reason (and often all of those things) to why it is that way. It begs further argumentation despite being used a method to end a debate.

It's frequently used when someone either doesn't know why a certain thing is that way (but don't want to admit their lack of knowledge) or when that someone chose to make it so (and don't want to acknowledge he missed something). It's an instrument of fear used by the person's survival rules to guard an over-sensitive ego from negative exposure.

Such a survival rule could be that "I must appear perfect at all times" or "They won't think I'm a good leader or technical sufficient if I back down". But just as trying to end the debate using the instrument of fear, the consequences of such survival rules is the exact opposite.

Trying to appear perfect at all times will ensure you never look perfect. Never backing down to a superior argument will ensure you're seen as a bad leader or technical inadequate.

Admitting faults and lack of knowledge is the only way to move forward as a human being. Stop worrying so much about your appearance. It'll work out fine in the end if you're open and willing to learn.

November 02, 12:49 | Comments (8)

Instant messaging steps closer to standards

IM compatibility closer to reality (

[IETF] gave the go-ahead to the creators of open-source instant-messaging application Jabber to create a working group based on that technology.

What sweet pleasure it would be to have the instant messaging protocols wrestled away from the proprietary claws of AOL and Microsoft.

I'm about to venture into domain of IM bots, and the plethora of protocols, one more obscure than the other, is more than a little daunting (and add the ActiveBuddy patent to the mix and it's getting more intimidating than daunting).

Internet infrastructure is too important to be controlled by a handful of tech execs with the next quarterly earnings in mind.