Closer To The Ideal

Why are there old people in science fiction movies and on TV? Why, for instance, does Jean-Luc Picard, commander of the Enterprise in the Star Trek television series, appear to be middle aged? Do people think we will still be trapped by our natural life cycle, even 300 years from now?

Written fiction tends to be a little better than the movies. In Larry Niven’s novel Ringworld, the main character is 200 years old, but still basically young:

Despite his age, Louis turns out to be in perfect physical condition owing to a combination of advanced medical technology and boosterspice, a drug that extends human life.

Still, Niven is an unusually thoughtful sci-fi writer. One can find old people in written sci-fi, but I’ll skip over the issue for now. The problem is much, much worse in the movies and on TV. That sci-fi is full of old people. There are older characters in The Fifth Element, Logan’s Run, Back To The Future, etc. It’s a long list. In Star Wars, the character Obi-Wan Kenobi is old, which raises the question how a civilization manages to become advanced enough to go faster than the speed of light, but is still unable to heal the simple genetic defects that lead to aging?

In the movies I list above, society has some amazing technologies, but their medical technologies are not much better than where we are at in 2009.

At one point in the past, much of sci-fi was focused on imagining the near future:

”…The answers we seek will be found in the near tomorrow… Let us explore together the future. A future not of dreams, but of reality. For much of what we are about to see is even now beyond the promise and well on it’s way to tomorrow’s world…”

For some reason, that interest has faded. It seems likely that the next 100 years will see dramatic advances in medical technology. It is curious that so much science fiction refuses to allow that probability into its works.

On a related note, Virginia Postrel quotes Joel Garreau about the changing vision of the future on display at Disney’s Tomorrowland:

Disney …is now presenting not so much the future, but the future that it thinks we want. Wander around Tomorrowland and it no longer gleams with white plastic and blue trim. No “2001.” It is an antique future, a bronze future, full of things that look like astrolabes channeling Leonardo da Vinci.

The future of the future is in the past?

“This is an aspirational future,” says Disney spokesman John J. Nicoletti….

But this is absolutely not the future in the research pipeline. No genetically modified critters here that eat carbon dioxide and poop gasoline. No nanobots smaller than blood cells, cruising our bodies to zap cancer. No brain implants that expand our memory. No cellphones that translate Chinese. No dragonfly-size surveillance bots, no pills that shut off the brain’s trigger to sleep, no modified mitochondria sustaining our energy while making obesity as quaint as polio.

Apparently that tsunami of change doesn’t sell. That disturbing but dazzling future rumbling our way is distinctly different from the soothing one Disney thinks we crave.

And then there is this quote from Danny Hillis:

“What I think it says is that we are nostalgic for a time when we believed in the future. People miss the future. There’s a yearning for it. Disney does know what people want. People want to feel some connectedness to the future. The way Disney delivers that is to reach back in time a little bit to the past when they did feel connected.

“It’s a bit of a cop-out. There was a time when the future was streamlined jet cars. Rather than create a new sense of the future, they say, ‘Ah, remember when we believed that the future was streamlined jet cars?’ It’s a feeling of connection to the future, rather than connection to the future.

“It’s a core ache. Something is missing that we’re searching for.”

All of which leaves me wondering why the public may have lost interest in the near-future as it will actually be. We can expect some amazing advances in the coming decades, but compare the public mood now to what it was 50 years ago, and clearly the public has less of an appetite for the (real) future than it once did.

I wonder why?

I’ve a new post up at Symfony Nerds. Fabien Potencier, the lead developer on Symfony, has recently introduced 2 new components related to templates in Symfony, including Twig, a template engine that will be introduced in Symfony 2.0. I try to offer an overview of the whole debate around these developments.

By middle age, people are riddled with cancer cells:

But knowing more about how tumors develop and sometimes reverse course might help doctors decide which tumors can be left alone and which need to be treated, something that is now not known in most cases.

Cancer cells and precancerous cells are so common that nearly everyone by middle age or old age is riddled with them, said Thea Tlsty, a professor of pathology at the University of California, San Francisco. That was discovered in autopsy studies of people who died of other causes, with no idea that they had cancer cells or precancerous cells. They did not have large tumors or symptoms of cancer. “The really interesting question,” Dr. Tlsty said, “is not so much why do we get cancer as why don’t we get cancer?”

The earlier a cell is in its path toward an aggressive cancer, researchers say, the more likely it is to reverse course. So, for example, cells that are early precursors of cervical cancer are likely to revert. One study found that 60 percent of precancerous cervical cells, found with Pap tests, revert to normal within a year; 90 percent revert within three years.

But if you think about it, it is tough to imagine a model whereby this situation comes about suddenly in middle age. What is more likely is that everyone has cancer cells from a young age. What declines over time is the ability of the body to manage those cancer cells.

Paul Graham writes about startups, reviewing feedback he has received from those who went through his “School for Startups”. The most common feedback was about the need to be careful when choosing business partners.

What people wished they’d paid more attention to when choosing cofounders was character and commitment, not ability. This was particularly true with startups that failed. The lesson: don’t pick cofounders who will flake.

Here’s a typical reponse:

You haven’t seen someone’s true colors unless you’ve worked with them on a startup.

