What I mainly took away from that article is its primary subject: how the lack of any standards and ethics mean that software development is no profession; and that it is in our power, interest and responsibility to change that.

Which, as it happens, has a lot of overlap with lesscode.org’s mission.

Kevin:

It’s not compatible with my ideas of fun, productivity, and (in many cases) broad spiritual/ethical beliefs.

You will probably enjoy The Crooked Timber Of Software Development.

Those who can do a thing, do it. Those who can’t, manage.

At the core of the arguements is either “Your people should know what they’re doing. Hire good programmers and get good results.” versus “We want to engineer a process that takes the endless supply of cheaper codemonkeys and generates something usable.”.

Ironically, both of these are correct answers to different questions from different people.

Good programmers rarely can suffer working for someone who can’t do what they are capable of doing. Enumerate the possibilities.

• Management can’t understand what you do and doesn’t give you the support needed to exceed (Management into Oblivion). This is not sustainable because generally gifted programmers quit.

• Management can’t understand what you do but gives you the room and support to succeed (Effective Middlemen). This isn’t sustainable because eventually the programmer recognize the uselessness of their management and starts a startup.

• Management can understand what you do and manages effectively. Of course, in this situation, good programmers usually ARE the management (usually this is a startup).

Essentially, gifted programmers don’t work for corporate management types for long.

Conversely, these people (henceforthe referred to as “MBAs”, used pejoratively) are left to do what they can. Since your average codemonkey will waste his time humping a stupid project for a visionless manager, these same management-types ALWAYS get the best out of codemonkeys. It’s a self fulfilling prophecy. If you manage capable people so badly that they leave, you’ll naively believe that capable people are “unreliable” and that the less capable are suitable because they are replacable and that your “process” will make everything work anyways.

This article essentially says that the corporate management (MBA) mindset is not even close to the right way to solve the problem. It is correct.

The referenced article says that, within the context of being a corporate manager who is incapable of writing good code yourself (and thus managing people who can), this process takes low quality programmers and forces them to behave a little better. In this way, that article is correct as well.

The problem is not that these people don’t understand what solves a problem. Programmers write code because they want to solve problems. MBAs us to work in such a way as to enabling the mediocre to repeatedly succeed cheaply enough that the savings amortized over the lifetime of the enterprise offsets the loss expended to later achieve optimal solutions (the above Franchise Scenario). Business types have no problem with a net loss if the short term win keeps them in business.

I love how some respondents use the word “artist” as a pejorative. It’s kind of like the way certain people use the word “Republican”, “Democrat”, “Feminist”, “Management”, etc. Essentially its a way to appear polite when covertly signalling other people which share your lack of respect for your opposition. A way of coopting the naming of a thing to communicate disdain for it.

In this case, the implication is that caring about “design” or “craftsmanship” is impractical, or at least that a process can somehow make a solution “good enough”. This is, of course, classic code monkey / management groupthink–and it benefits both of them to feel that way. Of course, they may be right. Hiring good programmers is useless if you’re out of business.

That said, the mistake is to then blindly trust management to sort it out because “it’s their job”, which is ironic because they are least suited (well, they do wear suits) to make the calls necessary to design their products. In the end, I don’t even bother to explain it anymore. People who need to ask the question are already too far gone to affect. How do you explain to someone that quality companies are built on quality people? If you don’t understand, it will be up to repeated failures at the hands of quality people to teach you.

I’m afraid that the only way to solve this problem will be for engineers and programmers to systematically remove MBAs from companies by repeatedly founding valuable startups and dominate business with value. Don’t sell out. Be brutal in keeping your environment pure. You’ll have to spend generations draining the money from the MBA types, since their primary skill is retaining it.

The proof is in the pudding. MBAs pull the double whammy. They get to trade in the analysis of what is “valuable”. They get to turn real world situations into “valuations”. It is no surprise that they dominate management decisions when they are the ones that assign relative value. It’s no wonder they hijack control of business.

The market is more discerning than this. Just crank out good software at a fraction of the cost and work to destroy the credibility of the MBA (believe me, most of Wall Street, Tyco, Worldcom, and Enron have already gone a long way).

Along the way, it may be necessary to reclaim the courts and the government, but that’s another discussion… :)

Seriously though, I can only hope that real, honest-to-goodness MBAs can read this and appreciate what I’m saying. People in management are competitive. This competition becomes manipulative. It is a matter of ethics and responsibility for MBAs to keep reality in their numbers and work as a group to prevent those of their number from “minimizing” in these ways.

