jasonwatkinspdx

There are as many variations of agile processes as there are teams, so I'm just going to speak directly about what I've seen work and fail without excessive qualifying language and trust people to have the judgement to know what's relevant to their situation. I'll also use the terms/language I've gotten used to over the years without attempting to translate to other glossaries. The agile manifest was originally a statement of values, not a specific bureaucratic process.

If your iteration planning meeting is taking even most of a single day, then something is going very wrong. The most recent on site full time job I worked had about 15 participants in the typical meeting, and we usually boxed it to within an hour. On a good day we'd dispatch with it in just 15 minutes.

Why the obsession with keeping it short? Well full team meetings are expensive in terms of time, but the bigger value is: practices that streamline this process tend to solve political or process dysfunctions. I won't say everything in that of

It's true that the government can't rack up debt forever. But we need to look at proportionality. Right now US total debt is around 100% of GDP. That's not awesome, but it's been higher than that in the past without dire results or not being able to control it. There are other examples of developed countries that have accumulated even more debt and successfully drained it, such as Japan.

In the context of a recessing, letting the government go into debt makes a great deal of sense. The government can spend the capital raised on infrastructure projects that create jobs, aid the economy as a whole and in the end smooth the economic dip. The government can then pay down the debt over a longer time scale. In the end the tax paying population pays either way, but it can be much more beneficial for society to take advantage of the time scale and smoothing the government debt allows. The alternatives are to raise taxes, cut spending, or do nothing. The public likely can't afford higher taxes during a time of econom

Software projects have an inherent bias towards unpredictability. Why? Because all software projects center on novelty.

In other trades or forms of craftsmanship, labor is not reusable. Take bricklaying as an example. While you gain experience and learn how to work more effectively, at some point you're basically the best mason you can be within physical limits. Each wall you build will inevitably take a certain amount of time. Past walls don't help you reduce the time necessary to build future walls. You can look at the plans and have quite accurate estimates of the time and materials involved, because you've done the exact same thing in the past and are highly practiced at it.

Software is fundamentally different because it is highly reusable. Once written, code can be copy'd and used again and again nearly instantly. Even if it can't be directly reused without modification, it's likely that adapting old code to a new context is less work than starting from square one again. So most software projects will

The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

-- EWD http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html

"To undertake the direction of the economic life of people with widely divergent ideals and values is to assume responsibilities which commit one to the use of force; it is to assume a position where the best intentions cannot prevent one from being forced to act in a way which to some of those affected must appear highly immoral. This is true even if we assume the dominant power to be as idealistic and unselfish as we can possibly conceive. But how small is the likelihood that it will be unselfish, and how great are the temptations!"

-- Friedrich Hayek

Sharding in small systems presents problems:

Let's imagine a social network. Users can see posts from users they follow in a timeline.

Let's also imagine a sharded database ...using around 10 servers.

Two basic architectures: scatter and gather.

	var secret = 'this should stay secret'

	console.log('Running...')

	for (var step = 0; step < 10000; step++){
	var buf = (new Buffer(200)).toString('ascii');
	if (buf.indexOf(secret) !== -1){
	console.log('Found your secret at step ' + step + ': ' + buf);
	}
	}

	# Example, parsing a phone book of name, number lines:
	# bob, 867-5309
	# ricky bobby, 867-5309

	# classic style PEG would give me some s expression thing like:

	[:phonebook,
	[:line, [:name, "bob"], [:number, "867-5309"]
	[:line, [:name, "ricky bobby"], [:number, "867-5309"]]

	class Memcached::MultiPartRailsCache
	MAX_KEY_LENGTH = 255 # Actually overshooting what the client will let you send through
	# but this means our chunk sizes will just a few bytes of headroom
	# as we split
	PART_SIZE = 1.megabyte - MAX_KEY_LENGTH

	def initialize(rails_cache)
	@rails_cache = rails_cache
	end

	Well first, as a quibble, I think it's generally a bad idea to personify complex systems. A market doesn't really love anything, only the individuals within do. But sometimes you need some rhetoric to get the idea across.

	What I think is important for people to remember is that the market price mechanism is a blind force. It can be very effective in some roles, but highly destructive in others. I'd make an analogy to using fire on a farm: a great way to take care of a field full of weeds. But if you don't have a system in place to control, constrain and otherwise direct the fire where it's useful, you risk burning up your whole farm.

	I don't like defeatist assumptions about governments, and I don't like blind faith that what the market optimizes for is what we as a society should value.