The reason character is so important is that it’s tested more severely than in most other situations. One founder said explicitly that the relationship between founders was more important than ability:

I would rather cofound a startup with a friend than a stranger with higher output. Startups are so hard and emotional that the bonds and emotional and social support that come with friendship outweigh the extra output lost.

We learned this lesson a long time ago. If you look at the YC application, there are more questions about the commitment and relationship of the founders than their ability.

Founders of successful startups talked less about choosing cofounders and more about how hard they worked to maintain their relationship.

One thing that surprised me is how the relationship of startup founders goes from a friendship to a marriage. My relationship with my cofounder went from just being friends to seeing each other all the time, fretting over the finances and cleaning up shit. And the startup was our baby. I summed it up once like this: “It’s like we’re married, but we’re not fucking.”

Several people used that word “married.” It’s a far more intense relationship than you usually see between coworkers—partly because the stresses are so much greater, and partly because at first the founders are the whole company. So this relationship has to be built of top quality materials and carefully maintained. It’s the basis of everything.

Great essay by Paul Graham (from 2003):

The example of painting can teach us not only how to manage our own work, but how to work together. A lot of the great art of the past is the work of multiple hands, though there may only be one name on the wall next to it in the museum. Leonardo was an apprentice in the workshop of Verrocchio and painted one of the angels in his Baptism of Christ. This sort of thing was the rule, not the exception. Michelangelo was considered especially dedicated for insisting on painting all the figures on the ceiling of the Sistine Chapel himself.

As far as I know, when painters worked together on a painting, they never worked on the same parts. It was common for the master to paint the principal figures and for assistants to paint the others and the background. But you never had one guy painting over the work of another.

I think this is the right model for collaboration in software too. Don’t push it too far. When a piece of code is being hacked by three or four different people, no one of whom really owns it, it will end up being like a common-room. It will tend to feel bleak and abandoned, and accumulate cruft. The right way to collaborate, I think, is to divide projects into sharply defined modules, each with a definite owner, and with interfaces between them that are as carefully designed and, if possible, as articulated as programming languages.

I recently worked on a project where all the code was shared by all of the programmers. What a disaster. Each programmer had their own way of doing things. And each programmer wanted to use whatever library they felt most comfortable with. Thus, for the Javascript, the project included jQuery, Prototype, and a whole bunch of custom libraries that various programmers had written. Even worse, we had a dispersed team, so none of us ever got to meet one another. We had 2 programmers in New York City, one in North Carolina, one in Europe, and about 8 at a firm in India. And, even worse still, everyone was part time, so no one saw any need to make an emotional investment in the project, or even to study what the other programmers were doing. In short, nearly every mistake that could be made, was made. And I am certain that if the project had been handled by 2 programmers who worked on it full time, and who were in the same city and who could meet each day, then the project would have gone faster, cost less, and had less bugs. (I was nominally the “lead programmer” but all of my decisions were over-ruled by the project manager – he did not get that hacking is an art.)

This is also good:

One way to tell how good people are at empathy is to watch them explain a technical question to someone without a technical background. We probably all know people who, though otherwise smart, are just comically bad at this. If someone asks them at a dinner party what a programming language is, they’ll say something like “Oh, a high-level language is what the compiler uses as input to generate object code.” High-level language? Compiler? Object code? Someone who doesn’t know what a programming language is obviously doesn’t know what these things are, either.

I’ve a new post up over at Symfony Nerds. It is all about how ‘traits’ will bring something like Mixins to PHP.

Regular expressions strain my brain any time I have to do more than a straight literal match with maybe one wildcard, so I am very pleased to see this very cool online tool for analysing RegEx in jQuery.

Simon Willison is rightly upset at the scantily clad women hired to do sexy dances on stage at the Yahoo Hack Day in Taiwan:

I’ve heard arguments that this kind of thing is culturally acceptable in Taiwan—in fact it may even be expected for technology events, though I’d love to hear further confirmation. I don’t care. The technology industry has a serious, widely recognised problem attracting female talent. The ratio of male to female attendants at most conferences I attend is embarassing—An Event Apart last week in Chicago was a notable and commendable exception.

Our industry is still young. If we want an all-encompassing technology scene, we need to actively work to cultivate an inclusive environment. This means a zero tolerance approach to this kind of entertainment. Booth babes, tequila girls, and scantily clad gyrating women simply set the wrong tone, here or abroad. Heck, this isn’t just about offending women—many guy geeks I know would be mortified by this kind of thing.

Articles like this make me think I need to learn Clojure.

Great article on the origins of life, before the first cells formed.

Darren Hoyt points me to this good article about 8 ways to make the WordPress interface easier for your clients to understand.

Martin Fowler has a great post about technical debt:

There’s been a few posts over the last couple of months about TechnicalDebt that’s raised the question of what kinds of design flaws should or shouldn’t be classified as Technical Debt.

A good example of this is Uncle Bob’s post saying a mess is not a debt. His argument is that messy code, produced by people who are ignorant of good design practices, shouldn’t be a debt. Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn’t sustainable in the longer term, but yields a short term benefit, such as making a release. The point is that the debt yields value sooner, but needs to be paid off as soon as possible.