They have a profound effect on the market. They determine which languages get press and nourishment. Agile languages are supremely important regardless of the supply of programmers for them. If IBM wants Python or Ruby programmers, there will be Python or Ruby programmers. Don’t underestimate your role in this.

Realize that employees (good programmers in particular) aren’t just a “resource”, but more appropriately an “asset”. Realize that you are fooling yourself if you can’t see where good programmers fit into your balance sheet.

When hiring a cheap programmer or two in place of a good one, realize that you’re replacing an asset with a much less valuable one. It may look like you’ve saved if you don’t properly value the assets you’re trading…

It’s not compatible with my ideas of fun, productivity, and (in many cases) broad spiritual/ethical beliefs. I’ve worked at about twenty companies (salary and contract) over about 25 years. From banks and IBM to 3-person startups. I know what environments work best for me.

If you want to be a corporate coder, I have no problem with that. But the more shops that switch to an agile process, the more job opportunities that I would actually consider. Hence, my low-level advocacy for all things agile.

This turned out to be untrue. It was a surprise to me. I wanted to convince people in my previous situation what I learned.

Ah. That does put your article in quite a different light. I wish you had phrased it along the lines of this comment, though, that is, framed the Java = maintainable assertions as convictions rather than fact (even if only subversively ;-)). I don’t think I’d have taken issue at all in that case.

Brian, again:

The main problems are there’s no easy way to judge them, and you can’t hit deadlines with artists.

Careful: I don’t equate artists with great programmers. Great programmers are craftsmen and pragmatists. They may express themselves through their work, but they don’t do it to express themselves.

That said, it is true that they are hard to identify. The moral is probably that programmers need to be involved in the hiring process if you want to hire good programmers. I am reminded once more of things Paul Graham has said.

As for paradigm shifts, be sure not to miss Ben Tilly on Kuhn on Paradigm Shifts.

Tony:

Comparing 5 great coders to 1,000,000 “codemonkeys” is silly. Instead, compare the 5 great coders to 1 great coder (as tech lead) with 4 solid mid-level/junior programmers.

I’d rather have two great programmers than one great teach lead and 4 juniors. But that example doesn’t really highlight the point, because in small teams, the randomness factor is, as you say, large.

OTOH, a team of 30, consisting almost exclusively of mediocre programmers, is worth less than a team of only 5 developers who can hit the high notes. I’d rather spend the resources required up front to find a small number of excellent developers than burn a lot more resources, over the course of the project, on a huge team of monkeys.

So in the business reality where you have to hire some mid-level and junior-level coders (cause that’s all you can find/afford), what will help you succeed? Business systems and coding frameworks will!

Frameworks help; but they do only to the extent that they match the application’s requirements. The more specialised your needs, the more architecture you will be building outside the structure afforded by the framework.

The difference isn’t that the franchise businesses hire the absolute elite people in their field (usually the opposite is true). The different is that there is a system and framework that allows average people to produce above-average work (yet still command only an average salary).

I disagree that this is a good analogy. Franchises are not frameworks in the software sense. Franchises instruct you on how to execute basic tasks of business. A franchise business is a processor that runs a franchise business executable. A franchise plan is equivalent to an application in the software sense, not a framework.

In software, things written repeatedly by programmers will sooner or later be abstracted away. Following a fixed, repeatable plan for building software really means that you haven’t abstracted away enough yet. A competitor who does will eat your lunch.

Hence RoR: a software framework extracted from an application in order for the team behind it not to have to repeat the same work in the next application. Your claim that what I wrote amounts to “we don’t need Rails, we’ll just hire smart programmers” misses the mark completely and misstates the purpose of software frameworks. Those smart programmers will build a Rails of their own if they find themselves doing repeated work and a Rails does not yet exist. (And will choose to build upon Rails by themselves if they find themselves doing a lot of work which the use of Rails would preempt.)

Kragen has an excellent article on this issue in the pipeline. I hope he manages to finish and publish it, one day. :-)

Of course, the analogy to a franchise looks believable on the surface and appeals greatly to business types; no wonder middle management generally operates on the delusions it does.

Kragen:

I think that’s overstating the case.

So it is.

The problem I faced is that I saw no easy way to incorporate those nuances within the frame of the argument I was trying to present. They are why the published revision of the article does not simply state, as earlier versions did, that:

Comparatively, the chosen language is barely more than a neglibility.

but goes on to qualify:

assuming it has a good impendance match with the type of application being written.

I agree that even this insufficiently captures the points in question.

I had been wanting to discuss this in greater detail with you prior to publishing, but I didn’t know how to get hold of you and the article had already languished for such a long time that I decided to forge ahead anyway.

I hope that aspect doesn’t detract greatly from the overall argument.