Archive for April, 2009

Television is dangerous to your finances

Wednesday, April 29th, 2009

Televisions are bad, bad, bad:

To put it into perspective, if you watch an average of 31.5 hours of TV each week (which the average person in the US does) and you value your time at minimum wage of $5.85 an hour, you are spending nearly $800 a month ($798.53) to watch TV. That comes to nearly $10,000 ($9582.30) a year. I would imagine that most people reading this value their time well above minimum wage, so the cost is likely several times that number. When you look at it from that perspective, watching TV is an extremely expensive and financial draining habit to have.

Installing multiple versions of IE on your machine

Wednesday, April 29th, 2009

I am sometimes called in to help designers wrestle with CSS issues on old versions of IE. Also, I have often have to get Javascript working on old version of IE. Old versions of IE are, of course, a notorious pain, but a lot of people still use them. I just discovered this package, which will install all the old versions of IE on your computer. Very, very handy.

Getting “top” and “left” of an element using Javascript

Friday, April 24th, 2009

Vishal Astik has a great post on getting “top” and “left” on an element using Javascript. As with most things Javascript, nowadays, the problem is making it work in IE6. His key point is this:

I always use Mozilla Firefox(FF), so when I tested my code it worked perfectly.But, when I tested this code in Internet Explorer 6(IE6) the offsetTop did not work correctly.

I used Google my best friend to find the answer, and here is what I found

“When your element is nested inside other elements or when it has elements above it with position relative or absolute, element.offsetTop does not work properly in IE6.”

…But the important function GetTopLeft(elm) is what you should have a look at, if you want to find Top and Left of element using Javascript.

function GetTopLeft(elm)

{

        var x, y = 0;

    //set x to elm’s offsetLeft
    x = elm.offsetLeft;

    //set y to elm’s offsetTop
y = elm.offsetTop;

    //set elm to its offsetParent
    elm = elm.offsetParent;

    //use while loop to check if elm is null
    // if not then add current elm’s offsetLeft to x
    //offsetTop to y and set elm to its offsetParent

    while(elm != null)
     {

        x = parseInt(x) + parseInt(elm.offsetLeft);
        y = parseInt(y) + parseInt(elm.offsetTop);
        elm = elm.offsetParent;
     }

    //here is interesting thing
    //it return Object with two properties
    //Top and Left

    return {Top:y, Left: x};

}

I just had to wrestle with this today, so I found this a handy tip.

Upgrading Symfony can a real hassle

Thursday, April 23rd, 2009

So I just upgraded a site from Symfony 1.1 to Symfony 1.2. Normally, with other software, a small increment upgrade does not cause much pain. However, Symfony 1.2 introdced changes to several configuration files, and it also changed how some core classes behave. So the upgrade is more like going from the 1.0 version of software to the 2.0 version.

You might ask, “Can’t they automate the upgrade?” Oddly enough, they wrote an upgrade script, and yet it is quite limited. Even after you run, you still need to tweak several configuration files by hand. Normally I think of Symfony as being better than WordPress in every conceivable way. And yet, here is something WordPress does well – their last few upgrades have been painless, because they’ve written excellent upgrade scripts.

It’s possible that on this issue, the quality of the people working with Symfony allows Symfony to get away with less in the way of upgrade scripts. After all, WordPress is, in a sense, a consumer product. The designers who love it tend to be fairly non-technical. They need a lot of hand-holding. By contrast, the people using Symfony tend to be highly experienced. They need less hand holding.

I was happy to discover that the VACS blog had already written up their own experiences upgrading Symfony. That article is very useful. However, there is at least one upgrade issue they don’t mention, which is that the database configuration file now has a completely new format. And, even worse, the official documentation on this, on the Symfony site, is inaccurate (though someone just raised a ticket about this yesterday, so hopefully it will be fixed soon). To help out everyone else who might be upgrading, I mention that the command looks like this:

symfony configure:database “mysql:host=someHost;dbname=dbName” username password

And in the end, your databases.yml file should look like this:


dev:
  propel:
    param:
      classname: DebugPDO

test:
  propel:
    param:
      classname:  DebugPDO

