Posts tagged with “development”…

Which language should my startup use?

Posted by Aidan, 20th January 2010. Share this:

• .net
• c#
• development
• django
• java
• language
• php
• software

We're often asked by entrepreneurs which language their startups should adopt when developing their technology. Attending events around London, or talking with some of the development agencies present at the events, one might hear a startling set of opinions. PHP is insecure? Ruby on Rails doesn't scale? It can be difficult -- without experience building software -- to make an informed choice which is most suitable. Technology enthusiasts tend to get tangled up in enthusiasm for their chosen platforms, so we'd like to provide an objective summary.

But wait

Not all startups are alike. Some are more technical, or more mature than others. Whilst this guidance should be of interest to technical startups, if they have capable senior staff they should be able to get this from them. Businesses with more complex needs or pressures may use multi-platform solutions. In particular, they may use service oriented architecture, or SoA. This can be used to spread some of the platform risk a business might face.

What to avoid

Fortunately for entrepreneurs, there are only a few technology language choices that are likely to be fundamentally "wrong". ASP (or Visual Basic) does not have a justifiable use, other than by companies needing to service existing ASP technology. Microsoft replaced ASP with the .NET platform more than five years ago, and even at the height of its popularity ASP was wholly inadequate. ColdFusion, one of the few languages to have an "is this language dead?" page, can -- despite the occasional new release from Adobe -- be considered a dead language, with all that this entails (difficulty finding and retaining good developers, vendor lock-in, horrendous cost, poor support, porting nightmares, infrastructure constraints). ColdFusion occupied a niche for rapid web development since the late '90s, and its legacy consists of around ten very vocal agencies and developers, some of whom are moving slowly to .NET.

Languages like Tcl -- which powered Vignette's CMS products in the dotcom heyday -- are now rather unusual in web development. They're not entirely without use or benefit, but like Lisp, Flash or Silverlight, they're often not the best choice. There's nothing inherently wrong with Flash or Silverlight, but most often their use should be considered only for incremental interface enhancements to a system built on an establish web framework.

It's worth noting that technically capable startups may use esoteric languages with a great deal of success. 37signals repopularised Ruby this way, and last.fm have been beavering away with Haskell. These languages work well for the companies because they are solidly technical, and are able to kickstart their own frameworks or adapt other projects. Many startups do not have this luxury, and although they've been very successful, 37signal's David Heinemeier Hansson was quite indulgent and not at all risk averse in choosing to single-handedly reinvent a language.

Language doesn't matter

Complex web applications can be built in just about any programming language, and it's not really the language that is so important as the frameworks that are available. Despite what some vendors may say, all languages scale, and it's hard to argue that one language is fundamentally less secure than another. One can, however, make these arguments about different frameworks. Development frameworks are toolkits to guide developers in building particular pieces of software. Critically, they provide implicit (and sometimes explicit) structure to what the developers are developing, and will allow the team to use pre-built blocks of functionality. No company, in any industry, should be building functionality without recourse to significant chunks of other peoples' frameworks. (The common argument used to be "this isn't rocket science, it's likely someone's already built at least part of what we're doing before". However, nowadays even the rocket scientists at NASA are using external frameworks.)

But frameworks really do matter

Above all, in order to make an informed choice of platform, consideration must be made as to the framework. Why would one chose to develop with a particular framework over any other? Consider these eight areas:

