the macbook pro has a keyboard that can be back-illuminated. but being able to see the key you need to press to turn up the backlighting is hard when the backlighting isn't on and the room is dark.

duh.

as an end-user of programming languages, i am greatly annoyed by ones that don't handle forward references (clojure, others?).

thank goodness for (a) google and (b) stack overflow.

i'm pretty sure i will hate your charts and graphs, whoever you are. unless you've read tufte and really think about a budget for your ink.

might be interesting, if the font weren't so small.

do you correctly decouple estimates from commitments?

it's the value, stupid.

because everybody who has made an operating system to date, and most people who have made applications, are complete and utter jerk-tards.

ho ho ho, yes!

it is nice that unity 3d and unreal 3 are available freeish. but usability still sucks, of course. oh well.

i'm waiting for the day somebody implements a good expert system / ai / natural language ui for doing asset development and management etc.

when i say things like Steam, or Windows XP, or updating Firefox, etc. are bad, i don't just mean in some vague I'm An Asshole With A Blog sense, i mean they really do have concrete ways in which they are just daily excrementally runny.

the flickr uploader is a piece o excrement, strooth.

the kicker with all the stuff that is just bad and broken and evil and wrong about zimbra is that on the whole they are doing nothing innovative, and they could simply have compared their system to Google Docs, to Microsoft Office, to Open Office, whatever, to see how painful things are. Let alone having a basic clue about usability what-so-ever.

wow. it isn't just that every time i use zimbra i hate it. no, it is also that any time i go to try to use some new feature of zimbra, i find even more wonderful new hateful ways it sucks donkey poo.

i really like the idea of getting medieval on code's ass.

i <heart> dwarf fortress.

oh, i get it! some sort of crack-smoking shangri-la!

"The problem with Technical limiting constraints (e.g. scalability) is that they viciously constrain systems when they are reached (e.g. by taking it down), whereas Feature constraints are passive: the more features you add the more revenue you get, but the system still works fine in the meantime. As a result, waiting until a Technical issue becomes a limiting constraint before addressing it is very dangerous unless you have specifically designed your architecture and infrastructure to be highly self-monitoring and responsive (e.g. via spinning up new machine images on demand in response to scalability limits being reached), which ties back into your points about the key importance of liquidity. Without that I think a time component needs to be factored in, such that a technical issue is considered a virtual limiting constraint at the point where there’s any non-trivial chance of it becoming the true limiting constraint n days into the future, where n is the number of days it will take to resolve the situation."

how do you know what will generate value?

"I treat features as the source of revenue, and non-functional and operational requirements as risk to that revenue, on the basis that if those requirements are not met then the full revenue potential will not be realised."