Real Ultimate Programming Power

blog
21

You’re kidding right? I LOVE programming, I love learning about design patterns and structure methodologies. But, my cranial RAM is full! I’m still trying to cache something…anything to my mental hard drive that I’ve learned over the last year!

WPF, Silverlight, SQL 200X, RAD, SCRUM, Agile, NUnit, TortiseSVN, TFS, VS 200X, AJAX, Javascript, HTML X.X, CSS X.X, PHP, C# X.X, .Net X.X …duh…the list goes on and on.

All this progress is cute but I can’t keep up…oh…wait a sec…thank you God, I think I’m having a heart attack.

Goodbye cruel world!

22

This is probably not the entirely appropriate forum for this rant, but I wrote it already…

Good point, I suppose. But for example, I find it interesting that after the brouhaha of stackoverflow # 38 (or whichever one it was), when you guys invited the fellow you criticized on the show…you would think that he would have come equipped with some decent examples, case studies, or…something. I thought Joel was extremely restrained during the interview, because at least for me, I totally didn’t see his point. His appearance only solidified my belief that joel is more correct on this particular subject.

Look at the history of software, methodolgies, etc… AT LEAST 50% of it is either useless, self serving, or of no productive consequence, but when you dare criticize a methodology, the proponents act as if you are trying to stifle innovation. Where is the intellectual humility on behalf of the proponents of the new methodologies? And, when you are given massive exposure on a popular blog/podcast, and you can’t find a remotely real world applicable example of why I should take your methodolgy seriously, you call me uninformed?

If I have a task to implement at work, I can write it with my present skills, it will work for years, and when a junior programmer comes along, they can figure it out. Following some of these new and better programs, it takes me hours to sort through how to disconnect from all the other objects, and no one will ever be able to figure it out.

I think Joel is EXACTLY right, I think these advocates are full of it. He can’t really say it now, but I will restate what he said…I don’t think these people write code day in day out. They live in a little fantasy land. They come up with their schemes in an environment where all the developers are hardcore and totally up on the latest design. Well, in the real world, everyone isn’t. And who knows what developers will know 10 years from now. In the real world, designs and patterns come and go. But common sense doesn’t. How about simple? I could show you code from the Thoughtworks drones that should be f*cking illegal. I’ve personally ripped out their crap and reimplemented smaller, simpler, faster, and more functional, with 70% less code.

I just don’t buy the snake oil you guys are selling. (This is directed to the guy Joel hacked on.)

23

So I guess we should stick to the 1969 structured programming then (or even something before that), since everything that came after is just too complicated to fit your sheet of paper definition. Objects, inheritance, encapsulation, overloading, interfaces, delegates, lambda expressions etc. - I could argue (using your 4 rules) these are all unnecessary since you can achieve DRY, KISS, YAGNI with simple plain old C

24

I dunno what Jeff’s trying to get at. But it seems to me that his three principles don’t mean that you ignore all the other stuff out there – just that those three are the core.

To my eye, SOLID consists of one iron-clad principle of OOP (LSP) and four great patterns for OOP development. But I have a huge problem with treating those other four as if they are the core of OOP, because they are only great patterns when applied sensibly, and the way I’m seeing SOLID presented suggests they should always be used.

For instance, I’m looking at the world’s simplest Hello World class / program, and thinking that if you took SOLID seriously you’d be required to rewrite it as four classes/interfaces. (Because the two pieces of functionality – marking the main entrance to the program and printing a message – should be separated into two classes under SRP, and then each of those classes should have an abstract interface and a concrete implementation under DIP. Actually, I can even see an argument it should be six classes…)

That is to say, the SO/ID parts of SOLID are at war with KISS/YAGNI. And personally, I think KISS/YAGNI is the clear winner: you shouldn’t be pulling in all that abstraction unless you actually need it. When you need it, abstraction is the greatest thing ever, but when you don’t, it just makes your code needlessly complex.

25

NAMBLA interpretation: NAMBLA references are jokes, Jeffs Ultimate Whatever is a joke name, some people do not get the joke. Even though its a joke, it doesn’t mean the whole post is a joke.

26

I believe Jeff totally misunderstood the motivation for many of the fancy methodologies like RUP: it’s not to make great programmers greater, but to reach the people who are not interested in improving their programming skills, not through marketing, but through simple coercion.

The idea is that a methodology like RUP, if allows a large organization with a mix of competent and incompetent programmers to have the incompetent ones be productive by establishing clear rules about who has to do what, and how to cope with problems that arise.

It’s certainly arguable whether this works as well as the proponents imagine, but it’s at least a constructive idea of how to deal with the situation of many large organizations DO have lots of marginally competent programmers and DON’T really have the option of firing them all and hiring only competent ones.

27

The software engineer should have as a minimum:

  1. Membership of a society-wide accepted professional institution that is the governing body of professional software engineering standards, status and awards.

  2. A computer science degree with a minimum of 25% mathematical (pure and applied) content acceptable to the above institution.

28

He IS the Messiah!

29

In my software engineering class I learn about all those methodologies and metrics. Then we go and do not ever use them again (heck we didn’t even used in the first place, we only learned how it worked) in our entire academic life.

90% of my colleagues HATE software engineering class, there is simply too much information that we don’t apply anywhere, Most only get all the slides the professor use one day before the test and study like hell.

Maybe if software engineering wasn’t so boring we could have more interested people

30

The difference between rules you provide and people really thinking about software design is that they aren’t substantive.

It’s not that it isn’t bad general advice. But what is worse is that you appear to think it is a substitute for attempting to codify good practice in a reusable way.