all:
  propel:
    class: sfPropelDatabase
    param:
      dsn:        mysql:dbname=zzz;host=localhost
      username:   zzz
      password:   zzz
      encoding:   utf8
      persistent: true
      pooling:    true
      classname:  DebugPDO

Note the final use of DebugPDO. By default it is PropelPDO, but if you use PropelPDO, then your SQL queries will no longer appear in the debug toolbar – and being able to see the SQL is very useful when one is debugging.

Brad Delong is to the left of the Obama administration

Sunday, April 19th, 2009

I think it’s tragic that Brad Delong is finding himself to the left of the administration of President Obama. Especially on the banking issue. Delong is a far cry from radical. Many on the far left have been uncomfortable with his positive view of markets. I recall the mailist that Doug Henwood ran in the mid-90s, where the radicals would call Delong a conservative or a right-winger, because of his celebration of the utility of markets. In a perfect world, Delong would represent the exact center of American politics, and then around that center would be the various left and right factions, each trying to pull the government in their direction. That Delong is not at the center of American politics, even when America has a nominally progressive President, leaves me worried that there is something fundamentally wrong with the political culture in the US.

How do you get data from one domain to another using Javascript?

Tuesday, April 14th, 2009

Recently I was asked to fetch data from one domain and use the data to update a website on another server. Let’s call these sites site1 and site2. The problem we faced was that site2 was a weblog powered by Blogger, which doesn’t allow a website owner to run any server side code. So we couldn’t use Java or Ruby or PHP. Instead, all we could use was Javascript.

My first thought was, “No problem! I’ll just do an Ajax call to get the data.” However, this does not work. The Javascript security model enforces a Same Origin Policy on Ajax. If you, with your web browser, go to site1, then the Javascript that your browser downloads can only make calls against site1. The Javascript can not make an Ajax call to site2.

Of course, when you look around the web, you see hundreds of sites that appear to be getting around this problem. For instance, all of the mashup sites that do interesting things with the Google APIs are clearing getting data from Google, somehow.

The answer is apparently what is known as the Script Tag Hack. The script tag is not effected by the Same Origin Policy. You can import data from somewhere else by putting this on your page:

<script src=”http://www.site1.com/neededInfo.php”></script>

In this example, the PHP script neededInfo.php (which is on site1) can output whatever info the Javascript on site2 needs to import. There are two tricks to make this work:

1.) The PHP script neededInfo.php (which is on site1) needs to wrap the data in a call to whatever Javascript function will be used on site2 to handle the data. So you might output the data like this:

updateComments({ ‘/93467763726066064′: ‘255′, ‘/3687512778221280499′:
‘154′, ‘/7469483397667998711′: ‘69′, ‘/3546694631903279790′: ‘86′, ‘/
7826626581502083668′: ‘257′, ‘/7863118590857837142′: ‘3′, ‘/
4528442172302293469′: ‘121′, ‘/4746505715184542507′: ‘125′, ‘/
3734446988393833799′: ‘242′, ‘/3855898527917724656′: ‘190′, ‘/
2322556671825296195′: ‘89′, ‘/7828790542573728707′: ‘83′, ‘/
7789277747613265886′: ‘137′, ‘/856477599963783632′: ‘109′, ‘/
170917561786384883′: ‘119′, ‘/2415194963852019364′: ‘66′, ‘/
4594614219998113399′: ‘106′, ‘/8621485541364545191′: ‘297′, ‘/
2546912594140426303′: ‘159′, ‘/2124986657277402452′: ‘284′, ‘/
294853826990957498′: ‘112′ })

This is all that should be on the page, just this, nothing else. Now updateComments() is the Javascript function that will be called on site2, when the script is imported. And the call to add in this script should happen only after the page is done loading. So when your browser downloads all the HTML from site2, a script tag is added to the page, which imports this from site1, and which calls the Javascript function updateComments, which is being handed a block of JSON info, which can be treated, inside of updateComments, as any other Javascript object.

2.) This needs to run after the page is done downloading. There are a number of good scripts for ensuring that something happens after the page is done downloading. I’ve often used Simon Willison’s script. Or, if a site is using jQuery, you can just register it as a function to run inside of the ready() method:

jQuery(document).ready(function() {
getSomeData();
});

Or you can just do things the simple way:

window.onload= function () {
getSomeData();
};

In the function getSomeData(), you’d then add a script tag to the page, using DOM methods:

var script= document.createElement(’script’);
script.type= “text/javascript”;
script.src=”http://www.site1.com/neededInfo.php”;
document.body.appendChild(script);

This is, apparently, the only way to get data from one domain to another, using Javascript.

I’m grateful to Jorge Chamorro for helping me understand this issue and for putting up an excellent example.

The end of globaliziation?

Tuesday, April 14th, 2009

Interesting post by Brad Sester, suggesting we can expect a pull back from the global economy:

The FT – more than most – has recognized the challenges created by a global banking system and national regulation. A recent leader argued: “The current mismatch of globalised finance and national governance is unsustainable. Either governance becomes more globalised or finance less globalised.“

My guess is that finance will necessarily become a bit more national. The current crisis has shown than highly leveraged intermediaries require a government backstop, and for now there is no global taxpayer willing to bailout global banks that go bad.

Finance has traditionally been the most international of all types of business. This is true going back centuries, to when the merchants of Venice were making loans to the Ottaman Empire, and Genoa was helping Spain finance explorations of the New World, way back in the 1400s. If finance pulls back, then surely all other forms of industry are likely to pull back as well.

How much, or how often, should a design idea be discussed?

Monday, April 6th, 2009

One of the tough calls to make, when managing a project, is figuring out how much time should be devoted to talking things over. If you are the manager, there are two mistakes that you might make:

1.) You cut off conversation too soon, before the designer has had a chance to defend their idea, or before the client has had a chance to fully articulate their dissatisfaction, or before your programmer can explain why one option would take more time, and therefore more money. You force a decision to be made before all the facts are in. Possibly you kill the conversation just as people are warming up to what would be a brilliantly creative set of insights, if only you allowed more time.

2.) You allow the conversation to go on too long. After awhile, people begin to repeat the same points they made 4 hours before, or perhaps the day before. Your team begins to fear these conversations, which seem to be endless swamps of unproductive debate. The team craves action, decisions, movement, they want to finally be building something, but instead you keep pushing for more information, another round of opinion gathering.

It is difficult to find the right balance. I suspect we all have our preferences about what we consider the right level of conversation versus action.

Over at 37 Signals they’ve posted an extended chat that Jason Fried and Ryan Singer had about adding a new feature to Basecamp. It is useful to see how such a well known and successful team works through their design issues.

(14:42:41) Jason Fried: What are some of the pushback points we’re anticipating?
(14:43:02) Ryan Singer: “i use milestone attachments for [some crazy custom reason] and this doesn’t apply to me”
(14:43:30) Ryan Singer: possibly: “i want dates on my to-do items, not the lists themselves”
(14:44:12) Ryan Singer: i don’t think the first point is a problem
(14:44:18) Ryan Singer: there are always people who bend the interpretation
(14:44:51) Jason Fried: What if the date thing said “On or before March 14”
(14:44:59) Jason Fried: I think the ridigness of it may be a problem.
(14:45:03) Jason Fried: And this could soften that a bit
(14:45:05) Ryan Singer: a bit long, but i like that idea
(14:45:52) Ryan Singer: hm kinda long
(14:46:08) Ryan Singer: becomes harder to interpret too

I know that in such conversations I tend to defer to the designer, and I tend to want to reach a conclusion quickly. Probably because I’ve been in so many, many meetings where someone else forced the conversation to go on for many more hours than was needed, I tend to play the role of the person who is willing to reach a quick agreement. Ryan Singer reminds me of myself, in this portion of the chat, where he seems willing to go along with the “Due by” language, even though he initially disliked it. He seems eager to reach a final agreement.

