The first PHR Patent Troll?

The following just came across my Google Alerts:Healthcare Analyst Values MMRGlobal Patents at $300-800 Million. This is scary. I’ve seen this company for years; they were one of the pack trying to build personal health records in the mid-2000s, and from what I’ve seen there is nothing in their historic offering that was particularly innovative – except that unlike most of the others running around at the time, they appear to have had some budget to file some patents, and they have now commenced shaking other people down.

Now, I haven’t done a very complete review of their patent holdings, and they may well have some highly innovative, original work there that took a substantial investment to develop and realize. But that’s not the trend, and I’m very concerned that this could be problematic for a lot of small innovators in the personal and clinical health records markets. Software patents have become a real problem across a variety of domains, but so far HIT seems to have avoided the worst of it. I suspect that this is in part because of industry’s long history – most of the core capabilities were introduced long enough ago that any patents would have expired. There’s a ton of prior art: you can track a lot of personal health monitoring to 1994′s Guardian Angel Manifesto. But that’s expensive to litigate when the trolls come out from under the bridge.

As it stands, I’m looking for defensive patent structures for my own start-up so that we have some chits to trade if someone comes knocking. And that’s a shame – I have better things to do with my time.

Learning to Code

Knowing how to code is a really useful skill for anybody in business. For an entrepreneur, it means you can validate your high-tech startup idea without having to out and recruit a CTO or spend a lot of money on an external software development shop. But even if you’re running a pizza place, a little bit of coding experience can save you a lot of time when you’re playing with Excel spreadsheets late at night trying to figure out how much money all that fancy pepperoni is costing you.  Most people are in the middle. I have a lot of friends who went into management consulting – the ones who know how to write little bits of software to help them do their jobs tend to get a lot more sleep at night.

The other reason to learn programming – even a little bit of programming – is that it makes the whole process of interacting with technology a lot less scary. Computers are black boxes, and people don’t trust black boxes.

So I thought CodeAcademy was pretty cool. It’s a web site that takes you through some simple programming exercises in JavaScript, which is one of the most common programming languages on the web. In half an hour you can go from no experience at all to writing simple programs. They don’t do that much, and to solve real problems you’ll have to do more. But it’s a nice way to start out – and even if the student doesn’t go any further they’ll benefit from a more visceral understanding of how computers work. In the best case, it will teach them to recognize the kinds of patterns that can be solved with a little code.

Having written that, I suppose I should consider the opposite extreme. Just because you can write simple programs after half an hour of interactive lessons doesn’t mean that software development is either easy or low-value. It’s not. A top-tier software engineer took thousands of hours to get that way.

Expensify: A Case Study

I hadn’t heard of Expensify before I saw a TechCrunch piece on the company this afternoon. I happened to have several expense reports outstanding for a consulting client. I hate doing expense reports – scanning all the pieces of paper, putting together a cover document and putting everything into a PDF. Except during the relatively rare interludes in my career where I’ve had an assistant I can thrown receipts at and then race out of the room (Hi Andrew!), I’ve always been really bad at these. I have no excuse: my first boss taught me many useful skills, and precise receipt keeping was one of them. I just hate doing the reports. For that matter, I was never all that good at getting the receipts to my assistants.

Expensify LogoSo after reading the TechCrunch article I logged into Expensify, and half an hour later all my consulting expense reports but one were done and sent off. All of my expense reports for Linked Medical, our new startup, were done too, and filed in the “pay when we have more money” bin. I don’t think any web based tool has ever become so essential to me so quickly. One of the first “ASP model” web applications I ever used was the Ariba purchasing system, after my early-2000s startup became part of a much larger company. It was truly terrible. Fortunately I had an assistant.