1. Cost of development (rates, productivity, time cost to recruit & availability)
2. Platform cost (& total cost of ownership, or TCO, including hosting, support, licensing, cost of requirements)
3. Quality of developers (& barrier to entry)
4. Maturity (& continued maintenance)
5. Similar business use
6. Suitability for web (& your domain)
7. Support & documentation (don't forget release cycles and open vs. proprietary, RTFM = STFW?)
8. Ease of integration & adaptability (SoA, other components & processes)

There are five or so fairly common languages that startup companies might use to address their needs. These are Java (from Sun), .NET (from Microsoft), and three Open Source options: PHP, Python and Ruby. We’ve tried to convey a flavour for each language as concisely as possible.

Java stands alone from the four others. It -- along with Perl, ASP and a host of proprietary platforms -- powered many of the enterprise sites of the late nineties and around the turn of the century. It's a powerful object oriented language, and is effectively Open Source. Java can be used in both Microsoft or Open Source environments. As it presents a relatively high barrier to entry in terms of technical complexity, Java developers tend to be more capable (and expensive) than many developers who use simpler scripting languages. However, Java is not a particularly productive language to work with, and many elements of functionality can be delivered more rapidly in the other languages. Java developers pioneered some of the best early web frameworks and tools: J2EE, Spring, Eclipse, Hibernate, Ant, Struts, Tomcat. Java has a fair amount of syntax in common in common with some of the .NET languages which were designed by Microsoft to counter Java's success. Java is a great language for enterprises and is commonly used by many big dotcoms, banks and airlines, but its relatively slow development pace and higher barrier to entry make it inappropriate for most early-stage businesses.

PHP is a widely-used Open Source web scripting language. Many small to medium size sites use it, alongside a few massive ones such as Facebook. Of the languages considered here, PHP has the lowest barrier to entry, which has some big drawbacks. First of all, PHP powers a number of content management systems (CMS) – such as Joomla! and Drupal – which are often confused for frameworks. It’s possible to get very simple sites up and running very quickly with CMSes, but often businesses can get caught up trying to extend them. Having a site built on a CMS platform may make sense for the first iteration, but beware of falling into trying to upgrade the modified CMS to support a complex site. It won’t, or at least, it won’t work well and be a robust, fast and high-quality solution. (This isn’t to say PHP doesn’t have frameworks – it has many, from Symfony, CakePHP and Zend to a host of others.) Secondly, the ease of use of the language means that many of the programmers and agencies available are, at best, hopeless. PHP programmers are often unfairly stigmatised by colleagues who work with more complex languages, and whilst there are some excellent ones out there, many more are poor. Grand Master Programmer theory states that around 1 in 20 (or 5%) of programmers are super programmers, and in “easy” languages this number is even lower. Hiring a good team of PHP developers is neither likely nor easy for the non-technical. A team of poor developers won’t just take longer to deliver a solution: they’ll build something which is insecure and complex, and subsequent modifications will become increasingly costly with time.

The .NET framework is a set of proprietary languages (most prominently C#, VisualBasic.NET and ASP.NET) developed by Microsoft. Microsoft made a half-hearted attempt to “open” the languages by publishing an ECMA standards document, and there is an Open Source implementation (Mono) available, but for the most part development with .NET requires use of Microsoft operating systems and licenses. This isn’t a discussion of the merits of Closed vs. Open Source, but it’s worth noting that each Microsoft server costs around $1,000 to license, and their database software costs between £2,000 - £16,000 per CPU (most servers have two to four) to license. These are usually insignificant amounts once a business is proven but can seriously eat into seed or first round capital. (Microsoft have a Bizspark programme to provide these products freely for the first three years of a startup’s life.) The .NET languages, and particularly VisualBasic and ASP.NET have a barrier to entry only slightly higher than that of PHP. That, and the fact that they represent “point and click computing” have resulted in an industry segment full of sub-par programmers. Like PHP, when hiring Microsoft programmers there’s much to be wary of. .NET powers sites of all sizes (though relatively few massive ones) and is very common. .NET has some CMS frameworks such as dotnetnuke and Community Server which often distract startups. Most startups don't have "legacy applications" to deal with, but .NET can be particularly easy to integrate with older Windows applications and services, and is an easier migration choice for older "Microsoft" code. Reincubate have been called in to rescue twice as many project disasters on .NET than any other platform.

Ruby on Rails is a combination of framework and language, with Ruby being the language and Rails being the framework. Ruby was considered a dead language to all but some system administrators when it was revived in 2003 by 37signals to develop their award-winning productivity startup Basecamp, and then taken on to power Twitter. Their lead developer built the first parts of the Rails framework before throwing it open to the Open Source community for further work, and in doing so the first true Web 2.0 framework was built. With a mid-level barrier to entry and a fan-base of intelligent, capable, multi-skilled developers, Rails represents an excellent choice for a startup. The project is mature enough and well documented enough to have attracted developers seeking refuge from other, more tiresome languages. Some purists consider it a joy to program in, and anecdotally it appears to be the platform of choice for many of the hot American companies on TechCrunch. Rails is a web framework at heart, and is less suitable for non-web projects. Being so fashionable, there are many developers both on and off-shore (increasing rapidly) but finding available resource can sometimes be tricky.

Finally, Python’s Django framework has catapulted it into a serious contender to web development. Python is an Open Source language (with a philosophy behind it) long-beloved by Object Orientation enthusiasts, system administrators and Google, and has had a number of different web frameworks – like Zope – before. However, it’s only really with the appearance of Django over the last few years that it’s been more widely used by start-ups. Describing itself as a framework "for perfectionists with deadlines", Django is comparable only to Rails in its tight focus on delivering functionality very quickly for Web 2.0 web applications. Whilst technically there are some interesting differentiators between Django and Rails, there are only a few key differences worth considering. Django is much newer and has a more immature codebase. This means there’s far less supporting documentation, far fewer experienced developers, and is more likely to change as it gets away from version one. Such is its impressiveness, however, that Google released Django as the first supported language on their App Engine cloud computing platform, and a number of Rails developers are starting to transition over. Central to Django are the principles or DRY (“Don’t repeat yourself”) and Python’s lack of TIMTOWTDI (“there more than one way to do it”), with a medium barrier to entry, these help less experienced developers get it right -- the first time around -- in a way which PHP frameworks cannot.

At a glance

Being one of the few expert companies assisting early start companies with their technology strategy and platform, we’re particularly well exposed to platform disasters through the rescue projects we’ve embarked on. In fairness, early-stage business failure caused solely by language or platform choice is rare, but it's often a significant contributory factor.

From what we see, one of the biggest technology risks is where companies take on agencies or developers who have built their own, idiosyncratic frameworks, and we see these tripping up companies time and time again. Seed money gets invested on something that shouldn’t be in use, rather than something provided by an off-the-shelf framework which won’t tie the business to a particular agency. We’ve written previously on the other technical challenges start-ups will face when working with agencies or developers.

• The good: Python (Django), Ruby on Rails
• The bad (or less good): Java (also J2EE, JSP), .NET (includes C#, VB.NET, ASP.NET), PHP
• The ugly: ASP (also Visual Basic), ColdFusion, Flash, Silverlight Lisp, Tcl, Perl, any framework built and provided by a development agency, even if they say it’s “open source”

We value our independence and do not endorse any agencies or developers. However, we will publish a short round up of resources and guideline rates in a follow-up to this article.

A guiding principle

It is impossible to give general advice on which languages are better than others, and this post makes a number of generalisations. An expert in a particular language or framework will usually be more productive than a non-expert in another language. Whatever the choice, it's important that the experts aren't using the platform in an idiosyncratic manner.

It never hurts to focus on simplicity. A business should own as little technology as is suitable to fulfil its strategy. This should translate to every variable one can use to measure technology: number of servers, number of licenses, lines of code owned, technical staff. The less a business owns, the easier it is to change and grow. Other considerations aside, the framework that's most suitable for expressing the business' logic as simply as possible is often the right choice.

This post has 2 comments »

Kublax insecure: what is going on?

Posted by Aidan, 1st May 2009. Share this:

• audit
• cto
• development
• security
• seedcamp
• turnaround

On paper Kublax sounds like a great start-up. They've set out to solve a real challenge faced by users of online banking. They're doing it with relatively little competition, are well funded, got through Seedcamp in 2007, have some really smart investors. What they're doing is a little tricky, although it's been done very well in the States by Mint, who are excellent.

I've been intrigued by Kublax's journey, having been following the space very closely. It was announced in passing during one of the TechCrunch Geek'n'Rolla presentations the other week that they were relaunching, seemingly without fanfare. Kublax had presented at the TechCrunch SeedCamp review event in September 2008, one year after getting funding, but were unable to show a working product.

Keeping it simple is as good a principle in business as it is in technology, much as it might make for glib analysis. Kublax' main priority was to address the pain they had identified: allowing users to bring their online banking accounts together for ease of use, better budgeting and to save money. Their main threat was that their implementation -- which by necessity requires the users to give up the online banking details they're not supposed to -- would need to be perceived as incredibly secure. Ease of use and security: that's it, a little mission statement for the developers.

Maybe the early roadmap looked a bit like this:

1. Build a prototype to explore the proposition
2. Raise some funding to pay third-party account aggregator
3. Building something easy to use and secure
4. Build a clever automatic tagging engine but also hire a bunch people to type in categorisations all day so that statement data gets correctly analysed
5. Start addressing shortcomings in service from third-party account aggregator
6. If it's working well, enhance the revenue generation mechanism and spend some money making the platform more robust, scalable, etc.
7. Profit

Something has gone wrong, however. Kublax is neither easy to use nor secure. That's a sweeping statement, so let's look into it.

Kublax is not easy to use

First off, it doesn't work properly in Firefox. At a quick glance, popups break and the budgetting table misforms. There's no tagging of transactions possible, no evidence that the interface learns, no statistical analysis from other users' general data, and poor initial categorisation of spend. I've put several accounts in it and less than 15% of spend gets categorised correctly, or at all. The interface is slow, counter-intuitive and fails to take advantage of a fair few Web 2.0 tricks that could really help.

The shortcomings from the third-party account aggregator haven't been addressed. The system can't recognise transfers between bank accounts, struggles with common direct debits, and can't figure out cash withdrawls in shops.

Take five minutes to log in to Mint. It's beautiful, and is based on the same technology. Yes, they raised around $16M more funding but it's a similar age and I bet it's not the technology that most of that cash has gone on.

There's huge potential in online account aggregation, but there's less functionality here than in Microsoft Money or Quicken.

Kublax is not secure

So what about security? Is Kublax secure? Well no, I don't think it is. There's at least one glaring security hole, and a huge amount of bad security practice to the extent that it is a good tool for hackers and phishers.

It goes without saying that making a secure product is fruitless if it isn't presented in a way that's trustworthy and secure. Getting that copy, branding and user-flow is essential to create the feeling of trustworthiness. Aside from SSL padlock icons in their browsers, most users have no idea whether what they're doing is secure or not, and the perception of security is emotional, and separate from any real security. The security FAQ is written in rather poor English with a liberal sprinkling of commas: "Kublax alerts can increase your financial security, by providing you with timely appropriate alerts". The FAQ includes this:

"What if my bank calls me to tell me that a robot is accessing my account and to terminate any account aggregation service? Have a look at your account and you'll see everything is normal. We do "read only" service and no transaction of transferring money can ever take place. Your bank has contacted you based on their misunderstanding of the way in which the service works. Put simply, there is no disclosure of your security details to us or to anyone else through your use of our service. [...] It is unfortunate but inevitable that in this modern age some of the older organisations find new services threatening because they do not understand the nature of the service or because the service may not show them in a favourable light in relation to their services or as against their competitors."

This reads like a phishing phone-call from Fonejacker's George Agdgdgwngo: "Good morning Sir, there is a pigeon in your bank account, I just need your bank account details". For a start, it's wrong. Security details do pass through Kublax and Yodlee, even if they're not stored. To suggest that the service is secure because it's not possible to transfer money suggests access to the read-only data is perhaps not so secure.

And anyway, it's not secure, with a cursory inspection showing up some really serious security flaws. Kublax has basic security errors including CWE-312 ("Cleartext storage of sensitive information"), CWE-311 ("Failure to encrypt sensitive data") and CWE-319 ("Cleartext transmission of sensitive information"). America's National Security Agency puts CWE-311 in the "top ten" most dangerous errors in the "insecure storage" and "insecure communications", and rates CWE-319 in the "top 25 most dangerous programming errors".

You can quite simply demonstrate all three of these errors by using the password reminder functionality. This sends your password -- completely unencrypted -- by email back to you, meaning that the sensitive data that Kublax do store is unencrypted and accessible by at least some of their employees. The message I received was:

"Dear ,

Your password for Kublax.com is PLAINTTEXTPASSWORD

Kublax Team. "

Oops! Awkwardly, when you use the password reminder functionality, Kublax doesn't confirm they've sent a reminder email. Rather, the site throws an error saying "You have been INACTIVE for a long time.Therefore for Security reasons we have logged you out".

That's not the full extent of the problems. Unlike secure sites, Kublax reveals the difference between an invalid email address and an invalid password as users try to log in. If you try to log in on Amazon, eBay, MySpace, Facebook, etc. and you get either your username or password incorrect, you'll get an error message telling you that one or both were wrong, but not identifying which. Would-be phishers with lists of email addresses to target for online-banking fraud can easily run their lists against the Kublax system to see which users are registered for online banking.

Having forgotten my own password for the system I tried about ten passwords before I got it right, and unlike secure online banking systems, Kublax won't lock you out after you try a number of incorrect passwords. This opens the door for brute-force hacking. Would-be hackers could easily look up the partners at Kublax's investors, for instance, and brute-force their email addresses. Even more dangerous is the face that the Kublax system has weakness CWE-521 ("Weak Password Requirements"), allowing users to choose passwords such as "letmein" or "password". There are good reasons for online banking services to restrict these choices.

Long-dormant accounts, such as mine which was last used six months ago, should probably be flagged as being dormant and require some form of additional security to reactivate, to prevent forgotten accounts being targets for hackers. There's no sign of this happening on the system.

With all of these obvious problems one rather wonders what the behind-the-scenes security of the infrastructure and back-end is like. It can't have undergone an external security audit.

What does all this mean?

From the outside, it's hard to see where it went so wrong. Other than having said hello to the Kublax team at the event in 2008, and having programmed using the underlying account aggregation software they use, I know little of the background. Some things are clear, though:

The technology implementation has been a disaster. The Yodlee account aggregator service that they use is not that difficult. In two weeks it's possible for a single coder to knock up something crude but essentially as functional as the Kublax site, and I know this because I've done so myself.

I suspect the problems have stemmed from a typical startup challenge: outsourcing technology is difficult for start-ups, and it's hard to get it right. I believe Kublax's technology is outsourced to India. Outsourced or not, there are a dozen Ruby on Rails agencies who could deliver a prettier, more intuitive interface than Kublax's for no more than £50,000, and in a matter of a few months.

And what next for Kublax?

A few tips from us:

• Take down the site until it's secure, and get an external security auditor in.
• Get in a new creative agency and brainstorm some designs with them. Look at Mint and some of their competitors for inspiration. Come up with a less clumsy way of integrating financial product referral: it drives revenues.
• Find a way to manage the capital outflow to the account aggregator. There's likely a massive burn rate for the business in this.
• If necessary, start raising another round of funding to buy some time.
• Get in a new CTO, and start prototyping an application with the new designs. Take that to the investors. The CTO should be cognisant that a highly productive web language will probably be more cost-effective than Java, but in a few months he should be able to catch up with the last platform.
• Don't forget SEO this time: it looks like an afterthought in the current platform.

A final comment

Reincubate are in the industry to build and contribute to growth start-ups. It's incredible that a Seedcamp winner should struggle so much with their technology, and we're always happy to provide constructive criticism and suggestions to move forward, as above.

There are valuable lessons to be learnt by other entrepreneurs looking to innovate in this field. Don't lose track of the consumer pains you're addressing, and if there's a threat around security, for instance, do everything you can to mitigate it.

As ever, we appreciate the feedback we receive.

EDIT: Interestingly, Kublax was tipped off about some of these security problems by Doug Winter back in February. He found a more serious security problem which has since been fixed, but concludes his review: "Kublax: security fail, usability fail and coding fail. If I were a VC who had funded this I would be quite upset".

JUNE UPDATE: No more than a month after this post we were pleased to see Kublax's new CEO announce an overhauled site which addressed some of these issues.

This post has 2 comments »

A little planning goes a long way

Posted by Andrew, 2nd March 2009. Share this:

• development
• lpc
• mvc
• planning

A couple of weeks ago I was involved in a database upgrade. Reincubate's client was wanting to migrate two operational systems of similar size and complexity from a legacy dBase-compatible database backend to SQL Server, and I felt the differing experience with the two systems serves as a good illustration of the importance of proper planning and code discipline, right from the initial stages of a software development.

The first system had grown organically over many years. There were numerous examples of hard-coded connection strings, proprietary SQL commands and the use of direct table access instead of the use of SQL views for accessing data. Consequently, the migration process for this product required several weeks of code analysis - essentially having to code through the codebase line by line to ensure that, when the data was migrated to SQL Server, the software would continue to run.

In contrast the second operational system, a .NET application also using a dBase-compatible backend, was much simpler to migrate. This application had been developed using our own .NET brokering framework, which provides tiered abstraction layers to separate presentational code, business logic and database integration. At the initial planning stage for this product several years ago it had been recognised that there would be a need to migrate the database backend in the future, so database portability was planned into the project right from the initial stages. Consequently, the entire migration process for this product was completed in less than a day, as the only changes required (other than the actual data migration) were to remove vendor-specific DML from the configuration file, change the database connection string and port a number of stored procedures to T-SQL.

This is a striking example of how proper planning right from the early stages of a project can provide a pay-off many years in the future. In this case, several weeks of resource-intensive development, potentially costing thousands of pounds, was avoided by identifying the potential need for migration right at the initial stages of the project and using the right tools to ensure that MVC principles were followed throughout development.

If you're in the initial stages of planning a software development and want to ensure you're taking the right decisions then why not speak to us?

This post has 0 comments »