(14:46:35) Jason Fried: After seeing this the issue I have is the rigidity of it.
(14:46:42) Jason Fried: This list IS DUE on this date
(14:46:45) Jason Fried: Well, not really
(14:46:57) Jason Fried: It’s part of a milestone that is due on this date.
(14:47:07) Jason Fried: So I’d like to see if we can figure out how to present that reality a bit better
(14:47:15) Ryan Singer: good point
(14:47:18) Ryan Singer: ok
(14:47:41) Jason Fried: how about
(14:47:47) Jason Fried: “Due by 14 February”
(14:47:49) Ryan Singer: “Milestone: 14 February”
(14:48:03) Ryan Singer: nice that Due by is shorter
(14:48:05) Jason Fried: Milestone may work. Ties it into the feature.
(14:48:07) Ryan Singer: shorter is better for this flag
(14:48:12) Ryan Singer: even “Milestone: 10 Feburary” is quite long
(14:48:13) Jason Fried: Due by is less rigid than “Due on”
(14:48:15) Ryan Singer: doesn’t hold together as well
(14:48:16) Ryan Singer: yeah
(14:48:37) Ryan Singer: Due by looks pretty good. screenshot coming

But Jason Fried won’t be rushed into a decision. Instead, he keeps the conversation going, even though Ryan Singer was willing to go along with “Due on”.

(14:55:14) Jason Fried: Due is good, but it’s an opinion 5 years after the fact.
(14:55:20) Jason Fried: That’s why I’m pushing back a bit.
(14:55:30) Jason Fried: We’re not introducing attachments today
(14:55:37) Jason Fried: If we were I’d feel better about it.
(14:56:15) Ryan Singer: i think if we don’t go with “Due..”
(14:56:26) Ryan Singer: it would be better to explore moving the link below the title into the list description area
(14:56:30) Ryan Singer: and actually naming the milestone or something
(14:56:41) Jason Fried: right like…
(14:56:54) Ryan Singer: like “For Ship v1 of the Home Page, 14 Feburary”
(14:56:57) Jason Fried: “This to-do list is attached to a “milestone name” which is due on 14 Feb”
(14:57:23) Jason Fried: I feel like we don’t lose anything with that direction.
(14:57:27) Jason Fried: And we gain clarity

If you read the whole transcript, you can tell these two are getting warmed up as the conversation continues – they are thinking hard about this problem, and they are getting deeper and deeper into the nuances. I relate to this chat quite a bit, as it reminds me of so many of the more productive meetings I’ve been in.

Finally, an hour goes by, and Jason Fried keeps pushing them until they arrive at what they both agree is the perfect answer:

(15:20:08) Jason Fried: In the app we say “Attach to…” so I wonder if we should repeat that here.
(15:20:18) Ryan Singer: i would rather change the language in the other places
(15:20:23) Ryan Singer: “Attached to” looks weird here
(15:20:28) Ryan Singer: and it doesn’t fit with the normal expectations of what an “attachment” is
(15:20:36) Jason Fried: K. We don’t want to change the language elsewhere so we’ll consider that one a no go.
(15:20:39) Jason Fried: Umm…
(15:20:46) Jason Fried: “Related to” works for me.
(15:20:47) Jason Fried: Cause it is.
(15:20:51) Ryan Singer: actually the edit dialog says this:
(15:20:55) Ryan Singer: “Does this list relate to a milestone?”
(15:20:58) Jason Fried: Perfect
(15:20:59) Jason Fried: Done
(15:21:02) Ryan Singer: done

The dangers of having a so called “positive attitude”

Monday, April 6th, 2009

I’m going to talk about a real project from a year ago, but I’m changing the name of the project to “Tango”. Here is part of a message that I posted, several months ago, to the Tango project area on our Basecamp account:

Traffic to the website is down 12%. All of the effort expended to encourage people to use the chat rooms has shifted traffic around on the site, but it hasn’t lead to an increase in traffic. Also, the money spent on Facebook ads has turned out to be a complete waste of money – for the number of new visitors that Tango got, twice as much money was spent than would have been spent using the same money to hire new writers.

To some extent, I was criticizing strategies that had been proposed by other people, but which I’d been willing to go along with to see how they might work out. Part of the reply that I got from one of my co-workers:

I’d appreciate a more positive attitude.

I am increasingly afraid of “positive attitudes”. Or rather, what is often called a positive attitude. A project is in deep trouble when the people working on it fail to point out the weaknesses that they see. How can improvements be made without criticism?