Expensify’s product is pretty far from that original Ariba system. Sure, the software isn’t perfect, and a few of the rough edges are downright weird considering the overall level of polish (uploading a “.htm” file receipt gives you an error message, while “.html” works just fine). But they did at least six things right, and those six things are relevant for lots of different applications:

  1. Make it brain-dead easy to start. I typed in my email address and was done. They sent me an email which I later clicked through to set my password. There was zero friction, which is incredibly important. I could also have logged in with my Google credentials, which is a nice touch – but this was actually faster.
  2. Make it easy to explore. The home screen is a series of big boxes identifying common interests for new users. I’d heard about the mobile tool first, and it was one click to learn more. The basic navigation is very simple, and maps to things like “Receipts”.
  3. Use Mobile for the right things. This is really important. I do not want to create an expense report on my Android phone. I probably don’t want to create one on my iPad either. When I’m mobile, I want to do one thing: easily record expenses. So the mobile app does that very well – I can photograph a receipt with my phone, and/or enter expense details on a simple screen. There are two big buttons when I open the application, one for each option. It’s very responsive. And I don’t need to keep the small receipts anymore.
  4. Integrate seamlessly, but don’t make me do it first. Another box on the home page is “Link Credit Cards.” It took two minutes to link in my American Express, and then I had a huge list of transactions to choose from.
  5. Give me multiple avenues to learn the software. I can add expenses to a report from the report, or I can look at expenses and add them to a report. Same with receipts. I never found myself having to go back into the wrong area of the application. When I looked for a feature, it was there.
  6. Don’t make me learn the whole thing. Expensify supports “policies” for corporate expenses. There are some other features there too around submissions and approvals. I don’t need those yet, so I didn’t have to use them, learn about them, or worry about them. As it happens I have looked at them, and they’ll be useful in the future – I just don’t need them now. Complexity kills, especially when you want casual users to adopt a system without external support. Expensify landed me as a customer because I was able to finish an expense report in 15% of the time it would have otherwise taken.

They also do a good job of thinking about ways that new technology lets you change the underlying workflow of an old process. In this case, it’s expense reports for receipts under $75. If you link a credit card, you can import expenses and the system generates an “eReceipt” for that charge. Expensify prints it in the report and adds a bar-code, and it can be verified with the site later. The company will stand behind the fact that the expense was imported from a credit card statement, up to and including during an audit from the IRS. If your corporation accepts the eReceipts, you can stop carrying around those little printouts from taxis. This is something that the old Ariba system – or any non-cloud expense account system – simply can’t provide, because it relies upon the trusted connection to the credit card company, and on Expensify’s willingness to stand behind the integrity of that data.

When turning workflows into products, it makes to ask what capabilities are available now that weren’t available on paper or weren’t possible electronically with the technology of a few years ago. The eReceipts are a great example of this. Development for the iPad should be triggering a lot more of this kind of lateral thinking, as we all adjust to touch-and-swipe interfaces instead of keyboards and form fields.

Naturally there are a few things Expensify can improve on. I’m glad I didn’t need to take a training course to use the tool, but a five-point introduction to the core concepts would have been nice. The most opaque thing about the system is the relationship between receipts and expenses. It’s not actually all that hard to figure out, and the system gives you helpful messages. But an introduction presentation would have made things clear from the get-go. Dropbox does a great job with that.

Any time you’re asking users to think about the attributes of a data model you’re asking for a certain amount of trouble. In this case, the idea of “reimbursable” and “unreimbursable” expenses also needed some clarification. Since I was in consultant mode when I was doing today’s reports there’s no concept of “unreimbursable” – but I’d unclicked the default when I was linking my credit card because I thought that leaving it as “reimbursable” would make more work for me as I filtered through expense lists. It turns out this is useful for corporate cards, which makes sense – but I’ve never carried a corporate card where I didn’t get the bill myself (oddly, this was true even when I worked for the Federal government).

The bottom line: a very useful service and a great source of ideas for making other web applications easier to use. Oh, Expensify guys -please add an “email receipt” feature like TripIt’s, if you haven’t already.

Hiring Programmers – The One Question Interview

First off: the blog is back. I will refrain from commenting at any length on why it had gone away, as introspective blog posts about the process of blogging are boring. Sometimes you’re blogging a lot, sometimes you’re not.

I’ve been thinking a lot lately about hiring programmers. I’m launching a new venture, and I’ve been very luck to bring one of my favorite people on board to lead our development team. He’s brilliant, hard working, polymathic and generally willing to dive into things which have to be done but may not be massively interesting. I’ve hired a few other people like this in the past, and when I have the opportunity to hire them again (and the role is appropriate) I always go for it.

I do that because it’s a complete crap-shoot otherwise.  I’ve got it easy – since I wrote a few books on software development between the late 90s and middle 2000s I have a good reputation as a boss who knows how software gets developed. That’s made it easier for me to attract top tier people – much easier than if I was a pure business guy, regardless of however good a business guy I may have been.

