That is all.
That is all.
Wealth is not the same thing as money. If you want to create wealth, it will help to understand what it is.
Wealth is the fundamental thing. Wealth is stuff we want: food, clothes, houses, cars, gadgets, travel to interesting places, and so on. There is not a fixed amount of wealth in the world. You can make more wealth.
People think that what a business does is make money. But money is just the intermediate stage— just a shorthand— for whatever people want. What most businesses really do is make wealth. They do something people want. Money is a comparatively recent invention.
A surprising number of people retain from childhood the idea that there is a fixed amount of wealth in the world. There is, in any normal family, a fixed amount of money at any moment. But that’s not the same thing.
Suppose you own a beat-up old car. Instead of sitting on your butt next summer, you could spend the time restoring your car to pristine condition. In doing so you create wealth. The world is— and you specifically are— one pristine old car richer. And not just in some metaphorical way. If you sell your car, you’ll get more for it.
In restoring your old car you have made yourself richer. You haven’t made anyone else poorer. So there is obviously not a fixed pie. And in fact, when you look at it this way, you wonder why anyone would think there was.
I took the liberty of de-Paul-Graham-ifying a bit of this to make some of the central points more clear.
This is probably the most level-headed introduction to scrum / agile processes I’ve ever read.
I have come to think of estimation and time tracking as being similar to code coverage. People who have never really tried using code coverage tools are quick to point out all the reasons why code coverage is a waste of time. They can describe in great deal why code coverage will not solve all their problems. They know that even 100% code coverage does not guarantee that software is correct. All of their excuses are built on facts. But it is also difficult to find someone who has used code coverage who believes it is pointless.
It is true that best practices can be taken too far. Many of them produce their greatest returns when applied in a small way. Nobody’s going to be hiring me as an agile coach, but I’ve got more experience than I did two years ago, and I’ve learned some great lessons. Nowadays, when somebody tries to tell me that estimation and time tracking are pointless, I ask them, “Have you tried these practices with 4-week sprints and a burndown chart?”
He approaches the topic as a skeptical skilled-practicioner and it seems their team was constantly adjusting the “final target” aim for their software release.
There was a period of several months where every time we finished a sprint we had to insert a new one to deal with the stuff that didn’t get done. Ian described sprint 15 as the first sprint where he didn’t have to redo the 1.0 plan.
This is in pretty stark contrast to most sprint-based projects I’ve worked on which have been more of “small batches, updating production” and no final marketing or release push for any of the “bigger” things that might shift / delay from sprint to sprint.
In any case, if you are an “agile skeptic”, please read the linked article, it’ll give you some healthy food for thought.
A traveler approached him and asked, “Sir, I’m new here. Could you tell me the kind of people that live in this city?”
After pondering, the wise men asked in return, “And what were the people like where you came from?”
The man replied, “They were unfriendly and mean-spirited.”
The wise man responded, “That’s what they’re like here, too.”
Not long thereafter another traveler approached the city and asked the wise man again the kind of people that lived within the city. “What were the people like in the city that you’ve come from?”
The traveler replied, “Friendly, good-hearted, willing to help their neighbor,” to which the wise man responded, ”And that is what they are like here, too.”
…try ignoring the hype-o-meter on this next vid, but it has some sobering historical information.
Some people have been dogging the iPhone and Mobile Safari as “the new IE6”. The sentiment being that we’re going back to the “Best Viewed in XXX Browser” era. I am unabashedly in favor of this particular icing on the internet cake mostly because we are still living with IE6. :^)
What I mean to say is that having a locked down platform that is guaranteed to support all of HTML5’s new features means that web developers can innovate using the shiny new tools in the toolbox and hopefully those uses will make their way back into web development at large.
In addition, if you give an executive the choice between supporting IE6 and doing up a good iPhone / mobile implementation I think we’re at the tipping point where decision-makers are leaning away from IE6 and towards these newer technologies.
Like icing, however, too much of it can ruin a good cake. I don’t really want iPhone-only sites, but instead good small-screen experiences driving improvements which in turn drive faster and ~nicer~ desktop experiences.
My six month prediction sees an increase in “IE6 is officially not supported” messaging with IE6 phased out for the internet at large within a year or so (ie: one of the major JS frameworks drops IE6 support, makes it optional, or drops active testing against it).
A neat trick you can start playing with now is the following mojo to trigger different mobile Safari keyboards on web pages (nice!) which all devolve into <input type=”text”>:
What’s most interesting is that we’re starting to see some of these features get implemented into browsers.
- <input type=”number”> - iPhone keypad loads with numerics
- <input type=”url”> - iPhone keypad loads with “.com” button
- <input type=”email”> - iPhone keypad loads with “@” sign
Mobile Safari (on the iPhone) was quick out of the gate by adding support for number, email and url. No validation is performed but special keyboards for each input type are presented to aid in entering a value.
Most recently, Chrome 5 beta has support for the placeholder attribute.
And if you want to see state of the art on iPhone web experiences, check out the following:
future present certainly looks bright.
Water Consumption in Canada During 2010 Olympic Gold Medal Hockey Game.
If the airline charges $1 per ticket of course the plane will fill, but the total revenue of $150 barely pays for an hour of a pilot’s salary. If they charge $1000 a ticket then if they could fill the plane they’d make a fortune, but only a small number of people are willing to fly at that price, so again they can’t equal the fixed costs of flying a plane. But if the airline can make those who are willing to pay it pay $1000, and others pay $800, and others $500, maybe down to $100 or so, then the sum total over all passengers is sufficient to pay for the fixed costs. In fact, some estimates put the incremental cost of flying a single passenger as low as $30 (for the meal and baggage and ticket handling), so that once the airline has committed to flying the plane it is in their interest to sell a ticket for $30 rather than let a seat go empty. But they must keep those who can pay more from buying their ticket at low prices, a tough balancing act.
The whole paper is worth reading if you’re that kind of dork. I knew things were complicated but I didn’t realize just how complicated.
At Google, we generally program in three languages: C++, Java, and Python. None of them are functional languages: are all state-heavy, imperative, object-oriented languages. But the more I’ve read and written code in this code-base, the more I’ve found that functional code is the best way of building large things.
Nice little article about the benefits of functional-style programming.
Like what you just read? Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.
Thanks for Visiting!