Never mind what the real meaning of the phrase “positive attitude” is. As a practical matter, in a business context, what it usually means is “Let’s ignore the bad news and focus on the good news.” But such an attitude only makes sense if you believe the bad news is unfixable. In other words, the bad news indicates that the whole project, the whole company, is doomed. So what is often referred to as a positive attitude is, in fact, a profoundly pessimistic attitude.

In truth, I have a positive attitude: I believed, and still believe, that the project will be a great success. But only if the project’s weaknesses are addressed. And if you look at what I wrote in my Basecamp post, you’ll see it implies a number of things that should be fixed, and which are probably fixable.

What is the point of this thing called a “positive attitude”? Much of it is political – a desire to avoid facing painful realities. Often this is done to keep together a coalition of people – that is, to keep a group of people supportive of a project. We might be talking about the Iraq war, where the American government has relentlessly painted a prettier picture than what reality justified – and this lying was meant to keep the American people supportive of the war. Or we might be talking about a money losing business, in which case the workers and managers might by lying to the investors, so as to keep the investors supportive of the business. And for those who want to make their living that way, this is the one real use of a “positive attitude”.

This is the only positive attitude that a project really needs: the belief that a project can succeed. Once you have that belief, everything else should be criticism: what isn’t working, what needs to be fixed? Happy talk is the enemy of truth, and lies are an effective way to take a viable project and kill it.

Jacek Utko offers brilliant design as a way to save newspapers

Monday, April 6th, 2009

This video is only 6 minutes long, and, if you have the slightest interest in the issue of the future of media, then it is very much worth watching. Jacek Utko relates his own experience using design to rescue newspapers in Eastern Europe. I think this idea can be boiled down to: “Newspapers need to become more like magazines.” That is a solid idea. After all, before the financial crisis, magazines were doing well, and they will probably do well again as soon as the recession ends.

The newspapers are doomed, part VCXXXIII

Monday, April 6th, 2009

One of the strongest arguments for protecting today’s newspaper’s is that they are vital sources of objective information. However, in practice, they are less altruistic than they are supposed to be. Some of the less pleasant realities of journalistic practice undermine their claim that society will suffer harm if daily newspapers disappear.

Matt Yglesias comments:

[P]art of the peculiar set of institutions that constitutes “journalistic ethics” is the idea of a “beat-sweetener.” This means that when a new set of powerful people is put into place, and most of all when a new presidential administration comes to DC, you see a flurry of journalists penning lavishly flattering profiles of different key players. The idea is that the key player in question and his staff will then become a useful source of future information. I don’t think anyone ever quite admits that a piece they’ve handed in is a beat-sweetener, but people in the game generally know one when they see one and it’s frequently joked about and so forth.

Duncan Black points out how much this underines the idea that society can not survive without these media institutions:

I think the main issue with beat sweeteners is that they’re part of a whole host of journalistic practices which aren’t especially pretty… and more than that, they’re practices that the public is largely ignorant of. There’s a lack of transparency in journalism which is often at odds with the great degree of self-righteousness regularly exhibited by some in the profession. You can’t simultaenously be a superhuman devotee to truth telling and someone who writes stories deliberately to curry favor with sources. Such practices might at times be, on balance, good for the overall goal of providing information for readers (though frequently they’re probably just good for the overall goal of personal career elevation), but they’re also a reminder that journalism as practiced is not the pristine objective truth machine that some suggest when writing columns about how bloggers suck.

Creole is dead, developers decide to move to Python and give up on PHP

Sunday, April 5th, 2009

Last summer I started to learn the Symfony web framework. At that time, it defaulted to using Propel as its ORM. Propel, in turn, relied on Creole for database abstraction. The developers of Creole have decided to abandon their project, and move on to Python. I found this interesting:

I have recently spoke with Hans (the creator of Creole) and we are in agreement that Creole is a dead project. I believe the current code base, including the beta that never got pushed to production, is pretty stable. However, I have chose to move to Python, mostly because of a frustration with PHP leadership and what appears to me to be a lack of focus and the difficulties I have encountered with the way PHP leadership handles bug reports. There are definitely a lot of drawbacks to Python web development, namely the fact that there are so many choices and that you have to work on a much lower level to get things to work (oh, and the docs are really bad when compared to PHP). But the benefits so far have far outweighed the drawbacks and I much prefer the perspective of the Python leadership and community.

