The UNIX-HATERS Handbook is one of the most entertaining commentaries ever produced on our ability, as People Of Code, to confound ourselves with ad hoc cleverness. One of my favorite passages from that book [PDF] is about the difference between "you could do that" and the act of actually doing it:

Once we were talking to a Unix programmer
about how nice it would be to have a utility that could examine a
program and then answer questions such as: “What functions call function
foo?” or “Which functions modify the global variable bar?” He agreed that
it would be useful and then observed that, “You could write a program like

To be fair, the reason he said “You could write a program like that” instead
of actually writing the program is that some properties of the C language
and the Unix “Programming Environment” combine synergistically to
make writing such a utility a pain of epic proportion.
You may think we exaggerate, and that this utility could be easily implemented
by writing a number of small utility programs and then piping them
together, but we’re not, and it can’t.

Remembering that passage helps to keep me honest whenever I talk to developers, or the people who pay those developers, about the things that "you could do" with I vastly, enormously, totally prefer to cite examples of people who've actually done it: who've found it technically feasible, mission-relevant, and cost-effective to take something beyond the realm of the science project to use it in solving real problems.

My latest addition to my portfolio of "Yes They Did"s is OPENLANE Inc., whose use of we described last month, but which has now been independently explored and reported as well. I can tell you that ties things together even better than the tools that are offered by the people who sell those things, but it's far better to hear from a customer who's reported as saying things like:

"It really drastically reduced the time it took to go and change these processes," said Leslie Brownlie, senior product developer for Openlane. She said that because of's proprietary and streamlined codebase, which is based around tight integration with's online services, she could do seven or eight product releases a year with a minimum of headaches. She said it even let non-IT professionals safely dabble with the platform.

Brownlie said she found it hard to estimate the potential savings on development by using cloud services such as to knit together their in-house auction software and accounting software. She said it was, practically speaking, impossible to see doing it another way…

Key take-aways from this, it seems to me, include:

  • Superior solutions
  • Faster improvement and adaptation to new needs  
  • Closer coupling of the development process to the people who own the business problem 
  • Platform leverage benefits far outweighing lock-in concerns 

"Yes we can" is an inspiring statement, but "Yes we did" seems so much better. Real Programmers actually do it.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS