Just one guy's opinion that I had a read through earlier. He goes onto mention UML and patterns which I know some of you do, and I know Karl does as well as I work with him. I'm sure you'll all love to pull apart this guy's notions, and maybe infuriate you along the way. Who knows!

Article: http://damienkatz.net/2006/05/signs_..._c.html?repeat

He doesn't seem to like patterns at all. Perhaps the guy has never found it particularly odd that editing a system he's coded has taken much longer than normal. Perhaps he's not even coded a large system in his time as a programmer.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

I do agree that you shouldn't have a force a particular pattern to a problem if it doesn't fit. But I do find it stupid how he mentions that the developer should feel stupid when he's forced to implement a pattern.

But I do believe that UML diagrams help. Not to mention their a great source of documentation. :)

I don't have tons of experience as a developer, but I'm trying. :)

I'm sorry, I usually try to be more reserved but this guys comes across as an idiot. He's basically denouncing advanced methodologies.

Let me guess, he's the sort of guy to just start coding a large project without a thought of design. He's either completely ignorant or he's never actually worked on a project large enough.

One point that really annoyed me was his jab at design patterns, does the guy even know what a design pattern is? He says "every time you are forced to code up another design pattern, it means you are doing busy work that makes things more complex and is of dubious benefit.", again, has he ever bothered to learn patterns? Does he not realise that:

First of all patterns exist whether you know it or not, chances are, that guy uses patterns and doesn't even know. Secondly, patterns generally present themselves naturally, it's up to the programmer to realise when they appear and to take the opportunity to implement the correct solution.

Ignoring patterns can only have negative repercussions, it's like throwing your hands up and saying, I know this has been done before, but I don't care, I'll do it again rather than trying to reuse something done previously. If he likes to waste his time, so be it.

This point ties in with both patterns and UML: If the guy did any actual reading on object design he would realise that you can acutally "design by patterns". That is the process of looking for the top-most pattern and creating other patterns based on the context of that pattern. This, like CVA (Commonality and Variability analysis) are just just some of the many ways to help in object design. As for the UML, you'd need to use UML to model the conceptual view of your system, detailing how all the elements of the system interact. Not knowing how your objects are going to interact is just plain bad design, not to mention programming.

Finally, a really good reason for using patterns is that it allows you to discuss your code easily with other developers (just as UML allows you to easily model your system). A good example is if someone asked you to explain a piece of code (say, code that uses a strategy pattern - but you don't know patterns): "I first create a property for storing the behavior of the class, then I'll create two separate classes based on an interface which I'll call..." or if I know patterns, I can simply say "I'll implement a strategy pattern". I know what I'd say if someone asked me to explain that code. If someone tried explaining code to me like the former, I'd tell them to sod off.

I'm going to have to stop there and do some work or Adam won't permit me any food tonight :(

__________________
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Easy tiger! I knew you were likely to pop-up with some remonstration, but steady. Retract your claws. I do agree though, although I'm not as up with patterns and UML as you, he did appear to be speaking a load of babble. It also got torn to pieces on Digg - people saying he wasn't even giving any justification or reasoning for his clearly unsubstantiated claims. I'm sure we could all blurt out lots of random notions based on feeling and not reason.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

Guy is an interesting one. Lots of text and so little useful thoughts. Fighting against UML, DP, OOP is almost as fighting with evolution. It's impossible to avoid it, but you can contribute. Rather being such cynic he introduced a healthy critic and solutions.

Many folks are using AOP (http://en.wikipedia.org/wiki/Aspect-...ed_programming) but they don't publish such crap.

After reading the article, I understand that I'm "crappy" coder but I'm good developer and all those stuff really helps!!!

__________________
Never trust anything that can think for itself if you can't see where it keeps its brain.
©J. K. Rowling

karl i agree 100%.

I found the opening line quite funny:
he just described himself from what i can tell.

He CLEARLY hasnt designed ANY form of software bigger than hello world, otherwise he would know that design patterns and UML help alot.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

he had a couple good points but more seemed way out in left field. I agree different languages are better at different things that one probably made the most sense. But the UML, Patterns and Copy Paste is bull. UML is needed in any large project as stated above.. Patterns help simplify not complicate. and copy paste is always your friend, programming or not.

__________________
iSearchNotes.com - Share College Student Notes | Blog

UML I've found saves a lot of time as well. You can begin to visualise everything before you even create your first PHP document. You've got it all down in a document on how it all works and you've cleared up any issues that were identified in your proposed implementation. That way once you've ironed out all the creases, you won't have to start editing your code, although there will always be times mid-code where you realise something can be done better and more efficiently.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

hahaha, i love that list :)