Disagreeing With Paul Graham: How Not To Pick A Platform

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.



And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:


Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:


Subscribe to Updates


30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn


Current Articles | RSS Feed RSS Feed

Disagreeing With Paul Graham: How Not To Pick A Platform


I am one of the many thousands of raving Paul Graham fans out there.  I’ve read most of his content (Paul doesn’t write blog articles, he writes essays).  He is clearly a very gifted writer.  He is also very, very smart (and I rarely use two verys).  But, at least on one point, I humbly submit that he is very wrong.

In the most recent essay, titled “The 18 Mistakes That Kill Startups”, Paul identifies (as you might expect from the title) the common causes of startup failure.

I’d like to focus on point is #17:  Choosing The Wrong Platform

I agree with Paul that picking a wrong platform can indeed sometimes kill a startup, but I’m not yet convinced that this is always the case.  History is replete with startups that picked what were widely considered to be the “wrong” platform and still survived to tell the story (and make a ton of money in the process).  One example would be MySpace and their use of ColdFusion (not that Cold Fusion is a bad platform, but most hacker-types – and particularly those that follow Paul, would likely categorize it as a sub-optimal platform).  There are other examples of startups that succeeded (some modestly, some spectacularly), despite having chosen the “wrong” platform.  One additional example that comes to mind is eBay’s early use of Microsoft’s platform (ISAPI DLL written on top of IIS).

But, this is not my primary point of contention with the article.  Little harm is done by identifying wrong platform selection as a potential mistake that startups should try and avoid (in fact, I think it helps to raise awareness of the importance of this decision).  My issue is with how Paul advises startup founders go about actually picking a platform.

Paul Graham:   “How do you pick the right platforms? The usual way is to hire good programmers and let them choose. But there is a trick you could use if you're not a programmer: visit a top computer science department and see what they use in research projects.” 
I agree with the first half.  A great way to pick a platform (if you’re not a programmer yourself) is to hire great programmers (not just good ones) and let them choose.  But, I don’t think visiting a computer science department and seeing what they use in research projects is an effective strategy.  Here are my issues with this particular approach:
  1. Being a prior computer science student myself, I have a bit of a feel for how platforms get picked for research projects.  Rarely do these coincide with how startups in the real world work.  People in academic research projects are often solving for a very different problem with very different motivations than a startup.  Lots of research projects are a learning exercise.  Most startups are a building exercise.  The desired outcomes are often vastly different.

  1. The platform selection process is sometimes domain and/or user specific.  For example, though Python is a cool language (and I’m sure there are many academics that like it), if you are seeking to build the next big killer desktop application to run on Windows, it will likely prove to be a fatal choice.  The reason is simple.  From a user’s perspective, they expect a Windows application to look and feel like a Windows application.  Chances are, your Python desktop app won’t quite feel “just right” (the user’s dog will bark at it).  This is a case where the users do care about the platform choice because it actually impacts what they experience.  Similar arguments can be made for other target areas like mobile applications.

  1. There may be other dependencies (i.e. integration points) that influence your decision.  As a startup, if you are building an application that will be an extension of an existing application (or consume its services somehow), it often helps to pick a platform that is conducive to that integration.  For example, if you’re building an Outlook plug-in, you probably don’t want to use Ruby for that (even though it might support COM).  

Basically, it seems that Paul thinks that all startups are going after “change the world” strategies and don’t need to concern themselves with user preferences, business domains or the need for integration with existing systems.  Though it would be great if this were true, it’s really not.  

What do you think?  Am I off-base here?  Are all of you writing world-changing software applications that need to use the higher-end languages and platforms from computer science research groups?  Or, are at least a few of you taking a less glamorous (but practical) approach?

Posted by admin_halligantravel admin_halligantravel on Tue, Oct 17, 2006


The success of ventures such as E-Bay and MySpace who built their business on wrong / un-cool/ unpopular / sub-optimal platforms goes to show that the platform is not critical to the success of the business.

However choice of platform will determine the size of your market, as stated by Eric Sink -

"Technology choices have big marketing implications. When you choose a platform, you define the maximum size of your market."

Also regarding current fad platforms -

"...if you are building products or solutions to be used today, there isn't any shame in choosing a platform and toolset which has completely proven itself as more than a fad."

