Reality Check: Coghead

Coghead provides a web-based application that allows tech-savvy businesspeople (that is, non-programmers) to create and deliver their own web-based applications. Essentially, it’s bringing the “do-it-yourself” trend to software—hopefully disrupting tradition and changing the way software is created and used. It can help fill the large, unmet need for small, specialized applications because packaged software is too inflexible and custom development is too expensive and slow.

Coghead’s website is both an application authoring tool and an application delivery service. At Coghead’s website people can create an application using simple-to-learn methods (or pick a pre-built app from Coghead’s application gallery) and then invite co-workers to use the application. All anyone needs is a browser and an Internet connection. The key selling points are:

• There’s no need to purchase new hardware or software.

• Users can access applications anywhere they have Internet access.

• Coghead applications are inherently multi-users.

• Data and application are managed centrally and off-site.

These days lots of people complain about needing custom applications to do their jobs better, but not being able to get them because IT is busy with other things or because custom application development is just too expensive. Coghead aims to empower the people closest to the need to create and deliver business applications in hours.

Coghead advances the state-of-the-art in a couple of other areas as well. First, Coghead allows you to create applications with meaty business logic. “Business logic” used to be the domain of enterprise applications like SAP and Oracle. Coghead has included an intuitive ‘process builder’ that lets people put real business logic in their apps.

Second, Coghead provides rich web services integration. When you create an application in Coghead, it automatically generates a web services interface for that application. It also provides the capability to integrate external web services from other applications. All this means that Coghead is a sweet platform for creating mash-ups—applications that integrate with other web services like Google Maps or stock market feeds.

Coghead is just now rolling out their public beta and they already have several thousand people on the waiting list. Click here if you’d like to sign up for the public beta.

Full disclosure: I am on the advisory board of Coghead.

---

---

Comments

[David Broderick]

It's funny, because unlike many of the comments here, I believe the future is going toward end-users defining what they want without a middle-man, such as a programmer.

The problem here, and the reason I gave this a thumbs-down, is that I saw the definition mechanism they use is... a flowchart. This would be fine if the year was 1974. But as we have known for a long time, that won't scale. It will look great on demos, it may even shine for very small apps, but when it comes to real-world applications, it will simply explode, like all the others that preceded it. Coghead has sadly put a lot of money and effort into something without first taking away the same roadblock that stopped the others that preceded it. Maybe they thought the roadblock was that the other attempts were not web-based enough? There is movement in this space, but it's not here. Good luck. Thumbs-down.

[Devdas Bhagat]

Quoting Richard Letts:
With development nowadays I'm seeing that 25-35% of my time is being spent on design, 50% on test, leaving 15-25% for coding. It looks to me like Cogworks is really only going to help me with the 15-25%.

I seem to recall this being mentioned in that little book named 'The Mythical Man Month'.

Quoting Denise:
It could be that programmers want job security, and are threatened by the concept of programming power in the hands of business people, or it could be that they know something that business people don't.

Programming is _not_ factory work. Programming is design, and debugging that design. Once the design is complete to exact specifications, the program is delivered.

Design which requires rigorous checks, particularly against boundary conditions, legal issues, malicious users, system failures ... .

As someone else put it, a program is an exact specification in a formal language. If users were able to provide exact specifications, programming as a skilled task would be eliminated.

The trouble with that is that English is not a good language for formal specifications. If you see the history of Mathematics, the field advanced when mathematicians adopted a formal symbolic language which could specify exactly what they meant.

Programming itself is not difficult, anyone can write simple programs. Deciding on implementation models, and specifications is hard.

Programmer truism: Users have no idea of what they really want.

[Kamisamanou Burgess]

Great write. I enjoy your blog very much. By the way, you forgot a couple of colons(;) in your post.

[Chris B]

It's pretty easy to pick out the programmers in the comments above. It never feels good to be told that an untrained person can do your job.

But, have you guys never heard of Access Db? Reality check - non-programmers develop their own applications all the time, in almost every large enterprise in the world (sometimes "developers" build things in this nasty little solution too). This stuff is EVERYWHERE, but the current model for building it, and most importantly, for supporting it (and trust me, IT eventually has to support it), is horrible. It sounds like Coghead could help with this problem.

I'll be interested to see if this becomes a preferred alternative to Access Db within enterprises, and actually gets pushed by IT for this purpose.

[Edwin Khodabakchian]

They have to make sure that they learn from the past: Avinon. Raised 15M. Was on steroids for a couple of years. Amazing demos. But after 2/3years, no real paying customers. Assets sold for $75,000.

It could be timing...but I think that there is more to this. The value proposition is interesting but the solutions are too simplistic to solve most real worlds problems. Specially with tools like excel and Google speadsheets removing some of the low hanging fruits.

-Edwin

[Mark Aufflick]

Another interesting player in this space is Dabble db founded by the Uber smart Avi Bryant.

It's really worth checking out. There's a great 7 minute demo that should leave you saying "wow"!

[Richard Letts]

As a collector of new programming languages I have a somewhat jaundiced view of anything which claims to bring the power of programming to non-programmers. Older folks will remember when COBOL was supposed to allow business people to write programs, others might remember 'The last One' trumpted in a BYTE article from the 1980's, and there was Novell's AppWare from the 1990's that allowed one to build a program using a drag-and-drop GUI interface.