So I enjoyed reading Jon Evans’ Why The New Guy Can’t Code. It’s a nice overview of some of the pathologies, particularly the idiocy of the brain teaser interview. Evan’s suggestion is that you don’t even bother interviewing people who can’t say “I got this done” where “this” is a self-contained project. And I basically agree.

The guy I brought back for the new company has been a friend for fifteen years. We went to high school together. So when I hired him I was cheating – I knew exactly what I was getting into (and I made sure my then-business partner was on board so that I had a check on any desire to hire a friend). After that point, however, I was out of rock-star friends who were looking for jobs, so I had to go looking the more conventional way. And in each case, the interview went the same way – we sat in a room and talked about projects for an hour. In some cases I had other people on the team do more conventional technical interviews, but I usually found I didn’t need them – by having someone clearly explain what they had done to build an application I could easily tell whether they actually had the skills they claimed. I could also tell how they worked in teams, and how they thought about problems.

The sample size is pretty small – maybe 30 people interviewed over the last five or six years. And everybody we hired wasn’t perfect. In those cases we usually had some misgivings to start, and we corrected fast. But by and large, we got the rock-stars, or at least the guys in the band. And we never had an issue with competence.

Of course, having a good HR department that knew how to source candidates properly (by going after the already employed at companies that were closing up and filtering out the top few people) helps. But the best people can have a conversation. And phone screens help – you can start this discussion on the phone, and if they can’t start telling you about a project they did within the first few minutes, time to move on.

Another good take on this issue is Why Can’t Programmers.. Program? which describes a great simple test to weed out the obvious non-coders in five minutes or less. Surprisingly, it excludes quite a few people with C/S degrees.

 

The End of Google Wave

Google killed Wave on August 4th. I wrote a bit this morning about Google Wave and knowledge worker collaboration over on the Beacon 16 blog, so if you want to know more or less what I’m talking about, check that one out.

What I liked about Wave from the healthcare perspective was the way it managed conversations. I could easily see the platform extended to care planning and coordination, and I had some fairly specific ideas along those lines. They may still see the light of day in the context of some our other projects – the idea of replacing chains of email with something that was just as easy to use but created an automatic running summary of the conclusions drawn by the group (and which made it easy to reconstruct the discussion behind that reasoning) was extremely compelling.

Changing Platform Rules

TechCrunch reports this morning that Facebook is changing the rules (again) for third party developers. They’ve done this a few times. So has Apple, on the iPhone platform – when they can be bothered to fully explain the rules in the first place.  Meanwhile, Motorola introduced Droid today – the new flagship Android 2.0 sliding keyboard phone.  Unlike Facebook and Apple, Android is an open platform, without Google guarding the gates for developers. And developers are already complaining that the in-market mix of Android 1.5, 1.6 and 2.0 is driving development costs towards an unsustainable endpoint.

All of this has got me thinking about the challenges of building applications on other people’s platforms.  Whatever users may say about Windows, Microsoft has always treated its ISV partners pretty well.  Lots of notice, and no arbitrary barriers to deployment (Apple) or random, substantive policy and feature swings (Facebook).

I have no deep insight here, but I’m curious – particularly in our area of healthcare informatics and public health, how much is platform instability (and profusion!) limiting the development of next-generation applications?  What’s required to justify an investment in these platforms?

As for Android – depending on what the reviews look like, I’ll probably get a Droid next week or the week after, despite my Sprint contract.  I’ve been fully fed up with Windows Mobile for a while, don’t like Blackberrys, and need a sliding keyboard. Hope the application developers keep up…

Adventures in JSF 2.0: Hello World Tutorial using Maven 2, JSF 2, Facelets 2, and Weld

In the first of many posts regarding the recently finalized JSF 2.0, I will be showing you what you need to do to write a simple Hello World Application. Instead of traditional JSF backing beans, this application will use Weld, an open-source implementation of JSR-299: Contexts and Dependency Injection for the Java EE platform. JSR-299 will be part of the upcoming JEE 6 specification.

Prerequisites:

Install Sun’s JDK 6, the latest version of Maven (presently 2.2.1), and the IDE of your choice.  I use Eclipse, but GEdit or notepad would work just fine. For this demo, I’ll be using Jetty, so you won’t need to install a container of any sort.

Getting Started:

Create Empty Project

Our first step is to create an ordinary empty WAR project in Maven using the

archetype:generate

command in the directory of your choice.