Who cares necessarily what the bad programmers are going to do, they’re going to copy other peoples code anyhow - and aren’t going to be helped by you.

But regarding the harm of rules… codification of good practice happens all the time. It’s obviously part of programming language development, we’re not just doing loads and stores to registers and memory and doing maths operations on them.

The irony is that you sound similar to a hardcore assembler programmer 25 years ago. Don’t use C you’ll stop thinking about the code!

31

I laugh! And it is funny because it is true!

It is a bit sad too, as there has to be a few more cold hard truths out there, but you certainly have to wade through some deep sewers to find them these days.

But that is not important right now - I want to start the first ARSUPP (Atwood Real System of Ultimate Programming Power) training center in my region. I expect I first need to pass the 8 week ARSE (Atwood Real System Engineer) training, so where do I sign up?

:wink:

32

Sorry, what’s the NAMBLA supposed to represent? Just a joke? Or something along the lines of:

Just like NAMBLA can, and has the right to, attempt to legalise sex between adult and minor males. Similarly zealots and marketeers have the right to advertise their version of The Methodology. But in both cases you still have to use your own judgement and make your own decision about going along or not?

33

Brilliant reposte, Jeff. Couldn’t agree with you more :slight_smile:

34

But here’s the paradox: the types of programmers who would most benefit from these guidelines, rules, principles, and checklists are the least likely to read and follow them.

Well let’s take building for example: the types of [worker] who would most benefit from these guidelines, rules, principles, and checklists [for building houses] are the least likely to read and follow them.

So what you are saying ? That those that are not knowledgeable enought in X would have most benefit in learning X ? That just seems common sense to me.
So little value you are providing there.

It’s no coincidence that a lot of the proponents of these methodologies make their living consulting and teaching about them.
And exactly how is this different from you proposing us your visions about sw development on your blog and making money from that ?

Remind me again – who, exactly, are we writing these principles, rules, guidelines, and methodologies for? If we’re only reaching the programmers who are thoughtful enough to care about their work in the first place, what have we truly accomplished?

Let’s try mathematics this time. Are you saying that mathematical discoveries shouldn’t be written in books because they would make sense only to Ph.D of mathematical science ?

Sorry, but seems like another non quality post on otherwise very good blog.

35

Above, you quote Jef R who was replying my question, which remains unanswered.

I am astonished that you seemed have missed, possibly deliberately, that SOLID is about design! I also have noticed, some other posters here dont seem to have, that you have subtly changed your line of argument from :

podcast : agile is a waste of time, you don’t need it
ferengi : solid is bureaucratic
this one : no point trying to improve programming technique as most people listening

This aside, can some please reply to my original question:

Could someone who actually agrees with this post, please give a non-trivial example of how not adhering to any of the SOLID principles leads to a better design?

36

I think that ignorance is only a small part of the cause of the problem, and making the case that software developers simply needs to be educated is a convenient and simplified view.

Software developers might make an active choice not to use any principles/methods/methodologies, but instead go for the cowboy quick-n-dirty style.

Why?

In many cases the goal of software development is as simple as:

  1. Make it work
  2. Do it as quickly as possible

A lot of companies today don’t compete on quality or durability. Quite the opposite actually, the biggest and most successful companies seems not to care so much about quality, and rather compete on other means. Such as low prices, aggressive marketing etc.

Why and how would the software industry to be an exception from these market forces?

37

R. Lee Ermey…

This is my keyboard. There are many like it but this one is mine.

38

The Rational Unified Process was invented long before 2003 - I can remember using it in the late 90’s.

39

Sorry, Jeff. You just don’t seem to get it. And neither do a lot of your readers.

SOLID is not a set of commandments about how to write software. SOLID is about gaining an understanding about what makes an object-oriented design a good one. I agree with DRY, YAGNI, and KISS, but these ideas don’t give you any guidance about how to design your class structures.

So what happens when you sit down and try to write code? Re-listen to the Hanselminutes podcast where Bob is talking about the LSP, and he gives the classic example of the Rectangle vs. Square class design. Nothing in DRY, YAGNI, or KISS will guide you in any way about how to create your classes here. The LSP (The L in SOLID) gives us a really good way of thinking about how we might design these classes, and also gives us a reason other than well, it felt like the right design at the time. This, then, is the true value of a set of principles like SOLID.

These principles become more important as the importance and visibility of the software you write rises. So if you’re publishing an API for other programmers, either in a large team or publicly, non-SOLID based object structures are visible to few people. Sure, you may find yourself having to spend a bit more extra time changing your code, but that doesn’t matter as long as you or your one or two team members are the only ones making the sausage. I suspect this is where your (and Joel’s) lack of understanding of the principles stem from.

Let’s face it, SOLID is getting criticism from a guy who made his own language to wrap classic ASP, and whose company is now stuck with it. That’s hardly a sign of someone who cares about the ability of other people to work with his code.

Now it’s time to hold up the mirror, folks. Which ones of you who are criticizing Bob Martin and SOLID have written public object-oriented APIs, used by many people? Code bases to be used by many people in your team? Code that can be extended without having to be changed? Then you’re probably getting away with ignoring these principles.

Just understand that getting away with coding something and having it work is not the same as writing good code. Thinking about coding is not the same as writing good code, either.

40

I don’t like the NAMBLA joke. It’s like if you ask about NAMBLA then you belongs to that group, the unenlightened mass. Questions are the most important thing in our society.

Or is it joke about abbreviations? If it is, then you do not understand abstractions. And that is a crime.

Please, do not make me research unimportant things on the internet. And do not try to make me laugh!