Coghead: Web Applications for Dummies by Dummies

There's been a buzz going around about a new web startup called Coghead.  Heralded by Business 2.0 as one of the "innovations that could reorder entire industries," Coghead is lead by former Red Hat executive Paul McNamara and Extricity founder Greg Olsen. El Dorado Ventures, a Venture Capitalist firm, recently invested $2.3M in the company. According to McNamara,

Coghead will enable nonprogrammers to rapidly create their own custom business software

In other words, Coghead is the b*stard child of 4GL and Web 2.0; it's the end result of a careful mixture of myth and buzzword; and, I'm sure, it will play an important part in several upcoming The Daily WTF articles. Before we get into the details of Coghead, let's take a look back at the world of 4GL.

There's a bit of ambiguity surrounding what is and isn't a 4GL (Fourth Generation Language), so I'll stick with James Martin's characterization from his 1982 book, Application Development Without Programmers. The book's title should give you a good enough understanding of the goal of a 4GL: the ability to develop complex custom business software through the use of simple-to-use tools.

In the quarter-century since Application Development Without Programmers debuted, let's consider how far we've come on this goal: dBase, Clipper, FileMaker, and Access. It's a pretty far cry from what James Martin and the other 4GL dreamers had in mind. Sure, Jane in Accounting could easily use Microsoft Access to create custom software to manage her music collection, but ask her to develop the General Ledger in Access and you'll find your books in worse shape than Enron's and Tyco's combined.

There's a simple, common-sense reason why custom business software will always require programmers. It's the same reason that brickwork will always require a mason and why woodwork will always require a carpenter. No matter how complex and versatile a tool is, an experienced builder is always required to create something unique.

Like many other common-sense principles, the "software machine" is one that some programmers don't get. Be it with The Tool or The Customer Friendly System, these programmers believe they are so clever and so intelligent that they can program even themselves into obsolescence.

Some businesses don't get it, either. But they will eventually pay the price: the "mission critical" software they developed for themselves in Microsoft Access will become their albatross, costing time, opportunity, and, eventually, lots of money for real programmers to fix their mess.

And this is where we return to Coghead. You see, Coghead is merely another example of this arrogant ignorance, but this time it's web-based and enterprisey. That's right; unlike its desktop counterparts, Coghead is targeted towards big businesses, not small businesses and hobbyists:

"anyone who can code a simple Excel macro should have little trouble using Coghead to create even sophisticated enterprise apps like logistics trackers, CRM programs, or project management systems.

Even with a liberal application of AJAX, the fact that Coghead is web-based means that it's less functional and offers a poorer experience than its desktop equivalent. Not only that, but all data and business logic are left in the hands of a third party. That, in and of itself, is a good enough reason to avoid Coghead.


the Coghead web IDE

Twenty years ago, if you developed a dBase application, you "owned" it and knew that so long as you could find a MS-DOS 2.0 disk, your data and business logic were safe. If you developed a Coghead application, what would happen if Coghead went out of business? What if they upgrade their system and it breaks your application? What if you forget to pay the subscription fee and they delete your application? It just isn't worth the risk.

Some might argue that this negative analysis is a knee-jerk reaction to a threat. After all, Business 2.0 claims that Coghead will be a disruptor for "initially, custom software developers, but potentially almost all software-tool makers." But I'm not threatened by Coghead; I'm disappointed.

We've come a long way with software development in the past twenty-five years, from automated build processes to advanced integrated development environments. We've developed effective techniques for communicating with users and bringing them closer to the development process. Perpetuating the myth that programmers are an unnecessary part of the software development process does nothing but alienate users and frustrate them when the (programmer-developed) ÜberTool fails to deliver the results it promised.

##
UPDATE, Feb 19, 2009 -- and would you know it, CogHead is no more. And Access '97 still runs strong.

