The Ferengi Programmer

@Jeff R.
In practice, that often means throwing out a whole lot of things I really want to do, like unit testing.

I know it sounds counter-intuitive, but you will find that you are more productive writing unit tests than not. You need to get the hang of it first (it takes about a week, IME), and to pick your time. You shouldn’t bother with the UI (there are better tools for testing that), although you can test UI logic if you package it up right. You won’t be able to test report layouts very easily either, and you shouldn’t test 3rd party code (assume that database, 3rd party library, etc works).

When you next have to write something with a bit of logic, give it a try. You don’t have to tell managers and clients everything :wink:

@Desmond
It’s nice to see satire in action :slight_smile:

Are we forgetting the most important rule. KISS. If we keep complexity at its lower limits, our code will be both easier to maintain and run more efficient. I have seen OO designs that would have worked better as procedural code. There are other times where OO reduces complexity. There is spaghetti code out there that works wonders(just don’t try to reuse). Whatever it take to Keep It Simple Stupid.

It’s a great idea but, there are always self important fools who think that they have to do something to help out the future generations when the best thing to do in most cases, is nothing at all.

Although geared more towards politics, this argument fits. Jefferson said it best: the government that governs best, governs the least .

Too bad there are self important fools in EVERY field of practice.

I went crosseyed trying to read that list.

Interesting, V, that:

Ferengi in Hindi means white guy.

Also, in Ethiopian Amharic, Ferenge means foreigner but colloquially, white guy.

If we reached the point where programmers relied so heavily on rules that it hindered their ability to code, then yes, we would have a serious problem on our hands.

The problem is that this scenario is so laughably far from the reality of what average programmers are like that I wonder if Jeff and Joel are secretly just messing with us to see how much commotion they can stir up.

If anything, we should be encouraging developers to think more about their code and abide by some sort of best practices.

Man, you are misleading a lot of young software developers who read your blogs for advice. You can’t be so irresponsible.

This blog should be condensed to this. The rest was blah, blah, blah. Your getting better talking about useless crap though.

Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substitute for thinking critically about your work.

I get what you’re saying here, but I don’t think it’s coming across quite right. Rules, patterns, etc, are still excellent things to learn and practice. Certainly don’t follow them because you’re supposed to, but because they make sense to.

A programmer might have 90% of the thought in their head and knowing about some of these proven techniques may complete that other 10% of the puzzle. Understanding techniques can save you a poop-ton of work before you code yourself in to a deep hole.

The point I think you’re trying to make is to use your head. Make good decisions. Make educated decisions. Do what’s right for the given situation.

Sheer ignorance.

What makes someone articulate on things like use this pattern, or follow this guideline? Some have pure thoughts, others have hidden agendas, but it all comes down to passion for their work. So having said that, let’s just let everyone express themselves and be grateful we have access to all these readings. Problem is when software houses enforce these insights as rules upon developers. It’s the failure to understand, yes that OOP is nice stuff, but can it give me that 100% CPU performance I’m looking for? Or maybe, you’re not concerned about performance but things like versioning and code reusability. Perhaps, both! Costs, schedules, discipline also get involved to make matters worse. But one must realise there are so many possibilities (a.k.a. real-world scenarios) that it would be naive to put them under a single faith.
On the other hand, the… rely-on-the-team-of-super-experienced-programmers-only is so disconcerting. There has to be another way, and there is… become a plumber!

No wonder the Java and Ruby communities think we’re idiots!

Cowboyism strikes again. Have fun leading your little horde of outlaws, Jeff.

I value the skills, experience, and judgment of my team far more than any static set of rules

Seems shocking to me, that Jeff and Joel continue to absolve themselves while still clearly illustrating that they don’t understand anything about SOLID. Not even that they are simply guiding principles.

SOLID principles are not a static set of rules. Jeff’s continued ignorance in the face of learning is annoying and damaging to the community.

Please have the basic discipline to actually learn what you are arguing against before you describe it falsely and then shoot it down. Please also check out what is a ‘Straw Man’ debate tactic - it’s clearly your favorite device.

But slavishly following the no rules mantra is also a path to failure.

I’ll tell you one thing, the Gang of Four book is probably one of my most disappointing programming reads of all time. Completely useless to me. Strange that I can have a successful programming career without understanding that book…

Oh and Scott Ambler blows too.

Yes, strict adherence to the rules is like filling your garage with a huge number of shiny power-tools. Then, for every project you do, you feel obligated to make use of all of the tools you have, in order to justify them. That’s work for a few huge projects, but how do you use a nail gun when hanging curtains? Sweeping up leaves?

Extreme behavior begets extreme results. :slight_smile:

Paul.

I completely agree with this post. You summed up my thoughts exactly. Strict software development methodologies are an attempt to guarantee good software using (good|bad|random) programmers.

For me, the most valuable thing a methodology offers is a common vocabulary for a team to use, so that it’s easier to communicate as you solve programming problems. Beyond that, it’s just one of a million different ways that code could be designed and written.

The only true indicator of success is the quality of your people. Hire really smart coders and don’t constrain them any more than necessary.

I see these object oriented rules as guidelines for my design. Obviously there are some that will be followed (I’d be stupid not to) and others that won’t be followed.

There’s nothing objectionable about his principles, you say? I can’t be bothered to find out, mainly because there’s something very objectionable about presenting anything as big lists of individual PDF files.