To my mind, the question of whether a design flaw is or isn’t debt is the wrong question. Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking. A particular benefit of the debt metaphor is that it’s very handy for communicating to non-technical people.

I think that the debt metaphor works well in both cases – the difference is in nature of the debt. A mess is a reckless debt which results in crippling interest payments or a long period of paying down the principal. We have a few projects where we’ve taken over a code base with a high debt and found the metaphor very useful in discussing with client management how to deal with it.

The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small – such as if it were in a rarely touched part of the code-base.

So the useful distinction isn’t between debt or non-debt, but between prudent and reckless debt.

Some articles I want to remember for later:

How to handle the CSS differences between IE6, IE7 and IE8.

Mockflow is a new online mockup/wireframing tool. Worth a look.

Massively collaborative mathematics.

I think in general people are terrified of the degree to which they can not control their lives. We’ve little protection against getting cancer, or driving down a narrow street when a drunken driver veers into out lane, nor can we easily control the events that effect our loved ones – parents, friends, partners, children. People live in denial about the large degree to which luck rules our lives.

I like this simulation, which makes the point in a business context:

Sugarscape had something that is supposed to be prohibited in mainstream economics – horizontal inequality. It means that agents with similar skills and similar levels of sugar wealth at birth should end up roughly equal. But they don’t. Take the example of two agents born with similar levels of vision and slow metabolisms. They are born right next to each other on the Sugarscape board. Neither can see any sugar, so one randomly goes north and the other randomly goes south. One turns out to be heading towards a sugar mountain, the other is doomed to starvation in a valley with no sugar. Same genes. Same birthplace. Only the path they each randomly took determined where they ended up. This doesn’t mean genes don’t matter, or birth place doesn’t matter… it just means that random choices have just as much to do with guiding our fate as our skills and work ethic.

What does this mean for startups? The good news is that hard work pays off. Working hard increases your chances of startup success. The wealth distribution in Sugarscape wasn’t random, it just wasn’t a simple meritocracy either. Overall, better agents fared better.

The bad news is that you can never guarantee success because some small random event could make the difference between a $100 million exit and a total fire sale failure. And you may have no way of knowing at the time that the event is that significant.

Richard Wiseman has done some experiments which he wants us to believe prove that happy, relaxed, positive people tend to be luckier than others:

Personality tests revealed that unlucky people are generally much more tense than lucky people, and research has shown that anxiety disrupts people’s ability to notice the unexpected.

I wish I could believe his findings, but from the sounds of it his experiments were very badly designed:

I gave both lucky and unlucky people a newspaper, and asked them to look through it and tell me how many photographs were inside. On average, the unlucky people took about two minutes to count the photographs, whereas the lucky people took just seconds. Why? Because the second page of the newspaper contained the message: “Stop counting. There are 43 photographs in this newspaper.” This message took up half of the page and was written in type that was more than 2in high. It was staring everyone straight in the face, but the unlucky people tended to miss it and the lucky people tended to spot it.

For fun, I placed a second large message halfway through the newspaper: “Stop counting. Tell the experimenter you have seen this and win £250.” Again, the unlucky people missed the opportunity because they were still too busy looking for photographs.

Wait a minute, the ‘lucky’ people stopped reading on page 2, and thus missed out on a £250 prize? Some of the unlucky people stupidly kept reading past page 2, and (I assume) the reward for at least a few of them was that they saw the second announcement and won £250?

This is a badly designed experiment since it throws into doubt who was really lucky and who was unlucky. Seems to me Wiseman is proving a different point: hyper-vigilance can lead to an excess of anxiety and therefore hyper-vigilance is often bad, but sometimes it pays off, as it did in this case for some of the ‘unlucky’ people.

For my part, if I’d seen the notice on page 2, I’d worry that it was some kind of trick that the researchers were trying to play on their subjects, and I would have kept reading. Maybe I would have been one of the ‘unlucky’ people who won £250.

Since his experiment was badly designed, I have trouble trusting his conclusions:

My research revealed that lucky people generate good fortune via four basic principles. They are skilled at creating and noticing chance opportunities, make lucky decisions by listening to their intuition, create self-fulfilling prophesies via positive expectations, and adopt a resilient attitude that transforms bad luck into good.

Of these, the least intuitive is “make lucky decisions by listening to their intuition”. I’ve had friends who are alcoholics. Their intuition tells them to drink alcohol. Most of them are aware that they have a problem and are struggling to improve their lives. They’ve learned to distrust their intuition. Some of them have joined the AA, and now they are trying to ingrain in their heads a totally new set of intuitions, based around ideas like “One day at a time” and “Trust your higher power.” It seems to me Wiseman has it backwards: unlucky people are often people who start out in life with very bad, inaccurate intuitions about the world, and then hard experience teaches them to distrust their intuitions. Their distrust of their intuitions is part of the process whereby they come to learn better, more accurate intuitions.

A town with only one restaurant, a McDonalds, suddenly gets another restaurant, a Wendy’s. The McDonalds handles this in a counter-intuitive fashion:

So what did McDonald’s do on Wendy’s big grand opening day?

Run a special and try to steal their thunder?

Bring out the clowns and free fries to defend their turf?

Nope…..

McDonald’s shut down that day without notice….repaved the parking lot.

At lunch time, 100s of cars that normally zip through the McD’s in a couple hours were essentially redirected to Wendy’s. A brand new Wendy’s. A Wendy’s with a staff that had absolutely no experience dealing with heavy lunch volume.

Of course, it was a disaster for Wendy’s. Customers that were used to moving through a drive-thru (McD’s) in 7 minutes were honking horns and leaving the line after ordering. The staff was rattled and probably had some defections.

By shutting down, McD’s overwhelmed their competitor into paralysis. They gave all of their normal customers a chance to try the new guy (which they would have anyway)….all at once….on his worst day.

This reminds me of when I was a little kid, playing football with the neighborhood kids – I remember the first time I saw a really well done fake-out, pulled off by one of the older kids, a teenager. I recall how counter-intuitive and clever it seemed at the time. And when it is done well, it still strikes me as counter-intuitive and clever.

I do not know much about Objective-C, but I’ve got a lot of friends who want to do iPhone apps, so I’ve thought about diving in.

Matt Gallagher writes about the best aspects of Objective-C in a really interesting post:

The short answer is that this dynamic message handling in Objective-C makes it much easier to work within a large framework that you didn’t create because you can examine, patch and modify elements of that framework on the fly. The most common situation where this is likely to occur is when dealing with an application framework.

The biggest reason for this is that you can add or change methods on existing objects, without needing to subclass them, while they are running. Approaches for this include categories, method swizzling and isa-swizzling.

This makes the following situations possible:

• You want to add a convenience method to someone else’s object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI).
• You want to change the behavior of a class you didn’t (and can’t) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa).
• You want to treat objects generically and handle potential differences with runtime introspection.
• You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object).

These points may seem somewhat mild but they are central to maximizing code reuse when working within someone else’s framework: if you need existing code to work differently, you don’t need to reimplement the whole class and you don’t need to change how it is allocated.

Languages using virtual method tables can adopt some of these ideas (like the boost::any class or C♯ 4.0’s dynamic member lookup) but these features have additional restrictions and don’t apply to all objects, meaning that they can’t be used on purely arbitrary objects (such as those you don’t control or didn’t create) and so don’t help when interacting with someone else’s framework.

Simply put: dynamic message passing instead of virtual method invocations makes Objective-C a much better language for working with a large library or framework that someone else has written.

… In my opinion, Objective-C is the best language for programming situations where you must make extensive use of a framework written by someone else (particularly an application framework). The success of Objective-C in this situation is due to the combination of:

* speed and precision (from its compiled C roots)
* dynamic flexibility (due to using message passing for method invocations)

To frame this conclusion, I’ll state that I’ve written major projects using C/WIN32, C++/PowerPlant, C++/MFC, and Java/Swing/AWT. I’ve also dabbled in smaller projects using C♯/.Net. In all of these cases I have found the application frameworks to be less flexible and less reusable because they lack the dynamic modifiability of Objective-C.

When I hear the words “change methods on existing objects… while they are running” I immediately think of Ruby. In fact, till recently, Ruby was the only language I was aware of that allowed you to modify a class at runtime. Some programmers regard this as heresy. Consider the fear in Bill Venners voice as he talks about this with Yukihiro Matsumoto (the creator of Ruby):

Bill Venners: In Ruby, I can add methods and variables to objects at runtime. I have certainly added methods and variables to classes, which become objects at runtime, in other languages. But in Java, for example, once a class is loaded or an object is instantiated, its interface stays the same. Allowing the interface to change at runtime seems a bit scary to me. I’m curious how I would use that feature in Ruby. What’s the benefit of being able to add methods at runtime?

Yukihiro Matsumoto: First of all, you don’t have to use that feature. The most useful application of dynamic features, such as adding methods to objects, is meta-programming. Such features allow you to create a library that adapts to the environment, but they are not for casual uses.

So, it seems to me, Objective-C was pioneering many of the advantages that I would nowadays associate with dynamic scripting languages, like Ruby or Groovy. But an interesting thing about Objective-C is that it is a compiled language. It was compiled largely because the computers that existed back then were not powerful enough to handle script languages. Perl and Python don’t get going till the end of the 80s, and scripting languages don’t really take off till the 90s, when there was sort of an explosion of them (Ruby, PHP, etc).

The SmallTalk language was an inspiration for Objective-C, but SmallTalk ran very slowly on the machines of the early 80s:

In the early 1980s, common software engineering practice was based on structured programming. Structured programming was implemented in order to help “break down” programs into smaller parts, primarily to make them easier to work on as they grew increasingly large. However, as the problems being solved grew in size, structured programming became less useful as more and more procedures had to be written, leading to complex control structures and a low level of code reuse.

Many saw object-oriented programming as a potential solution to the problem. In fact, Smalltalk had already addressed many of these engineering issues; some of the most complex systems in the world were Smalltalk environments.[citation needed] On the downside, Smalltalk used a virtual machine. The virtual machine interpreted an object memory called an image, containing all development tools. The Smalltalk image was very large and tended to require huge amounts of memory for the time. The virtual machine also ran very slowly, partly due to the lack of useful hardware VM/container support.