cd ~/workspace #this can obviously be anywhere.
mvn archetype:generate -DinteractiveMode=n -DarchetypeArtifactId=maven-archetype-webapp -Dversion=0.0.1-SNAPSHOT -DgroupId=org.bogus -DartifactId=jsf2_tutorial

Unfortunately, the default Maven archetype falls short of what we need, so we need to make a few extra directories.  We need a java directory and the test java and resources directory. I’ve also added the commands that an eclipse user would use to generate an importable eclipse project. Netbeans and IntellJ users can simply import the pom.xml.

#create a few extra directories for the project.
mkdir jsf2_tutorial/src/test jsf2_tutorial/src/test/java jsf2_tutorial/src/test/resources jsf2_tutorial/src/main/java
cd jsf2_tutorial
#if you're using *NIX, you can create empty files with this command.
mkdir src/main/java/org/ src/main/java/org/bogus/ #need to create package first.
touch pom.xml src/main/webapp/WEB-INF/web.xml src/main/webapp/WEB-INF/beans.xml src/main/java/org/bogus/HelloWorld.java src/main/webapp/index.xhtml src/test/resources/jetty-env.xml

Overview

I was very impressed that a simple Hello World project can be created with as little as five artifacts.

  1. /pom.xml
  2. /src/main/webapp/WEB-INF/web.xml
  3. /src/main/webapp/WEB-INF/beans.xml
  4. /src/main/java/org/bogus/HelloWorld.java
  5. /src/main/webapp/index.xhtml
  6. /src/test/resources/jetty-env.xml (for Jetty users).

Writing the actual Code

pom.xml

The first step is to the pom.xml file. Afterwards it can be easily imported into any modern IDE.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>org.bogus</groupId>
	<artifactId>helloworld</artifactId>
	<packaging>war</packaging>
	<version>0.0.1-SNAPSHOT</version>
	<name>JSF 2.0 Tutorial</name>
	<repositories>
		<!-- As of October 2009, a few of the weld dependencies were not yet on the main maven repo.  We can add JBoss repo as it is updated more frequently.  -->
		<repository>
			<id>repository.jboss.org</id>
			<name>JBoss Repository</name>
			<url>http://repository.jboss.org/maven2</url>
			<releases>
				<enabled>true</enabled>
			</releases>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>
	<dependencies>
		<!-- Common -->
		<dependency>
			<groupId>javax.enterprise</groupId>
			<artifactId>cdi-api</artifactId>
			<scope>provided</scope>
			<version>1.0-CR1</version>
		</dependency>
 
		<dependency>
			<groupId>javax.annotation</groupId>
			<artifactId>jsr250-api</artifactId>
			<version>1.0</version>
		</dependency>
 
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-api</artifactId>
			<version>2.0.0-RC</version>
		</dependency>
 
		<!-- Jetty-specific scopes and artifacts -->
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-impl</artifactId>
			<scope>runtime</scope>
			<version>2.0.0-RC</version>
		</dependency>
 
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>jstl</artifactId>
			<version>1.2</version>
			<scope>runtime</scope>
		</dependency>
 
		<dependency>
			<groupId>org.jboss.weld.servlet</groupId>
			<artifactId>weld-servlet</artifactId>
			<version>1.0.0-CR1</version>
			<scope>runtime</scope>
		</dependency>
 
		<dependency>
			<groupId>org.glassfish.web</groupId>
			<artifactId>el-impl</artifactId>
			<version>2.1.2-b04</version>
			<scope>runtime</scope>
			<exclusions>
				<exclusion>
					<groupId>javax.el</groupId>
					<artifactId>el-api</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
	</dependencies>
	<build>
		<finalName>jsf2</finalName>
		<plugins>
			<!-- Compiler plugin enforces Java 1.6 -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>1.6</source>
					<target>1.6</target>
				</configuration>
			</plugin>
 
			<!-- Eclipse plugin enforces download of source and JavaDoc jars -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-eclipse-plugin</artifactId>
				<configuration>
					<wtpversion>2.0</wtpversion>
					<downloadSources>true</downloadSources>
					<downloadJavadocs>true</downloadJavadocs>
				</configuration>
			</plugin>
			<!-- Embedded Jetty (jetty:run) -->
			<plugin>
				<groupId>org.mortbay.jetty</groupId>
				<artifactId>maven-jetty-plugin</artifactId>
				<configuration>
					<!-- force friendly name instead of artifact name + version -->
					<contextPath>${build.finalName}</contextPath>
					<!-- Where the BeanManager is constructed.  This is where we'll later declare datasource. -->
					<jettyEnvXml>${basedir}/src/test/resources/jetty-env.xml</jettyEnvXml>
					<!-- This parameter will auto-deploy modified classes...my personal favorite Jetty feature. -->
					<scanIntervalSeconds>3</scanIntervalSeconds>
				</configuration>
			</plugin>
		</plugins>
	</build>
