Coghead Shuttered: Another in a Long Line of Non-Developer Developer Tools
Posted by Bob Warfield on February 20, 2009
Coghead has shut down. Techcrunch has a copy of the letter sent to customers announcing the shutdown. Customers will be able to run their apps without support until April.
Meanwhile, SAP of all places has acquired the technology. I can’t imagine anything further removed from SAP than a tool for non-developers to use to create low end database and form apps. After all, SAP is known for unbelievably flexible but costly to implement and extremely complex high end enterprise apps. But, I assume a Grand Plan will be revealed in the fullness of time. Maybe they just wanted to hire the developers as a team. Intuit Quickbase have extended an offer to try to bring Coghead’s customers over. It’s a generous offer, but transitions like this are not easy. Coghead was a proprietary tool as most of these are and so the apps will have to be rewritten. Still, presumably there are folks dependent on those apps who will have to do something.
The market for tools for non-developers to build software with is littered with interesting remnants. They range from things like BASIC (still successful, but not clear VB is as simple as the original BASIC people were using to write Lunar Lander games with) to dBase/MS Access to the brief Renaissance of 4GL tools from companies like Powersoft that marked the early part of the Client Server era. Many of these tools have vanished without a trace, or at least gone off to niches where they’re much loved but seldom heard about. Lots of fancy names have been bandied about for this breed. Coghead calls itself a “declarative application” for example.
In general, these tools are really difficult to get right. Developers are expensive, and there is often a need for a little app that doesn’t warrant the expense of hiring the developers. It seems so tantalizing to many that an app can be created that suddenly makes it possible for non-developers who understand their business problem to crank out the apps like crazy. Alas, mostly it doesn’t happen so easily. The products demo well, but programming in the end is, well, programming. It ain’t easy if you’re not really a programmer at heart. Probably the best example of a successful product for non-programmers is the spreadsheet. But look at why it succeeds:
– They completely broke the mold. There was nothing remotely like spreadsheets before Visicalc arrived on the scene.
– They limited themselves to a particular domain–accounting and financial statements. And that domain gave them a ton of elbow room because there were a lot of “apps” (spreadsheets) that needed creating there, and they were all highly custom.
– The availability of this new invention intersected and rode on the back of a major paradigm shift that was underway: the PC. Spreadsheets, together with Word Processing, were the “killer apps” that made PC’s important to business.
This other genre of products doesn’t benefit from any of those qualities. They mostly don’t break the mold enough to really make programming easier. Instead they borrow ideas from lots of places and wind up complex grab bags of ideas. Their domain, simple apps that need forms and databases, often just don’t have enough compelling apps to sell. And lastly, that paradigm shift hasn’t been there to help much. In a world where you had a choice of BASIC or dBase to build a custom accounting system, life was easy. Today you could use so many different choices, and all the existing accounting systems are so much more customizable, that it’s hard to argue for this class. Coghead was at least SaaS, some called it a Platform as a Service, but I just don’t think the paradigm shift was favorable enough given other available choices. I also agree with Sinclair Schuller that the highly proprietary nature of a lot of these tools makes adoption a lot harder.
An adjacent space that I think is much more viable would be the easy-to-use “P” languages: Pearl, Python, and PHP. Ruby on Rails counts too, even though it doesn’t start with “P” and may be a little more cerebral than the other 3. I’ve seen non-programmers do some pretty amazing things with these tools. They have huge communities, and the languages are amenable to the sort of copying-and-pasting-of-examples-barely-understood. At least they’re not proprietary and its easy to get lots of help, whether in the form of books available everywhere, online help, lots of finished examples, or even meeting someone pretty easily who is an “expert.” Another I would throw into this category is Adobe’s Flex, which lets you do some very cool things indeed, though it is a touch more proprietary.
Other players still standing in this space: Caspio, Bungee, Longjump, and probably others I have missed. Best of luck to you guys!
Yves said
Hello Bob,
I would add to your points the following:
1. Users expect you to come with an answer to their business needs and not with a big toolbox;
2. One of the biggest challenges when creating applications is not about building it but listening to the customers and translates their functional needs into automated processes and web screens;
3. Web applications builders are putting high limitation to the developers’ freedom.
I covered it on our blog a few months ago:
My feelings is that when it comes to ask the users to play a role in the creation of a software, you cannot expect more than simple drags and drops.
Also, the proprietary approach is a huge lock-in for every developer. I would definitively push for more freedom, using the .
Yves said
Sorry for the last post, I just screwed the html tags. Here are the two links I wanted to share:
Can everyone be a software developer?
the browser as a platform
janemccarty said
The things got really complicated for Coghead customers. But the data should be saved anyway and moved in a better place. So, this is the comparison of migration opportunities:
http://webappsatwork.blogspot.com/2009/02/helping-coghead-customers.html
evoluteur said
There is an open source project with some similar features (but limited to CRUD… for now) that works. Total freedom to the developers!
http://www.evolutility.org
People Over Process » RIA Weekly #44 - JavaFX In-depth Update, Coghead, the Flex Community, URLs for your desktop, USB Gadgets said
[…] Coghead shuts down – we liked Bob Warfield’s coverage. […]
People Over Process » Links for February 20th said
[…] Coghead Shuttered: Another in a Long Line of Non-Developer Developer Tools « SmoothSpan BlogPretty good write-up of what the problems with Coghead coulda been. […]
RIA Weekly » RIA Weekly #44 - JavaFX In-depth Update, Coghead, the Flex Community, URLs for your desktop, USB Gadgets said
[…] Coghead shuts down – we liked Bob Warfield’s coverage. […]
SAP se queda con Coghead said
[…] Smoothspan blog ¡Compartelo! […]
jasapir said
One thing to consider about tools like Powerbuilder is that they allowed many valuable applications to be built that otherwise would not have been affordable using traditional development tools like C. The fact that the tool isn’t around anymore does not mean it wasn’t extremely valuable at the time. The same is true with tools like Coghead.
Also, there is an enormous difference between situational application platforms like Coghead versus programming in PHP et al. Besides the obvious difficulty of learning a tool like PHP for most non-professional programmers, there is all the “stuff” that lies beneath the surface – stuff that a situational application platform takes care of automatically for the person building the solution. More at http://www.powerinthecloud.com/blog/2009/2/22/php-is-not-a-situational-application-platform.html
smoothspan said
Jasapir, I’m skeptical from a lot of standpoints, but two really stand out.
First, its far from clear how successful non-programmers are at building much with these types of tools. Yes, you may get people with no formal training to do interesting things, but are they really non-programmers? Most are not capable of doing that much with these tools. It all looks great in the demo and right up to the point where you need to do something you can’t because it “doesn’t fit the model.”
Second, how valuable can the apps be really if they don’t have enough ROI to allow a developer for PHP to be hired?
There is a reason why these tools keep getting built over and over again, but they don’t seem to ever amount to much. Perhaps it just isn’t that interesting a market for the two reasons I describe.
Cheers,
BW
jasapir said
Ahh Bob, spoken like a true programmer!
1. You only have to look at the millions of “applications” that have been written by non-professional programmers using tools like Excel and Filemaker to see how much can be done without “programming”. (So it depends on how you define “application” and what you consider to be “programming”).Also, many of the new platforms have been thought out well enough so they can be extended by programmers when you hit the wall of their limitations. The fact that you may hit the wall at some point doesn’t mean that all the other functionality you can build is a waste of time. That’s like saying that you shouldn’t use Excel, because at a certain point, you are going to have to write VBA.
2.The “R” required to hire a PHP developer is so high because the “I” is so high to begin with. The cost is not simply the programmers time. In fact, that’s often the least of it. The overhead for starting up and implementing any traditional IT project is so high, the return has to be really worthwhile. The whole idea of the long tail is to get the “I” down so that you can build applications that have a smaller “R”. This will never happen if you have to do things the traditional way.
Couple more things: (1) The point of a good situational application platform is not to turn end users into programmers – it is to allow non-IT professionals to build meaningful applications without becoming programmers. (2) The success of situational applications in an organization is more than simply providing a tool. It involves a different type of support organization with a different methodology and mindset. You can see the beginnings of this with IBM’s “Situational Application Environment (SAE)” and the IBM Mashup Center.
This is going to be a huge market in the near future. The trends are all coming together to make it happen – better tools, more IT-savvy users, cloud-based platforms that eliminate most of the implementation issues normally faced when deploying these applications, and most of all – the need for applications that are built closer to the user and at a much lower cost.
smoothspan said
Correction: spoken like a “programmer” who has founded companies based on these tools (Quattro Pro the spreadsheet was my creation) and run businesses including dBase, Paradox, and Reflex based on these markets. I’m very familiar with the tools, the customers, and the apps built by them. You assert that the new platforms can do more, but I’ve looked at them and haven’t seen it. How exactly are they better?
I had a guy pitching me to write a story on his tool. He was describing something it could do that he said was unique. He had a scenario where a form was linked to a chart and the data changed in real time. Just one problem: we did that back in the early 90’s with dbase and paradox for windows. So what’s really new there?
There’s a never ending list of these applications. Most crash and burn for the reasons I describe. I’m still waiting to see beyond the spreadsheet any of them get particularly far down the road. They’re less successful today than in the past and that’s not a good sign. Simply repacking them for the Cloud didn’t seem to help.
You say the point is not to make end users into programmers, but all of these tools, including spreadsheets, do make end users into programmers. They just set the bar a little lower. Your spreadsheet is just as susceptible to bugs as your Java code. These tools all require a certain amount of programmer thinking.
Here is an interesting way to think about it. The US Army at some point discovered that 1/4 of its recruits couldn’t read a map and couldn’t be taught to read a map. Interesting, no? It has to do with the way the mind percieves abstractions. I believe the same is true of programming, though perhaps the number who can’t is higher than 1/4.
One thing you don’t mention that is true is that the “P” tools have made it a lot cheaper for developers to do more apps. So the knee in the long curve has moved substantially to the right. A lot of the apps that used to be done in 4GL tools are now very amenable to these new “P” tools.
Cheers,
BW
jasapir said
No question, many people can’t learn to “program”. There are also probably many people who could learn to program but find it way too boring. But let’s take a simple end user “development” tool like Wufoo. You can build some very useful simple web applications using a tool like Wufoo. But the people using Wufoo to build these applications would never consider themselves to be “programmers”.
Maybe the conclusion from all this is that the barrier to entry for people who want to program is being lowered by the “P” tools, and the barrier to entry for people who want to build software solutions without programming is being lowered by situational application platforms.
BTW, I do think that these tools are starting to get substantially better. Like you, I went through the dbase/Paradox/Reflex etc. wars. It’s true that there is still nothing out there that truly breaks out the pack, but I see glimmers of hope. (For example, I recently saw a demo of a research project from IBM that has some new and interesting ideas http://www.powerinthecloud.com/blog/2009/2/19/ibm-application-creator-for-business-users-goal-driven-devel.html). It’s just a question of time. But there is still great benefit to be gained from using these types of tools, even if they aren’t yet perfect.
Coghead Roundup: A Collection of Analysis « SaaSkatoon: All Things SaaS! said
[…] Bob Warfield: Coghead Shuttered: Another in a Long Line of Non-Developer Developer Tools […]
Chui Tey said
The problem is not in proprietariness of these tools, but rather, ubiquity.
Excel works great simply because the runtime is everywhere, and the design-time is every where too. Proprietary has nothing to do with it.
Similarly, while PHP is a great platform for situational applications, one rarely sees it in the enterprise as a situational application. Reason: lack of ubiquity. I had posited that “IT [departments] should be more like a hosting service, where employees can throw together php applications, hooked to to an instance of their database, where IT provides the necessary hardware, backup and uptime.”
PaaS offers to work around any barriers set by corporate IT. More power to the people.
You are right in classifying any of these activities as “programming”. In any organisation, there will be 5% of people who are capable and enjoy developing tools to automate their work. These artifacts are then disseminated throughout the organisation, much to the chagrin of IT and security personnel.
smoothspan said
Chui, pardon my pun, but impropriety leads to ubiquity, while propriety inhibits ubiquity. It is tough to be ubiquitious when you have something completely new and foreign to any other experience.
Excel is everywhere precisely because everyone can and does use it successfully. However, even Excel benefited from a high degree of compatibility with the market leader of the time, Lotus 1-2-3. It eschewed being purely proprietary in order to increase its ubiquity.
If PHP seems uncommon in the Enterprise (an assumption I do not share, BTW), it is incredibly common compared to these proprietary tools.
I do not see the PaaS as a very successful end around of IT. SaaS is a successful end around. PaaS, to date, fails because it is too rare to find folks outside IT who are capable of making a PaaS do anything useful. That’s fine. PaaS is very useful to IT as well.
kaelgoodman said
Bob,
Sorry a little late to this party… hopefully not too late. Is you position that a lot of people have tried to build tools for non-developers in the past and not been successful and so in the future people will also not be successful? Put differently, past performance is an indicator of future performance.
Or, is your position that it is too hard to get this kind of tooling right and so instead people should go for a less risky approach and build tooling around the “P” languages and Rails?
If your position is the first, I’m not sure that logic would hold for entrepreneurs… where those who have come before and failed is only more fuel for giving it a shot.
If your position is the second, for me, I tried that approach in my organization with Rails, wasn’t happy with the result, and that’s partly what led to my interest in the PaaS space in the first place. This seems like a common refrain across the web.
Finally, I agree its going to be hard to get it right, but I also believe that someone will… though I’m not saying when. Just as the path away from assembly towards abstract languages has taken place, it seems inevitable that today’s abstract languages will be replaced by even more abstraction, further eliminating the need for low levels of programming… and opening the domain to more non-technical users.
– Kael Goodman
Force Architects: Delivered Innovation Blog » Coghead Roundup: A Collection of Analysis said
[…] Bob Warfield: Coghead Shuttered: Another in a Long Line of Non-Developer Developer Tools […]
Database.com, nice name, shame about the platform (Huh?) « SmoothSpan Blog said
[…] As I’ve said in previous posts, I’m not a fan of the “anyone can program with our special point and click application” ideas. The demos look whizzy, but this is really not innovation, and the tools are pretty limited in how far they’ll take you. We’ve similar tools for a long time under earlier guises such as 4GL or later guises such as the PC desktop databases like dBase or Microsoft Access. We’ve seen it in languages with UI Builders like Visual Basic or Adobe Flex. I have to say, we’ve seen a lot more point and click programmers than we have seen DaaS. In addition, the idea that the problem a DaaS solves is one that is already solved, in other words that they’re trying to make understanding databases easier for programmers who already understand databases is also pretty far off base (and surprisingly given McAdams’ past in DBA software). […]