Real Ultimate Programming Power

Methodologies are for managers [grin].

Although it’s good that someone thinks about and formulates these principles, for the benefit of those who can appreciate them and maybe apply them, they are not meant for the masses.

The reality is that, in general, 20% of the programmers in a team produce 80% of the work. This is not always true, but it’s a frequent situation, because a lot of job interviewers are, um, tolerant.

What I mean is: The teamlead should at least be a person to get the team up to a certain acceptable level.

http://www.mellekoning.nl/index.php?entry=entry090107-162144

Your sort of whining is nearly as bad as those Christian groups that claim to be offended by the fact that Penthouse contains nudity.

Yeah it’s terrible that the white house contains nudity.

I believe in ONE rule/process/methodology:

  1. Hire good people.

If pressed very hard, I will also admit to being very fond of encapsulation.

@Dave:

And at that, I declare this thread dead (as far as I’m concerned.)

(Attention, Jeff Atwood: It would be a really fine idea to let us in on what the joke is supposed to be.)

One final ironic aspect to this. The link in this article to DRY actually points to an article on “Curley’s Law”. (So rules are a bad thing, but laws are fine?)

Here we find one of the main points of Curly’s Law is,

“Although Curly’s Law definitely applies to normalization and removing redundancies, Do One Thing is more nuanced than the various restatements of Do Each Thing Once outlined above. It runs deeper. Bob Martin refers to it as The Single Responsibility Principle:“

As this is the same principle that Jeff and Joel seemed to have the most problems with in the StackOverflow podcasts, I’m now officially confused, and am just going to assume this whole affair is just a massive troll.

Apologies for the previous comment. I’ve just checked the transcript of the podcast and realised that Jeff does admit to having linked to the Single Responsibility principle.

I’m still confused as to how you can get from DRY to SRP.

Seriously? You can’t understand why these principles/fads are developed, written, and codified into frightening management nightmares?
It’s easy.
Management wants it. Programmers want it. The ones reading them aren’t the ones expected to adopt the rules, they’re the ones expected to PROPAGATE the rules, in an effort to make those worse than them better in some measureable way.

As to the source of a lot of this: new design principles are necessary to improve the average quality of code worldwide. Hence object oriented design. They will, and should, continue to be created and evolved.
The danger comes from the 285 Rules of Acquisition, to stick to Jeff’s terminology. Object oriented design is fundamentally simple to explain and describe, even in great detail. But when given a large textbook on the subject, with hundreds of so-called rules that have nothing to do with OO except what’s in the author’s prejudiced experience, it can easily cause more harm than good. It certainly turns intelligent people away from programming (I’ve seen it happen many times).

Jeff has finally passed the plateau of a technical blogger and became an entertainer :slight_smile:

Best Practices and Methodologies are, just like the parties, designed for those who are not invited (read: can’t program no matter what you do to them :slight_smile:

I suggest you bring this stuff to Youtube.

What troubles me about most of this discussion is that the authors all have no doubt they are experts. When I see this I always worry about the central conclusion of the paper Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments. In summary it says, if you are no good at at an intellectual task you are likely to think you are better than average. If you are very good you are likely to underestimate your competence.

I think the point of NAMBLA in the list is to draw attention to the fact that people stop processing what you’re saying when you start using acronyms.

One of these things doesn’t belong:

  1. DRY = Don’t Repeat Yourself.
  2. KISS = Keep It Simple Stupid.
  3. YAGNI = You Aren’t Going To Need It.
  4. NAMBLA = North American Man/Boy Love Association.

I’m clear on what 1, 2, and 3 mean. I’m completely at a loss as to what you mean by including NAMBLA. Can I offer some possible explanations, and can you tell me which one is correct or at least close to being correct?

a. Jeff is a member of this group and has found that it increases his programming wisdom.

b. All other acronyms for other programming methodologies can be substituted with NAMBLA because those methodologies advocate homosexuality between men and boys.

c. Jeff is trying to lure his readers into a recursive and pointless discussion as to the meaning of NAMBLA as it relates to programming methodologies. His only purpose in this is to get a laugh out of all of the posts questioning the NAMBLA reference.

Jeff, am I at all close on any of these? Can you please help me connect the dots on your reference to this?

That was not a good joke to pull, the world doesn’t need jokes about pedophilia.

I’m just glad I knew what that acronym meant and didn’t click on it.

It woould be great to have time to read all the texts and keep up with them all. But there really are only a few fundamentals.

que bestera

This sounds very much like chess openings.

You have a million books and terms that you can throw at people and dazzle them. For instance, “to counter that knights offense, just use the black’s sicillian defense” could easily relate to “on this project I would only use DDD with an Agile Scrum master”. In the end these are just terms and words that have little to no meaning if even one person on your team does not understand them fully.

In the end it is all about being able to get the work done before the deadline with as few of bugs as possible. Like chess openings, it is important to know the fundamentals behind the opening. With these patterns it is important to know when to use them, what they are and what the cost is to apply them to your project.

Would you really use the four you listed on every single project that you do?

I personally feel that people should move away from these terms and get back to the core fundamentals. Gather requirements, design, storyboard, implement, test and rinse and repeat. It really does work.

Thanks, Jeff. I needed that. You really helped me snap out of it. In fact, just last night at 02:00 I had the Design Patterns book cracked and I was looking for just that right right pattern when I already had a working class with shared factory methods. No need for a singleton, no need for an abstract factory, YAGNI.

Again, thanks. :slight_smile:

I love links of london jewelry.More surprise! More fascination.The most elegant links are on show, Which will enhance your taste of fashion.
linksoflondon

It make me crazy.

Wow, you should look at how this post is formatted on your feed, especially at the end. Looks wacky.