</project>

Now that your pom is complete, you can import it into the IDE of your choice. Eclipse requires users to either install m2eclipse or run:

mvn eclipse:eclipse

Boilerplate

web.xml

Since JSF 1.2, the web.xml page got a lot smaller. This is where convention over configuration pays off. Also, faces-config.xml is now optional!

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
	<!-- Standard JSF 2.0 Configuration Paramters. -->
	<!-- No Joke!!...This is all you need now! -->
	<context-param>
		<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
		<param-value>.xhtml</param-value>
	</context-param>
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>
 
	<!-- Weld Jetty Configuration parameters -->
	<listener>
		<listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
	</listener>
	<resource-env-ref>
		<description>Object factory for the CDI Bean Manager</description>
		<resource-env-ref-name>BeanManager</resource-env-ref-name>
		<resource-env-ref-type>javax.enterprise.inject.spi.BeanManager</resource-env-ref-type>
	</resource-env-ref>
</web-app>

beans.xml

In order to indicate to weld to initialize dependency injection, you’ll need to create an empty file named beans.xml. The mere presence of this file in your WEB-INF folder tells the container that your WEB-INF/classes folder is a bean deployment archive.

Application-Specific Code

HelloWorld.java

To confirm that Weld (A.K.A. JSR 299 or WebBeans) Dependency Injection works, we’re going to write an incredibly simple bean. In contrast to Spring, you don’t need to declare the package or bean. Simply adding the @Named annotations and declaring a scope is all that is needed to have your bean registered with the dependency injection container and visible to your facelets view pages.

package org.bogus;
 
import java.io.Serializable;
 
import javax.enterprise.context.SessionScoped;
import javax.inject.Named;
 
@Named //assigns this bean the name of "helloWorld"...its "de-caplitalized" class name
@SessionScoped  //creates one bean for each user session.
public class HelloWorld implements Serializable {
	private final String text = "Hello World!";
 
	public String getText() {
		return text;
	}
 
	private static final long serialVersionUID = 1L;
}

index.xhtml

Now we want to actually view the bean we created. Below is an incredibly simple xhtml/facelets page.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html">
<h:head>
	<title>JSF Demo</title>
</h:head>
<h:body>
	<h1>Does Weld Work?</h1>
	<!-- Your bean can be easily accessed via Expression Language -->
	<p>My weld-injected bean says: #{helloWorld.text}</p>
</h:body>
</html>

jetty-env.xml

Since we’re not using a full JEE container, we need to configure Jetty to prepare the BeanManager.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
   "http://jetty.mortbay.org/configure.dtd">
<Configure id="webAppCtx" class="org.mortbay.jetty.webapp.WebAppContext">
	<New id="appManager" class="org.mortbay.jetty.plus.naming.Resource">
		<Arg>
			<Ref id="webAppCtx" />
		</Arg>
		<Arg>BeanManager</Arg>
		<Arg>
			<New class="javax.naming.Reference">
				<Arg>javax.enterprise.inject.spi.BeanManager</Arg>
				<Arg>org.jboss.weld.resources.ManagerObjectFactory</Arg>
				<Arg />
			</New>
		</Arg>
	</New>
</Configure>

Start up Jetty

Jetty is an embedded servlet container that can be easily launched from Maven. Since we added that small snippet to the pom, we can simply type:

mvn war:inplace jetty:run

…and maven will download Jetty and run it with the configuration file we passed.

Test Your Application

Simply load http://localhost:8080/jsf/index.jsf

firefox http://localhost:8080/jsf/index.jsf

Screenshot of your application
If you see the hello world text, everything has worked. Now that you’ve confirmed your configuration is setup correctly, you can explore the more interesting features of Weld and JSF 2, which I’ll be covering in future posts.

Download the Code

The source code to this tutorial is available via subversion here

UPDATE: Tomcat Users

With the addition of a context.xml, this example runs perfectly on Tomcat.
Please see this article for details.

Further Reading

Many thanks to the JBoss staff on the forums who helped me get started in Weld. The artifacts in this article were modeled after their examples.

Duct Tape Programming: Macho?…Yes! Practical?…Rarely!

In http://www.joelonsoftware.com/items/2009/09/23.html, Joel Spolsky of the Joel on Software Blog advocates a practice he calls “Duct Tape Programming.” What he advocates actually is nothing new. It’s more commonly known as “Cowboy Coding.” I decided to post my response for public comment.

Joel’s article was amusing, but obviously balance is important.

I got the impression the Joel was rebelling against COM, C++, OOP, and general abstraction. I can’t say I personally share his view that complex technology is inherently bad. These features are sharp tools, much like the power tools today’s carpenter uses to build a house. Left in the hands of idiots, sharp tools cause problems. It doesn’t take too much imagination to see how assigning an idiot with a drinking problem and an addiction to cough syrup with the task of ripping boards (cutting lengthwise) with a table saw can cause problems. Likewise, letting someone write multi-threaded code who doesn’t have the skill necessary to handle it responsibly is a recipe for disaster.

Over-engineering is a serious threat to a business, especially since many engineers I have worked with can fairly be accused of over-engineering at some point or another in his or her career. However, there’s obviously a reason things like Object Oriented Programming exist… and it isn’t just because the entire software engineering profession isn’t as smart as Mr. Macho Duct Tape Cowboy.

Everyone reading this who has written code for a large company has seen what happens when duct tape programming gets taken too far.  You end up with a giant legacy system, written by two-dozen authors over multiple decades. The application performs poorly, is difficult to maintain, and no one has holistic knowledge of how the system works. You often find yourself spending 6 months training each engineer which touches the system on your internal proprietary duct tape patterns. Duct tape programming is fine and dandy until you ship something that’s broken or can’t be extended to fit your changing business needs — because it is a giant scary monolith and every simple change in one piece of functionality breaks another piece that was duct-taped on it 5 years ago.

OOP and standardization technologies that abstract complexity pay off when you have more developers that can fit comfortably in a small office and you realistically expect for a product to be handled in the future by people other than its original authors. They add complexity for the sake of compartmentalizing functionality so it can be distributed among different authors and can encourage documentation of the workings of each module.

My team pushes for modern standards and best practices so that we can hire a sharp developer who’s familiar with modern technology, and he can instantly understand most of what we’re doing. More often than not, we could have shipped whatever we were working on slightly faster if we ignored standardization and just did things the way we did them many years ago because it was familiar to us. However, the customer would pay the price when they asked someone other than us to maintain our quickly-shipped, duct-taped masterpiece.

Most professional developers write code for a company for the sake of delivering a quality application, a tool to enhance their business. You do the client no favor by saving them money on the initial delivery and costing them more down the road to keep the product running and relevant… unless you’re solely billing by the hour and are in a situation where they can never fire or sue you.

Clearly this is a complex problem that people are years from solving, but until the geniuses of the world get together and solve this once and for all, I personally think we’re best off balancing writing elegant, standards-compliant code with shipping things on time and not blindly adopting technology without fully understanding the consequences.

Grant Central is Here!

On Thursday, our team released Grant Central, a tool to help life sciences researchers find grant opportunities, identify new collaborators, and manage the grant application process. It’s one of the things, along with Clickframes, that we’ve been working on for most of 2009.

Here are the highlights:

  • Search through all US government grant opportunities for life sciences, including all HHS agencies, (including the National Institutes of Health and the Centers for Disease Control) as well as the Department of Defense and the National Science Foundation. Searches can be by keyword or award size.
  • Comment on grants, enabling a conversation across the Harvard community.
  • Query the Harvard faculty Profiles database for new collaborators and invite them to participate in a grant project.
  • Manage grant projects using the aptly-named “Projects” module. Projects allows you to track due dates, tasks and documents, as well as maintaining an online discussion forum for your grant project. Grant Central also allows users to manage their NIH Biosketches, Other Support Forms and Lab Information documents -  no more chasing them down the day before the proposal is due!

We’ll post more about it over the next week or two. You won’t be able to see the whole application if you don’t have a Harvard Medical School eCommons account, but you can still use the grant and collaborator search engines.

And if you’re interested in Grant Central for your own institution, drop us a note. The application was developed as part of Harvard Catalyst, the Harvard Clinical and Translational Science Center – if your institution has a CTSC, you can get Grant Central too.