(Excerpt from http://www.ericsink.com/laws/Law_21.html )


posted on Tuesday, October 17, 2006 at 1:45 AM by Scott Carpenter

Yes, I think you're a bit off your rocker here. :-)

3: If you're building a startup around an Outlook plug-in, well, you have bigger problems, but then Outlook is the platform. Ruby is just the implementation language, and one the user won't even ever see.

2: Python, again, is a language, not a (complete) platform. Users don't care what language something is written in (and I was surprised to learn the implementation language for several apps I use every day) -- what they do care about is the GUI toolkit, because that's what they see. C++ may be the native language of Windows, but you can pick the right or wrong GUI toolkit in any language.

This point has an easy counterexample, too: Firefox uses its own GUI toolkit, and is largely implemented in Javascript, and it's kicking ass and taking names. For a startup, building your own toolkit+VM is not an efficient approach, but at least a few companies are building on top of Gecko, so initial work aside, it's turning out to be workable.

Even sucky GUI toolkits, if attached to a cool product, work OK. The canonical example here is WinAmp, which would have been absolutely horrible ... except that it was way cool.

1: I'll give you a half point here, because some CS projects are just crazy. But a surprising number aren't. Look how many companies were started directly out of CS departments. And remember, whatever CS departments are cooking up today is what the rest of the world will be using in a couple years, anyway; picking a niche platform today from a CS department could easily be riding the crest of the wave when your product ships next year. I'd love to be in that position.

posted on Tuesday, October 17, 2006 at 2:05 AM by Ken

Instead of visiting a nearby CS department, which I agree is hardly a good idea, I would suggest to Paul that startups instead do like they should everything else: research it. Everything techie gets pounded back and forth on forums and mailing lists. If you can't spare the time to go through forums, then get someone else to do it and make the final decision. If you don't have any programmers on your payroll to listen to, listen to those who aren't on your payroll and have no reason to lie to you, esp. since they don't know or care that you're listening.

posted on Tuesday, October 17, 2006 at 2:50 AM by Michael Chui

I agree with you. Another success story, despite their initial choice of platform, is Rand & Ryan Miller's "Myst" series of games. I believe the original prototyping was done with HyperCard! I'm also a fan of Paul Graham's writing, but I find he extrapolates on to the general what has worked for him in the specific. Rarely have I seen production ready platforms come out of or be used in research labs. I also disagree with the earlier comment that the language of implementation doesn't matter. Ruby and Python are fabulous languages, but building either a Windows desktop app or app plugin with them would be foolish.

posted on Tuesday, October 17, 2006 at 3:08 AM by skeptomai

I must disagree on one point. Python works extremely well for desktop apps. In fact, one of Microsoft's Office components was originally programmed in python. Not to mention that python is now a .NET language and has excellent cross-platform native gui support. There are plenty of desktop apps out there that are built with python...you just don't notice because they blend in well ;)

posted on Tuesday, October 17, 2006 at 4:16 AM by Brendan Kohler

Microsoft Office, I am told, has an installed base of 400-million users worldwide. Microsoft Outlook wouldn't be such a bad platform choice for the right application.

posted on Tuesday, October 17, 2006 at 6:21 AM by Matt Trifiro

I find a lot of differences between Paul Graham's and your "teachings" :) I think there is a fundamental underlying difference which may not always be explicitly stated.
When Graham's says "startups", he implicitly refers to the typically consumer facing startups where there is a mass target audience. In these type of startups, the dynamics are much different than a startup that is targeting enterprises. Paul's "startups" typically don't sell software (web based business) or sell them to individuals, etc.
I don't have enough experience to form an opinion whether or wrong choice of platform can kill a startup in general, but I think it may kill a consumer facing startup, if the website/application does not scale. Based on what's reported, it sounds like this may be at least one of the problems faced by Friendster as they watched Myspace become a monster although they were first to the market.

posted on Tuesday, October 17, 2006 at 7:22 AM by Berkay Mollamustafaoglu

Paul Graham is self absorbed poseur. He writes banal rubbish fundementally designed to promote himself and stroke his ego. It's sad that this Industry is so bereft of ideas and direction that idiots like him garner so much attention.

posted on Tuesday, October 17, 2006 at 8:07 AM by Aker Konrakis


I want to agree with you, as a pythonista, but I have to say that there just aren't a lot of python desktop apps out there. Boa Constructor sucks eggs, and bittorrent became popular mainly as a Java client app, despite the fact that its original implementation is in python.

There's a lot of things Python is good at, but experimental evidence seems to show that GUIs are not its strong suit.

posted on Tuesday, October 17, 2006 at 8:08 AM by Bill Mill