I'm not sure business people have the time to use this sort of software-as-a-service, and so what you might see it being used for is as a RAD tool by programmers. With development nowadays I'm seeing that 25-35% of my time is being spent on design, 50% on test, leaving 15-25% for coding. It looks to me like Cogworks is really only going to help me with the 15-25%.

[Jon]

Not that I'm knocking Coghead. I'm sure it's a fine product with many uses, but...

When done, it really isn't right ... so is it not right because of the spec, the coding or both.

Wait, so you're telling me that a 3rd party application with it's own (potential) pitfalls has a better chance at creating exactly what you want and need that the people closest to the problem?

I think you already hit the nail on the head when you wrote:

... because of the spec, the coding or both.

Fix a problem where the problem exists. If the problem is the spec, have a better (and/or more accurate) spec written. If it's the code, have better (and/or more accurate) code written. An oversimplification, perhaps, but it just seems to me that if your roof is leaking, would you head over to your neighbors house to fix it?

I could be wrong, though... it's happened before. :)

[denise]

I'm willing to bet that nearly everyone whose response to this product was along the lines of "great idea!" is on the blue oxford-wearing side of the office, and nearly everyone who answered "not a good idea" is on the t-shirt-wearing side.

I don't doubt this idea came from the business side, from the perceived need to cut costs and speed up the process of getting powerful tools built and into their hands.

It could be that programmers want job security, and are threatened by the concept of programming power in the hands of business people, or it could be that they know something that business people don't.

To me (a designer, somewhere in between camps) it seems that at the core of Coghead is the assumption that computers can sometimes replace programmers, and that programmers' most valuable contribution to a product can be measured in syntax and lines of code. It oversimplifies reality, and discounts the significant planning, strategy, and institutional knowledge behind (even small) applications.

You would never believe a product that claimed to be an end-run around your car mechanic, plumber, or electrician, would you? There is often a correlation between expensive work and work most people don't understand. It's only when they try to do it themselves that they figure out how much they don't know.

It's bound to fail.

[Mo]

Sounds like Ning, which never really got off the ground.

[Nathaniel Smith]

From this description, the tool's premise is "bring programming power to non-programmers". Right, cool, an excellent goal. But, this has been the rallying cry of failed system after failed system for decades, now, until many people's gut reaction is going to be to just roll their eyes and not even bother finding out more. Maybe Coghead is the tool that will finally change all that -- but your pitch needs to tell us why!

[Berislav Lopac]

I have five words for the concept of non-programmers' programming: the law of leaky abstractions.

[Rafa]

Users can access applications anywhere they have Internet access??????

Watch!!
http://hobbiesvideos.blogspot.com/2006/10/lindas-garotas-jogando-futevlei-no-rio.html

[murphtron]

I'd like to try this out. However, I cannot help but think of prior efforts and how they were ultimately derailed. Not because these are bad ideas. They are not. Mainly because these tools reach a diminishing point of return as they evolve. Initially they are fun and exciting to use. However, as the users requirements evolve, you find that the tool cannot meet the requirements (usually when it comes to creating 'business logic'). Then the tools evolve and before long they become full-fledged development environments with complex IDEs and 'languages' in which to create biz logic. Then they become unusable to the target audience. I know, it's a vicious cycle that's repeated over and over again. This is how PeopleSoft started with PeopleTools. There are numerous other examples.

That being said, I'm excited that Coghead uses BPEL, presumably with extensions since BPEL assumes humans don't exist, and that web services are created as a by-product.

Final thought. Don't think the big boys aren't also playing in this area. SAP has Visual Composer, and Oracle has Application Express (arguably a better implementation than SAP's VC).

Best of luck!

[Josiah Ritchie]

Will I be able to import/export data from the system in some automated way so that I can hook/sync it up with my other programs? That would be somewhat critical for the needs I can think of.

It would also be handy if it could share an external authentication database somehow.

[andy b]

Conceptionally, I am thrilled with the tools that are becoming available, CogHead looks like a tool with great possibilities.

However, I am having a dilemma wrapping my head around all of the Enterprise 2.0 concepts.

Here is the problem...I am in IT, and while yes we are often busy, it is generally because we are responding to an external issue that can cause great pain for the organization...things like SAS70 audits, SARBOX compliance, GLB compliance, HIPAA compliance, etc...

We work extremely hard to bring our organization into compliance with all of these regulations, only to be told that we are ignoring our users and our users go out and find a tool like CogHead and build an application that causes us to FAIL in all of our compliance efforts...especially those involving privacy issues and data sharing with 3rd parties.

If it is not compliance, then it is Total Cost of Ownership (TCO) edicts placed upon us by our executive leadership. One of the easiest ways to lower our TCO is to standardize hardware, software, processes, etc...but that makes us unresponsive to our users and the cycle begins all over again.

Your thoughts on how to deconflict all of this?

[Francis Wu]

This looks totally brilliant. Can't wait to try out the beta!

[Amar Rama]

While not as slick thingamy (www.thingamy.com) has similar goals.

[Dave Starr]

Looks like a good pick, Guy. It isn't only that custom web apps are expensive in terms of programmer hours ... either internal or contracted out ... but it's the age-old chicken/egg problem. My small business or department needs a tool. So we labor at writing some kind of spec (an art in itself) and then the application programmers do their best to meet the spec. When done, it really isn't right ... so is it not right because of the spec, the coding or both. The biggest power of CogHead may be to move the users closer to the design process and thus require far fewer iterations to get an app that actually fills a business need rather than the arbitrary requirements of a spec.