Software Developer Meat Market

An interesting article in Forbes about Software Developers and Development in general, The Rise of Developeronomics. While here and there he is promoting old chestnuts which may or may not be true there is a core argument which is quite intriguing. It goes something like this:

1. All companies are becoming software companies, meaning they are driven by software whatever their business actually is.
2. Hence a key resource to a successful business is an effective, efficient and scalable capability to create innovative computer driven systems. Programmers are scarce.
3. Hence the way to invest in the future is to cultivate great and excellent developers who believe in you, are willing to follow your vision and will commit to your projects.

Sometimes I wonder whether business writers come up with a two paragraph insight or story idea and bulk it up into a 3 page article, or whether I am just not appreciating their craft. In any event, Venkatesh Rao writes:

"Investing in good developers is such a good bet at the moment, that if you have money and you happen to find a talented developer who seems to like you and wants to work with you, you should give him/her your money to build something, anything, even if you have no really good product ideas (those are cheap; I’ll sell you a dozen for a dollar)." (from The Rise of Developeronomics)

Wow. And a little further on he warns:

"In what follows, I am deliberately going to talk about the developers like they are products in a meat market. For practical purposes, they are, since the vast majority of them haven’t found a way to use their own scarcity to their advantage. Which means others find a way to do so. In capitalism, every human is either a capitalist, somebody else’s capital, or economically worthless. Today, this abstract point specifically translates to: people who can invest in developers, developers, and everybody else. (from The Rise of Developeronomics)

Read the whole of The Rise of Developeronomics.

Is your software developer any good?

Are you thinking about hiring a software developer to build your system? Here are "8 Things You Ought to Know If You Do Not Know Anything About Hiring a Software Developer". He says:

"I did not come to this industry with a software background. I studied math, physics, business, then finance. But over the past 12 years or so, I have learned quite a bit about how to pick a software... “friend”. So let me share with you 8 things I would want to know if I was starting afresh." (from "8 Things You Ought to Know If You Do Not Know Anything About Hiring a Software Developer")

Can I be your friend?

Customer vs. Consultant: Excellent advice

From an article called "Effective Customer Consultant Relationships":

"As a customer, how can you get the most out of your consultants? As a consultant, how can you deliver what your customers really want? I have been on both sides of this relationship and experienced both successful and unsuccessful results. In this post, I will go through the typical aspects of these types of relationships and identify action items that I have used to forge effective and lasting customer consultant relationships for both parties." (from "Effective Customer Consultant Relationships")

If you are a tech consultant or are thinking of hiring one, this article has some excellent advice.

Designed As Designer

If you are interested in design and especially design and architecture of software, and you have a philosophical bent, you will enjoy this essay… I can't even attempt to summarize it's content, and even the abstract from the paper itself is quite inscrutable:

"Conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the thing designed itself." (From Designed As Designer)

What can I tell you. The author is the Richard Gabriel, a luminary of the computer world. Here's the article: Designed as Designer.

How do you feel about Software Patents?

I am not dead set against software patents, although I've been on both sides of the issue.

I am the proud inventor listed on 3 or 4 patents. Some are more worthy in my opinion that others. I was also leading a development team that had to stand on its head to avoid conflicting with a patent that everyone agreed should never have issued, but we didn't have the nerve or resources to contest.

So I was interested to see some behind the veil of "Intellectual Ventures", Nathan Myhrvold's IP/Patent company:

"…But IV is not buying inventions. It's buying patents. And most software engineers will tell you, at least when it comes to software, a patent and an invention are not the same. Lots of patents cover things that people who write software for a living wouldn't consider inventions at all… (from When Patents Attack)

Good e-book about software pricing

Pricing software is a perennial challenge. I came across this ebook, "Don't just roll the dice" by Neil Davidson. It's a very nice introduction to a tricky topic. I am considering a major revamp of the BlogBridge web site, with pricing and feature changes and this guide helps me think through those questions.

Is Software Eating the World

Marc Andreeson has a really good, optimistic article in the Wall Street Journal about the future foundational role of Software in all industries of the world's economy:

"[…snip]Finally, the new companies need to prove their worth. They need to build strong cultures, delight their customers, establish their own competitive advantages and, yes, justify their rising valuations. No one should expect building a new high-growth, software-powered company in an established industry to be easy. It's brutally difficult.

I'm privileged to work with some of the best of the new breed of software companies, and I can tell you they're really good at what they do. If they perform to my and others' expectations, they are going to be highly valuable cornerstone companies in the global economy, eating markets far larger than the technology industry has historically been able to pursue.

Instead of constantly questioning their valuations, let's seek to understand how the new generation of technology companies are doing what they do, what the broader consequences are for businesses and the economy and what we can collectively do to expand the number of innovative new software companies created in the U.S. and around the world.

That's the big opportunity. I know where I'm putting my money. […end snip]" (from Wall Street Journal)

A fine article. One thing that does go through my mind is that even though he cites opportunity after opportunity in the full article, my observation is that it is quite hard nowadays to get people to pay for software in any form. We've gotten used to free, even in the enterprise. Yes some do succeed, big, but many many do not make it.

You must have a deep, illogical, passionate belief in your company and then you have to actually be really really good at execution.

A great article about scientific discourse

This article is called "Fact and Folklore In Software Engineering" and while it is about that, the part that was more interesting to me was the first section talking about Scientific Discourse:

"This article is about why some “facts” refuse to die, and about how to avoid being fooled by opinion disguised as scientific “fact”. We start, therefore, with some observations on science and facts." (from "Fact and Folklore In Software Engineering")

Here he goes on to describe "The messy workings of scientific discourse". It's clarifying explanation of a process that we understand intuitively but actually has a rigorous process:

"Bruno Latour is one of the keenest observers I know of the work that scientists really do, and one of the most punctilious in clearing away the myths and misconceptions about how science is in fact done. I have found good use in some of the tools he created to assess the status of an ongoingdebate about a matter that falls within the purview of science, one that hasn’t been settled - what he calls a controversy." (from "Fact and Folklore In Software Engineering")

After lots of further interesting detail about this idea, he finally comes back to the question: "So what is known about programmer productivity?":

"We can now circle back to this widely circulated “fact” of the software profession, according to which “programmer productivity varies by a factor of 10 (or 5, or 20) between the best and worst individuals”. This is a remarkable statement, not least because of its implications: for instance, programmer compensation does not vary accordingly." (from "Fact and Folklore In Software Engineering")

After this introduction he goes on to thoroughly take apart this concept as nothing more than unsubstantiated, oft-repeated folklore, based in some really old, actually inapplicable, and incorrectly cited studies.

But they stick because there is a grain of truth in them. The problem is that it's just a grain of truth. It's a wonderful article. Read "Fact and Folklore In Software.