The bells of death do not ring immediately when startups choose the wrong platform, but eventually it does get tougher. And visiting comp sci research labs to find the right platform is definitely the wrong approach. One also has to realize that they need to get a wide array of developer support as they proceed, and using Scheme/Lisp (Paul's favorite) will only get you a small, obscure amount of available programmers. I know an office where they prefer Progress and Webspeed, and it suffers this same problem of having to waste time retraining new workers because it is not mainstream. No, the best bet is to grab the top 10 choices from Netcraft statistics, throw them all in your own round of lab tests, and find the one that seems easiest to find/fix bugs vs. scales well and which run on Linux. Right now those choices appear to be JSP/J2EE and PHP, right?

posted on Tuesday, October 17, 2006 at 8:14 AM by Supermike

Also, note that we can infer from Paul's essay that he is talking about Internet-facing, high traffic website applications, not internal business website, desktop, or tool applications. That's why I mentioned JSP/J2EE and PHP. However, my feeling is that you want to pick a language best for internal business apps, go with what has been the most mainstream for the last 5 years and which is ideally suited for the mode, such as using C# when you want to make an Outlook plugin or rich client GUI Win app, JSP/J2EE and/or PHP when you want to make an internal business website, Python when you want to make a rich client GUI Linux app or cross-platform app, and C# (Windows-only), Perl, Python, or PHP when you want to make a command-line tool.

posted on Tuesday, October 17, 2006 at 8:24 AM by Supermike

Yep yep you're right... plataform doesn't matter at the beggining (well... when you're start-up).

Just later in the cycle it will become critical. There's scalability concers, sure, but also the "brain factor". The truth is that good hackers don't use ColdFusion, so how can you hire good hackers if they don't know how to work in your app?

When you're small, you need 3-5 people dealing with the tech, so that's cool. But when you need 50 employes to handle development, DB administration, server uptime... then it's better to use, I am afraid to say "more popular" techs, or at least better supported.

I think that choosing the right plataform is very easy. That's because most of them are the "right" ones. Google goes with C/C++/Python/Java, Yahoo with C++/PHP, Myspace with ColdFusion, some with VB/ASP... the only thing is that they're not Cobol. They don't suck up to a point where you want to pull your hair off.

Web development is easier than desktop, so that's why the language/plataform choice is more forgiving.

posted on Tuesday, October 17, 2006 at 8:34 AM by Julio Nobrega

I am both a startup entreprenuer and application architect, so I have been dealing with this question from the beginning.

I have 2 goals. Unfortunately sometimes they contradict each other. Get to the market fast with a good basic product, and make sure it is scalable so that if it does catch on, it will be able to grow.

Choosing the platform is important for both business and technical reasons. The #1 technical reason is that you want to avoid a complete rewrite of your technology in the event that your startup succeeds.

Keeping that in mind, I have built a platform that "can" scale while at the same time cutting corners to get to market quickly.

At one point in development we realized that if the user base grew quickly, our code would not perform, so we did backtrack and fix it. It was an important part of the application that would have cost a lot of money to fix later on.

You must strike a balance. Visiting a comp sci research lab does not help you make a decision. Choose a platform that can scale, program it incorrectly if you have to, but know you are doing it. Only a good technology person can help make this decision.

We all think our startups are going to be big hits. How can you go into a venture knowing that if you succeed you will have to rewrite your technology?

posted on Tuesday, October 17, 2006 at 8:54 AM by Greg Harris

I would have to agree with you Dharmesh. Platform is over-hyped, and Comp Sci departments aren't always a good model for the real world - just look at Lambda the Ultimate (which is still very useful).

I think Pual's background skews his outlook just like anyone else. He's mostly right though. But I also think there are hackers out there who would work for a startup with a bad platform & 10,000 lines of code, and reduce it to 500, at which point the founders will gladly change.

If you're a smart hacker, getting ground level equity on a bright new idea, would you really let such a growing pain stop you from working on a fun project?

posted on Tuesday, October 17, 2006 at 9:51 AM by Ryan Elisei

In my experience, platform choices matter most over time. So, in the early days of a startup they don't matter much but over time the best platform choices are those that provide the most flexibility (scaling dimensions, performance, run-time environment (desktop, web, mobile)). Flexibility is critical because the one thing you can bet on early in a startup is that things will change - dramatically.

posted on Tuesday, October 17, 2006 at 11:20 AM by Roger Denton

You're making a critical mistake, here. You're assuming facts not in evidence. Specifically, you're treating the statement "visit a top computer science department and see what they use in research projects," as if it said "visit a top computer science department and see what they use in research projects then use that."

Checking what the research people are doing is just a trick to get you on the right track. It indicates what technologies are likely to be most useful for the realm of endeavor in which you're investing your time on a technical basis. Obviously, you should be checking research projects that actually bear some passing resemblance in some way to the sort of work you want to do, as much as possible.

It would also probably help if you keep in mind that Graham's not giving advice to people who want to create a home business that barely squeaks by and provides custom enterprise software to bloated corporate bureaucracies. He's offering advice to people with excellent technical acumen who want to embark on a project of monumental proportions (with regard to excitement potential, as measured by computer geeks) and succeed beyond their wildest dreams by doing something out of the ordinary that fills a need people didn't know they had. We're not talking about a slightly improved version of an accounting software widget, here.

posted on Tuesday, October 17, 2006 at 11:29 AM by apotheon

Well, I'm sitting here with one Windows 2000 machine that blue-screens with a registry error and a second Windows XP machine that I'm having to re-image and then re-install my apps on for the second time this year due to "registry rot", so this is definitely a topic of interest to me. Guess what? My startup won't be using Windows!

posted on Tuesday, October 17, 2006 at 12:48 PM by Anonymous


There's a danger in just following what's cool or accepted. B2b was going to take over the world in '98 and you couldn't pick up a business magazine that would tell you otherwise. But the reality (and I speak with considerable experience) was otherwise.

You may not be aware of it but there are some very talented programmers using Coldfusion.

It comes down to what allows you to get a prototype live quickly and yet still scales. Coldfusion by those standards is a contender.

Do you think those using myspace even are aware (or even care) that it's using Coldfusion? There a lot more important issues with apologies to Mr. Graham.

posted on Tuesday, October 17, 2006 at 12:53 PM by Rick Mason


No question about it, Coldfusion is a contender. But again, it must be scalable. I have a client that has a $40 million a year business and is still running on Coldfusion 4.5. The problem is that they built it completely unscalable.

Separate the front end from middle layer and database and you can't go wrong in any language. The problem lies when you build a prototype or initial version with the SQL calls mixed in the presentation layer. You then have so much time invested in it that changing it is so painful.

Just be smart upfront. Make it scalable, and abstract any proprietary controls, DB, etc.. and you're safe.

Doesn't take too much extra effort these days with great tools out there.

posted on Tuesday, October 17, 2006 at 1:01 PM by Greg HArris

Good point Rick.

How do we know MySpace doesn't have hackers writing software generation code that spits out Cold Fusion? Just because the result is Cold Fusion, doesn't mean there aren't talented people working on it. In fact, if I were so inclined, I might pick a language like Cold Fusion to throw off the competition as to my real strengths.

How much did MySpace make vs. Paul Graham? That's not to slam Paul's genius. I love his stuff with points like this in the minority. Dharmesh's point is well put.

posted on Tuesday, October 17, 2006 at 1:02 PM by Ryan Elisei

While I hate to jump in on what is obviously a minor sub-point to this discussion, the critiques of Python for desktop development are way off base. Python has a variety of bindings to various GUI toolkits, and regardless of what programming language you choose you will always be coding to a GUI toolkit of some sort or another. No one writes an app by saying "put this pixel here", they use libraries that provide buttons, canvases, and event callbacks to process user activity. Python has a variety of available interfaces to just about ever popular UI toolkit, ranging from cross-platform toolkits like wxWindows to native os-specific libraries. You can develop your UI in Microsoft's Visual Studio or Apple's Interface Builder and then call in to the library these development platforms provide to attach your program logic. (The short version of these is that there is _nothing_ you can do in Visual C++ that I can't interface with from Python....)

If you are a startup then you often do not have a very good idea of what your customers want, and if you think you know exactly what they want you are often going to be surprised to find out that your assumptions were incorrect. Using a high-level programming language like Python or Ruby makes it a lot easier to adapt and change directions as you learn more about your customer needs.

posted on Tuesday, October 17, 2006 at 1:16 PM by Jim McCoy

It seems like we're comparing apples & ornages here, in terms of platform. If you're writing a source control system that requires SQL Server (ala Eric Sink), then you've tied the size of your market to SQL Server installations. However, if like Ebay or MySpace, you simply choose the wrong platform, you haven't placed the same limitation on yourself. For Ebay and MySpace, the platform is the browser, not ColdFusion or IIS.

Now you could probably make the point that Ebay anbd Myspace could have made wrong choices as far as scalability, security, or attracting hackers to work for them, but that doesn't seem to be the argument here.

posted on Tuesday, October 17, 2006 at 1:38 PM by Kamau Malone

Thanks to everyone for their comments. I hadn't quite expected to genereate this level of discussion, but I'm glad I did.

I want to resist the tempatation to try and respond to some of the comments here (though the points are generally well taken and legitimate).

Will try to sift through the comments here, on Reddit and on Digg and see if I can synthesize them in to a future post.

posted on Tuesday, October 17, 2006 at 1:46 PM by

Everyone after Aker Konrakis, seems to avoid his words. Is there not some truth to it? Don't get me wrong. I really like what paul writes in his essays and I tend to agree with him mostly. Much as you do - it seems. But I'm just an average dumb ass developer who doesn't know too much about what is going on 'above'. And I wonder if Aker knows what he's talking about.

Leaves me a bit confused..

posted on Tuesday, October 17, 2006 at 1:56 PM by Daniel Lukic

Daniel: I disagree with Aker's viewpoint as he has provided little support for his argument.

Also, self-promotion and intelligence are not mutually exclusive.

I think most people would agree that Paul is very intelligent. You may not agree with everything he has to say, nor buy into his particular brand of entrepreneurship -- but there's no questioning that he's smart.

My two cents...

posted on Tuesday, October 17, 2006 at 2:02 PM by

It is an NDA, but MySpace gave up ColdFusion long time ago and is currently running on JSP/J2EE on Windows Server 2003 and IIS 5.0 clusters and I guess Oracle database. MySpace just uses URL rewriting to preserves the URLs to be consistent.

posted on Tuesday, October 17, 2006 at 2:02 PM by e

A few direct and tangential comments.

Direct comments:
- Hire the smartest tech you can find.
- Let him know what you know and what you don't know.
- Make sure he "gets" start ups and understands it is him that'll be paged at 2am if Ruby isn't playing nice with the web server.
- Also let him know that he's going to have a fixed budget and timeframe for development, so if he wants to have the robustness of static typing and compilers in Java and c# he's going to be working late every evening adding all the additional patterns required to create explicitly typed applications.
- Let him know he's responsible for hiring, so he can choose to fight for one of the handful of Ruby developers - most of whom are extremely smart - or can wade through the large number of Java developers who are more variable only because the technology has been out longer so it's not just the early adoptors any more.

He'll take you from there!!!

Indirect Points:
- Believe it or not, there ARE ColdFusion hackers - not many, but they exist. Depth of OO talent is a real issue, but I'm developing a dynamically typed OO software product line for generating web apps using CF (most of the algorithms are language independent so I'll probably do a Ruby port next year). There are limitations. The cost of object instantiation means that creating abstract data types for all object properties is unrealistic so I need to hack that with composed validation and transformation singletons in a pretty traditional Java style. You don't have interfaces and nulls, but I prefer Ruby/Python to Java and can live without them for this app. Lots of things are remarkably good about the language. The simplicity of querying db's, working with the file system, creating PDfs and developing Flex back ends is pretty good and I know a number of Java/CF developers who know Java but use CF for chunks of their apps and others who use CF even though they are proficient in Ruby.

Go figure!

posted on Tuesday, October 17, 2006 at 2:31 PM by Peter bell


CF version 4.5 is your grandfather's Coldfusion. It stacks up well against other language versions from 1998 but that's not the point.

CF MX 7 is built to compile to java bytecode and is orders of magnitude faster than 4.5. There are a half dozen MVC frameworks from which to choose now. Though I think you will agree with any language scalability depends largely on the programmer.

posted on Tuesday, October 17, 2006 at 2:42 PM by Rick Mason

Aker Konrakis: "Paul Graham is self absorbed poseur. He writes banal rubbish fundementally designed to promote himself and stroke his ego."

Well, let's see. Graham has a PhD in Computer Science from Harvard and has studied art at RISD and the Accademia di Belle Arti. He is the inventor of Bayesian SPAM filtering. He doesn't have to work because he made his fortune with Viaweb and can now afford to write essays telling us how he, you know, actually did it.

I'm just guessing here, so feel free to correct the record, but I'm thinking that none of these things apply to you, Aker, so you might want to be able to point to your own record of achievement before you call others poseurs.

posted on Tuesday, October 17, 2006 at 2:46 PM by fibian

Regarding MySpace:

I think that you have it wrong, I have actually met some of the myspace developers.

They began moving a year ago from Coldfusion 5 to a product called BlueDragon from a company called NewAtlanta.

Just like Coldfusion MX takes your cfml and compiles it to java bytecode, BlueDragon compiles the CFML to J# and lets it run on the dotNet platform. So you can still code in coldfusion and without changing a thing run on dotNet.


posted on Tuesday, October 17, 2006 at 2:49 PM by Rick Mason

Well if you make your desktop application with the Qt Python Bindings (PyQt) not only will it look and feel like a native application, but it will integrate better with vista then most third party applications. You can indeed write a desktop application in Python.

posted on Tuesday, October 17, 2006 at 4:52 PM by Benjamin Meyer

Not sure what GUI toolkits and version of Python the author's been using - I've never had any issues getting Python and wxPython to look native. As far as I'm aware, wxWidgets has no native issues on any of its supported platform. Heck, use py2exe and it's just like using a normal Win32 app.

Or I can use Python bindings to the win32gui library.

And BT's popular Java client was less to do with the language and more to do with the actual functionality of th client - the original BT client ddn't act like the P2P software people were used to; the new stuff did.

posted on Tuesday, October 17, 2006 at 8:24 PM by Liam Clarke

To the CF whiz's out here: There's no sense in trying to wake up those who don't know they are asleep. Every platform has it's strengths and weaknesses. People will always beat their most comfortable drum the loudest. A drum that costs money will get played less, because the other drums are free. I don't care to explain to anyone that CF handles J2EE/.NET natively, and compiles to Java Bytecode. It takes up 1/3rd of the code of any competitor, as we know, less code = less bugs.

But, I don't care. I don't live to sit in front of a computer programming with that much of my time when I can get it done, just as well with the most efficient tool that I can find for it. If you don't know your platforms, you might not be a candidate for building the next Google.

Any great platform and language can be reduced to rubble with a poor architect + implementation, and vice versa.

What we're left with is tools. The better you know what more tools are capable of, the more likely you are to integrate any number of technologies to do what you need.

I don't think I'd blindly trust many of my CS profs in their choices because they should be out in the world changing it, and concievably hitting the big time.

Ruby is swell. Where it isn't, Coldfusion wins. Where Coldfusion may not work, I have PHP. Where the internet is headed, RIA, is where the stepping-stone technologies will give way to the best integrated ones. For that reason alone, I don't think anyone comes near Adobe Flash/Flex/Coldfusion for any rich experience on the web that isn't back-breaking to develop.

Great blog, great discussion, instead of tearing down technologies, why don't we all share what other platforms are capable of?

- Long time reader, first time poster

posted on Thursday, October 19, 2006 at 10:19 PM by Jas

I think you're right.

Goals of a computer scientists are different from a production environment.

Scientists build in order to learn. Engineers learn in order to build.

Also, people often think they need to invent (something new) when they just need to incrementally innovate (something a little better).

posted on Saturday, October 21, 2006 at 11:18 PM by Aphasia Software

One post above stated that they could build their site in ColdFusion to throw others off on their true ability. Funny one... That true ability is then in question because the only thing people would see is the HTML rendered in the browser. Furthermore, if they had true ability, they could simply add a rule to their Apache web server to resolve urls with *.cfm to any processing engine or app server they wished.

Frameworks ARE important and especially for a startup. The advantage is more along the lines of hiring the right people with the right skills and not ability to handle increased load. You need a senior developer/architect and then choose a platform, framework, language and coding standards to define your architecture. You then leverage this to create your E2E prototype which you factor out into smart code shells that implement your standards including logging, exception handling and whatever MVC or other pattern you choose. Thereafter, you can rely on junior developers to do the busy work and code components identified to realize your design.

Scalability relies more on architecture and less on frameworks. Frameworks usually implement a design pattern. Design patterns often solve common problems w/o reinventing the wheel. These speed up development through re-use inevitably simplifying maintenance. This is more advantageous for scaling the amount of work effort but not the ability to handle increased load - that is a formula of bandwidth, processor, caching strategy, etc which fall under architecture (app and physical).

posted on Saturday, October 28, 2006 at 11:07 AM by Joe Blogg

Use Lisp. Use J#, C#, J2EE, Python, Win32 GUIs and frameworks. Hmm. Seems to be a disconnect between PG's statements and the comments here.

posted on Sunday, March 04, 2007 at 9:27 PM by Connelly Barnes

Comments have been closed for this article.