Hans Lellelid, the main developer of Creole, wrote a further note:

Yeah, a language is just a language. But I will say that when things like inconsistent error handling bite enough times, you do start wondering if all languages are really created equal.

I don’t think a language should be driven by democracy; I think that has fared very badly for PHP. Things keep getting tacked on without any real fixes to the underlying architecture; result is a product that has lots & lots of “seams” revealing fundamental disconnects between the paradigms that are being used to develop the code and the underlying structures.

This contrast between PHP userland (where we get exceptions, file streams, objects) and the engine core seems like it’s paralleled by the difference between the user community and the internals developers. The developers added these features that users clamor for and vote on, but they clearly either don’t understand the features in the first place (or how they will impact other parts of the language) or never really intend to use the features themselves. If the measure of this success is simply how many servers are running PHP, I’m sure this strategy is working fine. If the measure is how many PHP open-source projects are thinking about software architecture, innovative web-based server paradigms, and enterprise-scale design, then I don’t think it’s been so successful.

On more of a rant/stream-of-thought note, I wonder if PHP is ready for the next generation of web applications. It worked great for creating HTML templates, but are people building new applications today really using PHP to generate HTML? Maybe they are, but everything seems to be moving to a model where the backend is just a services layer. PHP doesn’t offer any advantages over other languages when it comes to a simple web services layer; heck, Java even starts to look easy if all I’m doing is writing a JSON-RPC server that talks to a database. The multiple-page model for serving requests no longer makes sense; instead you have some sort of front controller — so now you’re using a framework. And all of these languages have frameworks, but languages like Java and Python not only have web frameworks but have framework API standards. They’ve been thinking about this for a lot longer, and it shows. So I think that PHP as a solution needs to evolve at the engine level (with things like namespaces + built-in phar, etc.) AND it needs to evolve at the community level (with new standards and framework specifications). I’m not sure either type of evolution is really compatible with PHP’s democracy-driven development model.

The need for moderate and universally fair rules for trade

Saturday, April 4th, 2009

In the early 90s, during the recession, I read the newspapers and formed the impression that some of America’s major trading partners were treating America unfairly. Japan, in particular, seemed intent on boosting their own exports, without much thought to how their actions would effect America. At that time, I thought America should take unilateral action to set things right. Some of the policies that I would have supported at that time were immoderate. I was puzzled why the Federal government, under both President Bush and then under President Clinton, were so very careful and moderate in their dealings with America’s trade partners. All I could think of at the time was that the Federal government didn’t understand how hard the recession was for many people.

Nowadays, of course, I see things differently. A wealthy and powerful nation, such as America, has clearly benefited from the current world economic system, and thus America’s own self interest is best served by it making some sacrifices to keep the system working. The system will survive only if most nations feel the system is fair, so America has a self-interest to see that most nations see that the agreements that create the system are fair and universal to all.

John Maynard Keynes offered some very good advice back in the 1930s about the dangers of protectionist policies that damage trade:

In The General Theory of Employment Interest and Money Chapter 23 Notes on Notes on Merchantilism, the Usury Laws, Stamped Money and Theories of Under-consumption Keynes argued that back in the bad old days, going for the gold was the only feasible approach.

Now, if the wage-unit is somewhat stable and not liable to spontaneous changes of significant magnitude (a condition which is almost always satisfied), if the state of liquidity-preference is somewhat stable, taken as an average of its short-period fluctuations, and if banking conventions are also stable, the rate of interest will tend to be governed by the quantity of the precious metals, measured in terms of the wage-unit, available to satisfy the community’s desire for liquidity.
At the same time, in an age in which substantial foreign loans and the outright ownership of wealth located abroad are scarcely practicable, increases and decreases in the quantity of the precious metals will largely depend on whether the balance of trade is favourable or unfavourable.