So what was needed, at that time, was a compiled language that offered the flexibility of object oriented code, and perhaps some of the productivity benefits of dynamic languages:

Objective-C was created primarily by Brad Cox and Tom Love in the early 1980s at their company Stepstone. Both had been introduced to Smalltalk while at ITT Corporation’s Programming Technology Center in 1981. Cox had become interested in the problems of true reusability in software design and programming. He realized that a language like Smalltalk would be invaluable in building development environments for system developers at ITT. Cox began by modifying the C compiler to add some of the capabilities of Smalltalk. He soon had a working implementation of an object-oriented extension to the C language, which he called “OOPC” for Object-Oriented Programming in C. Meanwhile, Love was hired by Schlumberger Research in 1982 and had the opportunity to acquire the first commercial copy of Smalltalk-80, which further influenced development of their brainchild.

Objective-C arrived at Apple via NeXT:

After Steve Jobs left Apple, he started the company NeXT. In 1988, NeXT licensed Objective-C from StepStone (the owner of the Objective-C trademark) and released its own Objective-C compiler and libraries on which the NeXTstep user interface and interface builder were based. Although the NeXT workstations failed to make a great impact in the marketplace, the tools were widely lauded in the industry. This led NeXT to drop hardware production and focus on software tools, selling NeXTstep (and OpenStep) as a platform for custom programming.

…After acquiring NeXT in 1996, Apple Inc. used OpenStep in its new operating system, Mac OS X.

I can imagine that at the time Steve Jobs was starting NeXT, Objective-C would have huge appeal as the most dynamic compiled language available at that time. And Jobs has stuck with it for over 20 years now, first bringing it into the MacOS and then making it the basis of programming in the iPhone API.

The Wikipedia page says Objective-C tends to run 3 times slower than plain C. I imagine that used to matter, though of course nowadays large projects (possibly the majority of all software written?) is written in languages that depend on a virtual machine, so I assume Objective-C is faster than most of the languages that are nowadays in heavy use.

All of this leaves me somewhat curious about why Objective-C isn’t more popular. Perhaps it is just too much in the middle in terms of performance versus its dynamic nature? Nowadays programming tends to fall into 2 worlds – when you need speed, write in C, but if you want dynamic productivity, use something like a script language: Ruby, Groovy, PHP. Or, at the very least, a language that cleans up variables and memory for you (automatic garbage collection) as in Java and C#. Possibly it is the lack of automatic garbage collection that has kept Objective-C from taking off?

I’ve written about this before. Over the last 30 years women have made dramatic gains in field such as law, medicine, management and science. Almost 50% of new doctors are women, so that is a field that has achieved near perfect equality. But there is something wrong with the tech industry, and with computer programming in particular. The percent of computer scientists who are female and who are earning advanced degrees peaked in 1989 and has since retreated. What explains this retreat, when women are still advancing in almost all other professions?

A month ago, Bruce Byfield wrote about sexism in the free software movement, and his post ignited a firestorm. Now Byfield reflects on the angry reactions that his discussion of sexism invoked:

That brings up another point I’ve learned: people who are not consciously sexist themselves tend to be unable to see institutionalized sexism around them. They are not aware of any prejudice against women in themselves, so how could there be any sexism involved? They seem unaware that institutions and customs can be sexist simply by what they value or how they operate, that even something like a discourse developed by men talking to men can institutionalize sexism. Nor do they understand that, by simply accepting such institutions or ways of acting, they become supporters of sexism.

For instance, I am currently part of an email conversation with a prominent FOSS community member who has been pilloried who is hurt and baffled that I (or anyone else) could apply the word “sexism” to them. Their reasoning? They did not intend to be sexist, so therefore they can’t possibly be. Therefore, labelling their behavior as unacceptable is unfair, they argue. The fact that, in context, their actions and remarks could not possibly be described in any other way honestly does not seem to have occurred to them. No matter what I say, they remain hurt and baffled — and, like so many, deeply in denial.
Cutting across existing lines

…I’m not sure, but I think that the logic here is that if you are already part of an idealistic movement, your actions must be above criticism in every other sense. From that assumption, perhaps it follows that anyone questioning any part of your actions must have the most Machiavellian of motives. The fact that some people who raise issues do seem to enjoy fault-finding because of past grievances only makes this assumption all the easier to hold.

With such painful lessons coming my way, this last month has been shocking, disappointing, and — above all else — exhausting. I’ve lost respect for some people I thought I knew, and gained respect for others. At times, I’ve been happy to escape into writing a purely technical article to take a brief holiday from the endless angst.

Sometimes I reference Calvinball. If people do not know the reference, I send them links. Instead of looking it up on Google every time, I will leave the links here.

There is this strip:

And this link too.

Collaboration is difficult, possibly impossible, when you’re outsourcing:

Between Pixar and Disney we have used a range of production strategies that span everything from complete in-house production to work entirely farmed out, with several mixed strategies in-between. I fully understand both the economic pressures that drive people to outsource work and, of course, the aspirational desires and talent of those doing the work.