16 Comments

  • Alex, I agree that programmers are required for a large portion of the custom apps that exist today in the enterprise. What we're targeting is a class of applications that have been resistant to the custom development process. These tend to be apps that can't tolerate the time and expense of custom app development. They are a myriad of less-complex applications and business processes that today are generally unautomated or at best handled by speadsheets or Filemaker or Access.

    Our focus is business applications. The term 'Enterprise' means different things to different people. To some, it means large-scale complex applications. To others it simply describes the size of the business. We say that we are targeting small and medium size businesses and enterprise workgroups. I think the press sometime translates the term 'workgroups apps for enterprises' to 'enterprise apps'.

  • We've seen this kind of stuff come and go dozens of times. The only thing Coghead will ever succeed in doing is creating a niche market for programmers who have knowledge of Coghead.

    Smart business people don't WANT to mess around with this stuff - that's the whole point. Someone will sell a detached executive on all the pretty flashing lights of this application and in the end the customer will STILL go out and pay the technology people to use the pretty new tool they just bought. Or worse yet, they'll pay the technology people to dig them out of the immense hole they dig for themselves trying to do something that is completely out of their element.

    The customer will inevitably have it so hacked up and stretched beyond its operating limits that it would've been cheaper, easier, and more effective to just have a professional create precisely what the customer needed in the first place and move on with their business affairs.

    It is indeed sad that our industry still has so many ignorant and/or arrogant people in it continually giving the industry a bad reputation to overcome. Programmers and even IT professionals in general just need to do their jobs and quit thinking they're so brilliant that they're going to single-handedly change the world with their eccentric ideas.

  • Alex's two second tutorial about 4GL, while lame and useless is a sharp contrast to what I read in Queue magazine (you can find it on slashdot as well) a few months ago authored (I think) by the same Greg Olsen you mentioned above.

    Based on what I read, and what I see above, I'm guessing Greg knows, ummm, 20x more about this subject that Alex.

    Another example of the "media" trying to take on a subject too complex for their own good perhaps?

    Anyways - I checked the website and it does not look like Coghead is even available yet, so unless Alex has early access, how do you even have a basis for all of this? Did Business 2.0 decide to exclude you from the same article or something?

  • Have you checked out DabbleDB yet? I was pretty impressed at how they made a lot of the functionality of an RDBMS accessible to everyday schmoes and office workers. You still have the same problem of putting your data in a third parties hands, but the UI concepts they put forth in their application seem pretty solid.

    I would be less afraid of a secretary/admin assistant designed DabbleDB than I would a secretary/AA designed Access database.

  • Graphical programming tools only really work for very specialized applications. The best example I can think of are 3D animation applications: your data is really well defined, everything is based on movement over a timeline, etc, the application is already visual.

    The screenshot makes it look like a general programming language turned graphical, i.e., a programmer's flowchart. (if/then/etc.) These are unfortunately not that useful to untrained users, and limiting to programmers. Even really well-done graphical programming systems take expertise, but I'm skeptical that many companies will really understand that and take the time to train employees on the tool.


  • I think the reaction of this post is a similar one I hear from Linux fans. When someone views the world through a perspective where their focus and time are mostly consumed by running the environment they are a fan of (Linux, Rails, PHP, etc) - then they can't imagine a world where someone might want to use technology to achieve a goal that is only part of their day and need to leave time for their other duties such as running a business or being a doctor or writing a book.

    Developers and hobbyist will always look at solutions such as Coghead and DabbleDB or Microsoft Office for that matter from a viewpoint that they are "expensive", "Untrustworthy" and "not under my control". But people who spend most of their day a few layers removed from coding or hardware tinkering are willing to sacrifice some money and some control to a trusted third party to recapture some of their time or better yet move initiatives forward much faster and in parallel with other initiatives.

    Not everyone values their time at $0 and not everyone has lots of it to spare or a highly technical social group . For those people CogHead and DabbleDB are useful tools to let them play with different what-if scenarios quickly and at a low cost. It also lifts the burden of "simple" apps off of a developer and let's them concentrate on the really hard problems like generating pixel perfect PDF reports from these solutions or LDAP based integration of various solutions.

    I think solutions like Coghead and DabbleDB will make interaction between non-programmers and programmers even better, giving each side a better respect for the intelligence and skills of the other. A user of these solutions will think twice before asking for help from a developer before thinking through their requirements because they would have experienced first hand the double and triple work that occurs when you don't think and plan things through in advance. They would have learned this from their time using Coghead or DabbleDB.

  • An anecdote comes to mind, from around 1980.

    A friend went to a trade show where a salesman was showing off his new "natural language" database. "Just ask a question in English! This sample geographical database has all the rivers and mountains in the world."

    My friend typed: "What are the tallest mountains in Africa and Europe?"

    The computer replied: "There are no mountains in Africa and Europe."

    Which was correct, technically, but not useful.

  • @Buford: There are mountains in both Africa and Europe. The problem was the program did the intersection of the set of mountains in Europe with the set of mountains in Africa, which of course gives the empty set,
    because "There are no mountains in Africa and Europe".


  • "Programmers and even IT professionals in general just need to do their jobs and quit thinking they're so brilliant that they're going to single-handedly change the world with their eccentric ideas."

    Yeah, that kind of attitude has never resulted in anything good or useful.

  • Whenever a new "programmer-obsolesence tool" like this one comes along, a good question to ask is, "why do they want to get rid of the programmers?" I suspect that the reasons fall along mostly the same lines - the programmers aren't receptive to the realities of the business (e.g. they insist that the development will take 6 months when it's needed in 1 week), the programmers are too expensive, it takes too long to transfer the domain knowledge out of the heads of the people who have it into the heads of the programmers, etc.

    However, I contend that, even if Coghead is successful, all of these problems will persist - the people who learn to use Coghead will discover, from bitter experience that yes, it does take six months to build a six month application, the experienced people will be lured away to greener pastures by more money (and become expensive), and the people who work with Coghead won't have the time to maintain the domain knowledge and the knowledge will still need to be transferred.

    And, of course, Coghead runs on a computer. Things that run on computers break in computerish ways (Network timing out? File system full? Auto-generated file name longer than the OS-prescribed limit?) and experienced computer people are needed to troubleshoot what broke, and where. Either the (former) business gurus who started learning Coghead (until it became their 24x7 life) will need to also pick up knowledge of all of the random computer quirks that we recognize immediately, or another layer of staff will need to be added to support the application when it goes wrong.

    Whatever problem you think you're going to solve by getting rid of the programmers will circle back around and become a problem again.

  • When I went to work for a mom-and-pop web development shop a few years ago, the first thing they had me do was write a web-based time tracking system.

    My sister the contract programmer told me that every time she got a new consulting gig, the first thing they wanted her to do was write a time tracking system.

    What a waste of time, each of us developing custom apps for a common need.

    Coghead may turn out to be total, mmm ... poo, but I signed up for the beta to see if at least it might save me from inventing a couple of wheels ... and maybe save someone else from inventing wheels I'm already riding on.

  • Hey, I just got my beta test ID. Shall I blog it?

  • Anyone remember "The Last One" from 1980/81 on the Commodore PET? It was going to be the last program that would ever be bought as it would write all the code for future business applications.

    Its pure arrogance made me giggle in 1980 and, I'm afraid, it and its successors still do.

    Cliff.

  • Coghead seems to be pretty cool. I haven't learned all it's features yet, but for some reason I found Intuit Quickbase much easier to use, at least to start off. Quickbase seems to have an interface that doesn't look as "flashy" (no pun intended) but seems more intuitive and easier to use for some reason. Maybe it's the fact that you build your tables from scratch using the interface and then you build your forms. While Coghead lets you build your forms when then builds your table structure automatically. Once I wrap my head around it I'm sure I'll like it. Oh and the other thing I wish Coghead had was the ability to share applications like Quickbase does. That feature alone is worth a million bucks. Quickbase has an application library of at least 50 or more apps. mostly created by end users who have chosen to publish them. I can't seem to find the same thing in Coghead.

  • Craig, again, don't speak of what you don't know. Coghead may be using some kind of XML database, not big XML files. There are several XML databases out there that make dealing with XML very quick. You can index records, and do advanced queries quickly with XQuery.

  • so... now Joshua Davies' question from 12/2007 becomes relevant: SAP has taken coghead "off the market" (too much competition for their own "COBOL punched-card in a relational database" ???)... what of all the coghead apps? do those poor souls now have to purchase SAP and hire non-english speaking consultants to get at their data?

Comments have been disabled for this content.