Thus, as it happens, a preoccupation on the part of the authorities with a favourable balance of trade served both purposes; and was, furthermore, the only available means of promoting them. At a time when the authorities had no direct control over the domestic rate of interest or the other inducements to home investment, measures to increase the favourable balance of trade were the only direct means at their disposal for increasing foreign investment; and, at the same time, the effect of a favourable balance of trade on the influx of the precious metals was their only indirect means of reducing the domestic rate of interest and so increasing the inducement to home investment.

That does *not* mean that Keynes was a merchantilist. In particular one can imagine how delighted he was by a process that enriched the USA at the expense of Europe.

For this and other reasons the reader must not reach a premature conclusion as to the practical policy to which our argument leads up. There are strong presumptions of a general character against trade restrictions unless they can be justified on special grounds. The advantages of the international division of labour are real and substantial, even though the classical school greatly overstressed them. The fact that the advantage which our own country gains from a favourable balance is liable to involve an equal disadvantage to some other country (a point to which the mercantilists were fully alive) means not only that great moderation is necessary, so that a country secures for itself no larger a share of the stock of the precious metals than is fair and reasonable, but also that an immoderate policy may lead to a senseless international competition for a favourable balance which injures all alike.[4] And finally, a policy of trade restrictions is a treacherous instrument even for the attainment of its ostensible object, since private interest, administrative incompetence and the intrinsic difficulty of the task may divert it into producing results directly opposite to those intended.
Thus, the weight of my criticism is directed against the inadequacy of the theoretical foundations of the laissez-faire doctrine upon which I was brought up and which for many years I taught;— against the notion that the rate of interest and the volume of investment are self-adjusting at the optimum level, so that preoccupation with the balance of trade is a waste of time. For we, the faculty of economists, prove to have been guilty of presumptuous error in treating as a puerile obsession what for centuries has been a prime object of practical statecraft.

A startup that involves technology must have good technolgists on the core team, right from the start

Friday, April 3rd, 2009

Keith Casey writes a brilliant post about the need for technology experience on a team launching a firm that involves technology. This is a post that I wish I’d written, because it says a lot of things I’ve been thinking for the last year or two:

If you’re selling the best hamburger ever or making signs or running a franchise, most of the time, your technology can be an afterthought.

But if you’re building a social network, creating a new ad network, building a mobile phone platform or any number of other things, the technology is the core to what you’re doing.

That has some major implications. It means:

  • First, you have to consider it from day one. You have to know how it fits with what you’re doing. What goes into it, what doesn’t, and get an idea of your budget (time, $’s, etc).
  • Next, you need a technologist in the mix to figure out the boundaries. You need to know what is and isn’t possible and how to approach the process… more importantly, you need to know how to approach things, schedule things, and what “It’s 90% done!” really means. ;)
  • Next, you need a technologist in the mix to filter the candidates. When you don’t know what you’re doing (fact, not judgement), you need someone who does to find the right people to hire and filter out the posers.
  • Finaly, you don’t outsource it. I don’t mean offshoring, but that could be included. I mean the people who know your product – because they’re building it! – should be part of your organization.

Failure to have a serious tech person involved causes some terrible decisions.

For example, I recently tracked the progress of an angel-funded startup:

  • First, since they lacked any technical background, the sole developer-turned-investor promptly developed the entire application… in ColdFusion.
  • After that caught on fire and sunk into the swamp, they decided to rebuild it in .net… er… Rails… er… PHP. Their “technologist” didn’t have any experience in any of them and was therefore open to anything.
  • Next, since they developed their “architecture” (aka PHP), they began recruit for PHP-types. Since none of them had any experience whatsoever in PHP, they hired the first PHP’ers that could pass the single-round phone screen.
  • Finally, they called the ColdFusion version of the application a “reference implementation except for the wrong parts” and didn’t bother writing the spec as a result.

Fast forward a few months and inside reports say the team is in shambles, the project is months late, and major portions of it are being rebuilt from the ground up.

This strikes me as obvious, so I’m astonished when I run into a differing attitude. Yet just in the last year, I’ve had 3 different clients or potential clients who wanted to build online social networks and who thought they could leave the details of building the website to an outside team.