Pixar makes its computer-animated films entirely at our studio in Emeryville, California, at what I believe is the highest standard in this industry. But we believe fairly strongly that there’s creativity in every step of our process and that the integration of all those steps – having everyone integrated together and co-located – is what allows us to make exceptional movies. I don’t think we could get to that level of quality if we separated the physical making of the film from the creation of the ideas. If we did, we would not make the same film.

When companies are driven to outsource for economic reasons, there is a disconnect between the creators and makers of products. There is a further disconnect between marketing and the creators. This curious disconnect disproportionately devalues the making and manufacturing of products. I believe that a stronger connection between creators and production leads to much better products.

A list of math blogs and wikis. Useful stuff for when I want to delve further into statistics and data minining.

Leaders are like pieces of cork, floating on the tide. Sometimes the tide lifts them up, and sometimes the tide drops them low. Some great figures stay through a whole cycle: Napoleon was one of the first leaders to capture the energy unleashed by modern nationalism, which briefly lifted up France, and him too. But after 20 years there were nationalist sentiments motivating multiple movements all over Europe, and Napoleon was undone by the same force that initially lifted him up.

Chris Dixon seems to think leaders have a decisive effect on the corporations that they run, though he confines his actual examples to entrepreneurs, and he doesn’t seem aware of what he is doing. His anecdotes about Microsoft and Apple could be re-written into an interesting article about how difficult it is for a company to remain successful after the founding entrepreneur has left. Of course, there are many such companies, and if he was serious about his thesis, he would have written about them, since they offer the strongest case against his idea. AT&T and GE and IBM and Sears are all companies that had remarkable runs of success that lasted 50 to 75 years – runs too long to be attributed to any one particular leader. (If someone would like to reply that all of these companies have hit stumbles, I’d say that is irreverent to the point about leadership – such a point merely establishes that, given a long enough time frame, all things stumble, which is about as insightful as saying that the sky is blue.)

Closures are one of the features that I like most about languages like Javascript and Groovy (Ruby, too, of course, though I don’t use Ruby much). This article on Advanced Javascript techniques highlights closures, and is worth a read. Closures are the only way to introduce private class variables into Javascript. Closures often seem to me to be the way you can introduce into a language anything you think the language is missing. Closures are important to meta-programmng – a common practice in Ruby and Groovy. Closures have finally been introduced in PHP , as of version 5.3, but I have not yet used them in any of my PHP projects. Will be interesting to do so.

I first learned about closures from this old article on Jibbering. I think that is a great article and, even though it focuses on Javascript, I believe you can learn all of the basic concepts about closures by reading that article.

Startups need to keep their software simple. I want to write “at least during the first iteration” but it is probably more accurate to write “at least during the first hundred iterations”. Complexity in software seems to be like entropy – it takes energy to keep it at bay. So I really appreciate this post from Scout, about how they were ambushed by complexity:

We’ve been deleting a lot of code from Scout. We’re ripping out major infrastructure, and in doing so, pulling the plug on functionality which, just six months ago, we believed would be crucial to our business. Most importantly, we’re simplifying the most complex, error-prone, and poorly-performing parts of the application. At the same time, our revenue and sales pipeline is growing at a faster rate.

How did this happen? How did we get to a place where we can remove code and functionality and see our business will grow because of it?

As they say, “mistakes were made.” You don’t get the satisfaction of throwing out a bunch of cruft and performance-degrading features without having gone through the pain of:

Building those features in the first place.
Fighting the performance problems for a few months before you realize its all untenable and come up with alternatives.

…The ongoing cost of complexity is higher than you think. And it’s easy for complexity to sneak in through the back door in the guise of its nemesis, simplicity. Complexity is sneaky that way. Don’t be fooled.

Stuff like this makes me afraid to ever rely on anyone’s cloud services.

BitBucket got hit with a denial of service attack. But they host everything on Amazon Web services (EC2, EBS, etc). So they were dependent on Amazon to figure out what the problem was. And Amazon took 16 long hours to figure out what the problem was. And in the mean time, Amazon kept telling BitBucket that everything was fine:

What came from that, was 5 or 6 hours of advice, some of which were obvious timesinks, while others were somewhat credible. What they kept coming back to was that EBS is a “shared network resource” and performance would vary. We were also told to use RAID0 to distribute our load over several EBS instances to increase the throughput.

At this point, we were getting less throughput than you can pull off of a 1.44MB floppy, so we didn’t accept this for an answer. We did some more tests, trying to measure the bandwidth of the machine by fetching their “100mb.bin” files, which we couldn’t do. We again emphasized that this was in fact, in all likelihood, a network problem.

At this point, our outage was well known, especially in the Twittosphere. We have some rather large customers relying on service with us, and some of these customers have some hefty support contracts with Amazon. Emails were sent.

Shortly after this, I requested an additional phone-call from Amazon, this time to our system administrator. He had been compiling some rather worrying numbers over the past hours, since up until now, the support had refused to acknowledge a problem with the service. They claimed that everything was working fine, when clearly, it was not.

This time, a different support rep. called, and this time, they were ready to acknowledge our problem as “very serious.” We sent them our aggregated logs, and shortly thereafter, they reported that “we have found something out of the ordinary with your volume.”

We had been extremely frustrated up until this point, because 1) we couldn’t actually *do* anything about it, and 2) we were being told that everything should be fine. It felt like there was an elephant right in front of us, and a person next to us was insisting that there wasn’t.

We are pleased to announce that the new E*Society website is now live.

I have a client who wants an app we can roll out to all types of mobile phones (iPhone, Blackberry, Palm, Android). The obvious path is with a web app, but the debugging cycle, on so many platforms, is worrisome. I now learn there are some open source projects to make this easier. Darren Hoyt points me to PhoneGap.

At some point I need to read some of the books suggested in this review. They seem to delve deep into the conceptual underpinnings of computer programming.

I’m just thinking out loud here.

If the cell was like a computer, it would need a processor, and it would need RAM. The nucleus would be the processor, and the endoplasmic reticulum would be the RAM (the Golgi Apparatus would be something like the network router, making sure proteins get sent to the correct places). Processes might be initiated in the nucleus, but some processes would be multi-step, requiring processes and callbacks to be registered in the endoplasmic reticulum. The need to conserve protein would force the adoption of paging (whatever the next process is could recycle protein from the last process). The need for protein conservation would probably also force the adoption of lightweight scripting languages (I mean lighter weight than base 4 DNA). DNA might be the machine language of living things, but a paging system that conserved protein (through re-use) would perhaps use larger molecules that worked at more than base 4. Evolution would encourage a system that was fast enough yet conserved protein.

There would have to be a garbage collector (as in the Java language – something that takes care of cleaning up variables, resources and processes after they are finished). For single celled organisms, the garbage collector would not have to be very good, so long as there was some kind of complete integrity check when the cell divided. Maybe the cell would forget to unregister a callback (or, in real-life, the forgotten unfolded protein), but why would it matter? After 30 minutes of eating, the single-celled organism divides, and undergoes some process that offers a real integrity check. The endoplasmic reticulum starts out clean again in the new cell. This is like a PHP script – no need to be terribly efficient about cleaning up the RAM while the script processes, because it is only going to run for 60 seconds. When it is done, all its variables will cease to exist, all the RAM it was using will be properly reclaimed. But problems arise for multi-celled organism that hope to live a long time. They need cells to stay in place and maintain a certain structure for a long time. The inefficient garbage collector that worked reasonably well for single celled organisms spells death for multi-celled organisms. And why wasn’t this problem addressed? Because rebooting is cheaper than building a perfect garbage collector that can last forever. It is cheaper for a multi-celled organism to have children than for that multi-celled organism to figure out how to be perfect in its use of its resources.

I recall when I was young I asked my dad why people got older, and he said it was because of genetic damage that builds up over time. That was the standard answer back then. My science teacher said the same thing. But of course, that can not be true. A 30 year old male and a 30 year old female can combine to create a child that is 0 years old. That is not possible if aging is a result of genetic damage. Assuming the egg cell and the sperm cell are exposed to the same genetic damage as the rest of the body, then the baby would be 30 years old the moment it is born, since it would be born with whatever genetic damage the male and the female had accumulated. No, to explain aging, we need a mechanism that allows two 30 year olds to give birth to a baby that is 0 years old. This article on aging raises the point:

How exactly does random damage to macromolecules translate into the reproducible and recognizable organismic phenotype we call “aging”? This issue was first raised in 1959 (2), but it still remains unsolved (3). Most often, free radicals or other noxious agents will damage macromolecules in a very stochastic, idiosyncratic fashion. It is difficult to understand how such a random process can lead to the significant and reproducible loss in tissue function observed during aging.

Aging can not simply arise from random accidents, otherwise the incidence of aging would appear as a bell curve, and on the extreme tips of that bell curve would be some individual humans who looked as if they had some age other than their chronological age. There would be the 20 year old with gray hair, dementia and osteoporosis, and there would be the 60 year old who is still able to play pro NFL football, because their body is really 20 years old. And, anyway, no one seriously suggests that the changes in the body of a 3 year old, as it becomes a 4 year old, arise simply from accidental genetic damage. There is clearly a process at work.

Reading on this issue, I get the impression that biologists currently have a model aging that goes like this:

1.) Senescence is used to end an individuals initial growth phase. Only some cells are suppose to enter senescence.

2.) Genetic damage causes other cells to undergo senescence.

3.) Once the body has largely stopped growing, cell death leads to loss of function, as the dying cells are no longer replaced.

About damage, the above article says:

Thus, we propose that aging ensues only when damage is extensive enough, and of a type capable of inducing a cellular response, which often results in either cell senescence or apoptosis.

But this really just moves the question: if aging is caused by senescence, then why does senescence cause aging? Why can’t the cells just live forever, and therefore why can’t the multi-celled organism (for instance, us humans) live forever? This bit is interesting:

There are considerable data indicating that, if a cellular response to damage is not activated, then cells can withstand a significant amount of damage to DNA without the organism showing signs of premature aging (10). Indeed, in most of the mouse models where caretaker functions have been inactivated, an increased level of DNA mutations has been observed as expected, but the mice fail to display an accelerated aging phenotype. For example, Xpc–/– mice accumulate up to 30-fold higher levels of DNA mutations than do their wild-type counterparts, yet there is no effect on their life span (11). A similar, though less dramatic result has been observed in the case of scavenging proteins. … There is a considerable accumulation of unrepaired mutations that has no deleterious effect on life span. … In contrast, mouse models in which the activity of gatekeepers (including telomerase, Wrn, Blm, ATM, or p53) has been manipulated do generally display an accelerated aging phenotype (16–20). In the cases of telomerase, Wrn, Blm, and others, the gene knockout results in generalized genomic instability, including not only double-stranded breaks, but also telomere shortening and/or stalled replication or transcription complexes, both of which appear to be interpreted by the cell as an unrepaired double-stranded break. As previously mentioned, this type of damage leads to activation of a response that culminates in cellular senescence or apoptosis (4). From these data, we must conclude either that genomic instability (but not mutations) plays a role in aging, or that longevity is related to the cellular response of the cell to such DNA damage.

So the cell can take a lot of genetic damage, with no impact on life span, but a few key gatekeepers are needed to watch over things.

Most cells can only reproduce a limited number of times, even when you remove them from the body and cultivate them under ideal circumstances in a petri dish:

Cells divide vigorously and can often be subcultivated in a matter of a few days. Eventually, however, cells start dividing slower, which marks the beginning of Phase III. Eventually they stop dividing at all and may or not die (reviewed in Hayflick, 1985; Hayflick, 1994). Hayflick and Moorhead noticed that cultures stopped dividing after an average of fifty cumulative population doublings (CPDs). This phenomenon is known as Hayflick’s limit, Phase III phenomenon, or, as it will be called herein, replicative senescence (RS).

The limit depends on the type of cell and the species it is from:

Early results suggested a relation between the number of CPDs cells undergo in culture and the longevity of the species from which the cells were derived. For example, cells from the Galapagos tortoise, which–as described–can live over a century, divide about 110 times (Goldstein, 1974), while mouse cells divide roughly 15 times (Stanley et al., 1975; Rohme, 1981).

But some cells are immortal:

Exceptions exist and certain cell lines never reach RS. These are said to be “immortal” and include embryonic germ cells and most cell lines derived from tumors, such as HeLa cells (Brunmark et al., 1986; Chen and Yu, 1994; Pera et al., 2000). Some types of rat cells have also been claimed as capable of evading RS (Mathon et al., 2001; Tang et al., 2001).

And, of course, in recent years, scientists have figured out ways to roll back specialized cells and make them more like embryonic stem cells.

As things stand now, if one of your cells suffers a certain kind of damage, it will become senescent, and then it becomes a risk for cancer. If it accumulates more damage of a certain type, it will eventually develop into cancer. So why does the body allow such cells to exist? Why not kill all such cells? The most obvious answer to that is that, once the body has stopped generating a lot of new cells, it can not afford to kill off all of its existing cells. It needs to hang on to them, with the hope that you, damaged as you are, can live long enough to raise children.

Here is an avenue I’d like to research (perhaps some day I will switch careers): what if all senescent cells in your body were forced to die, and your body was allowed to grow new cells? This assumes that science develops a reliable method for getting particular genetic commands to one’s cells – but there are experiments with using genetically engineered viruses that are getting closer to that goal.

I’ve read that senescence is unique to vertebrates. To put that another way, senescence is unique to creatures that have central nervous systems. Lately I’ve been wondering if the nervous system is the main reason our bodies do not already do what I’m suggesting – why not kill off all the senescent cells and replace them with younger cells? While it would be great to have new muscle cells and new bone cells and new kidney cells and new colon cells and new skin cells, it generally would not be a good thing to casually kill off nerve cells. That is where vertebrates store everything they’ve learned. Tadpoles spend several days learning how to swim, no doubt it would be suicide for an adult frog to suddenly forget how to swim in water – evolution will not allow the emergence of a vertebrate that loses crucial skills as an adult. But humans are in a unique situation. We can afford to retire from life – we already do so. We could retire from life for 4 or 5 years, and be helpless, and have nurses take care of us. We could afford to forget how to walk and talk and eat – some already do this when they are old. But the way things work now, when humans reach that point, they usually only go a few more years and then they die. It is fascinating to think where we will be when we know how to order our cells to die off and then renew. Then we would retire from life for a few years, relearn skills, and then return to life, made young again. We would not die, though there would be a sorrow like death, as we would probably suffer massive amnesia, depending on how many of our nerve cells renewed. Our friends would regret the disappearance of the person they knew and loved. They would have to learn to live with the fact that the soul is transitory and does not last, even as the body lives on forever.

Ben Hughes and I share a similar kind of bigotry:

I am a programming languages bigot. There — I admit it. I write Rails code for startups and turn my nose up at those who slave away in Eclipse working with Java. I have always assumed that the promised land of modern, dynamic languages bears fruit for anyone who seeks it.

I never really considered the “why” of Java, as that would interfere with my unbridled hate. My Software Engineering class is centered around the Miltonian task of justifying Java’s ways to man. The professor constantly harps on the benefits for maintenance that the safety, strictness, and explicit verbosity provide to the development team, yet dynamic languages feel more productive and seem to entirely outstrip Java development in getting things done.