Are OO skills important when someone has a good technical knowledge

[CPallini]

Joe Woodbury wrote:

You must work at Microsoft where the motto is; anything not done in COM isn't worth doing?

COM is quite outdated, even at Microsoft.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[Rama Krishna Vavilala]

CPallini wrote:

COM is quite outdated, even at Microsoft.

Really! How come most of the new windows 7 stuff is in COM: Jump lists, Ribbon, Direct Write, new Media APIs.

[CPallini]

Ah, OK: COM is the blazing MS technology of the moment! My bad: I supposed they blowing on the NET fire! :-D

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]

[R Giskard Reventlov]

The ability to get on with the job and produce solid, maintainable code is far more important than being able to articulate the ins and outs of OO or know all the latest buzz words or can decribe th einner workings of the 'Useless' pattern. Besides, most people wouldn't know or don't understand OO anyway: many of the companies I have worked at ask lots of questions about OO and patterns at interview but when you get to working they never use them anyway or the workers on the ground don't have a clue.

me, me, me

[Pete OHanlon]

There is a common myth that OO and patterns are inherently related, and knowing OO means you have to know patterns. This is a complete nonsense - a pattern is merely a fancy way of saying that somebody has solved a particular problem in a particular way. It's a formalisation of a recognised problem and solution, that's all - and it's perfectly possible to go through your career writing good solid code without having a clue about what a particular pattern is called. It's completely acceptable to be able to write code that reproduces the Chain of Responsibility pattern without knowing that's what it's called. Ultimately, if your code does what it's supposed to in an efficient and maintainable fashion, that's far more important. I'd be more concerned to find out if he understood techniques like composition and aggregation. It doesn't matter if he doesn't know what they are called - as long as he can explain the basic principles; and you'd find this out by giving him problems to solve that are best solved using the relevant techniques. It's disturbing that so many people are putting emphasis on coding skills, without realising that design skills are just as important for a developer. At some point, you have to come out from the code editor. A good coder must, at some point, be able to pull a design together - if you can't, you're just a code monkey.

"WPF has many lovers. It's a veritable porn star!" - Josh Smith

As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.

My blog | My articles | MoXAML PowerToys | Onyx

[KramII]

I can't agree. My view is that better design => more maintainable => lower LCO + rapid changes => happy customer. Design patterns are tried and trusted methods of solving certain classes of problem. They (1) help developers avoid reinventing the wheel (2) help developers avoid common design pitfalls and (3) provide us with a common lanuage and approach that aids communication - either through out code or when (and I have heard it happens) developers actually talk to each other. Each of these benefits should have a quantifiable (but not necessarily direct) benefit to our clients. Of course, design patterns are not a silver bullet, but they are a useful tool in out arsenal (or if you prefer: weapon in our toolkit).

KramII

[V 0]

note that I didn't say that design patterns aren't useful, on the contrary. as you said:

KramII wrote:

Design patterns are tried and trusted methods of solving certain classes of problem

but a client, in the end, wouldn't give a sh*t :-D.

V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive

[N a v a n e e t h]

Good one.

Navaneeth How to use google | Ask smart questions

[Deezos]

Couldn't agree more, you can't teach an old dog new tricks ;P

[KramII]

I misunderstood (and really must learn to read). You're quire right, of course. :-O

KramII

[Rajesh R Subramanian]

In that case, (on a serious note) you could refer him to me if you didn't happen to take him in. We are looking for C++ (on Windows) developers. :)

It is a crappy thing, but it's life -^ Carlo Pallini

[Moreno Airoldi]

Well IMO it strongly depends on the project and on the role the guy will play. If you are designing a framework and need an immediatey productive high-level coder, then OO practices will sure be mandatory. On the other hand, if your project does not have such specific requirements, I think he will do more than fine.

2+2=5 for very large amounts of 2 (always loved that one hehe!)

[Gary Wheeler]

Hmm. I'm old enough that my formal academic training predates both object-oriented programming and the notion of design patterns. As I see it, OOP and design patterns formalized and documented practices that more capable and experienced programmers used to develop reliable, maintainable software. I picked up a lot of these practices over the years through solving my own problems and by looking at the code of others. I've seen great object-oriented code written in assembly language. I've seen abominations written in C++ and C# that ostentatiously applied design patterns. I think it's important, perhaps vital, that you understand the ideas behind object-oriented programming and design patterns. Being able to recite pseudo-code for the Observer pattern, or to diagram a design using UML, is less critical.

Software Zen: delete this;

[LenaBr]

However - those of us with over 30 years of programming experience - haven't got the the buzz words. I have to bone up on those damn things every time I need to talk to clients. I had no problem learning the OOP style of programming - (I had been trying to program that way for 25 years without the support of the languages) however I had a hard time beating my way through the f...ing terminology. And design patterns ... It is called programming skills.

[Lost User]

I used to write design patterns without knowing that there was a pattern for that I think you should hire that guy If he is so good, he is not gonna have trouble learning design patterns But if you hire him, you should give him some homework (read the entire Gamma book). You people has no problem if they have to do something for work at home if they think that is a good thing.

Saludos!! ____Juan

[CurtainDog]

I couldn't disagree more. There are those who grok OO and those who don't. No matter how much you can teach someone the theory of OO if they don't get it they're never going to apply it well if you force it upon them. This should in no way be taken as a judgement on a person's programming ability, you can write fantastic code in a non-OO manner. It's just a culture thing, and having a few dissenting voices in the team may not be such a bad thing depending on your style. Me? I don't get RDMSs. I can use them well enough, but they always seem somewhat arbitary to me. I don't think I'd get along (coding-wise) with someone who tried to use tables for everything for example.

[Steve Naidamast]

In terms of OO skills, one should be competent at writing classes with a good understanding about OO concepts. However, remember OO is a concept. It is also a concept that has been proven over the years to be an utter failure which SOA has already begun to mimic. OO has not been failure because of what it is but how it has been applied. Its most touted feature has been that of re-use but an in-depth study in this area (Unfortunately, I can't remember the paper...) has demonstrated that re-use after all these years has been dismally, almost nill except at the small group level. Inheritance, which is another touted feature has been touted as the second coming in programming panaceas. Nothing could be further from the truth. Most inheritance hierarchies have been a nightmare to develop and even worse to maintain. It has very little real use in business applications except in specific cases. Ted Patton, of COM\COM+ fame in his second book on the subject described the nightmarish results of the over enthusiastic use of inheritance hierarchies. Most are poorly designed and subsequently produce maintenance fiascoes. Design Patterns are solutions looking for problems. This is not to say they do not serve a purpose but how many people develop projects looking for the proper design pattern to implement first... Not many. Though in some cases it would serve them well if they had. The reason is that design patterns are natural outgrowths as to how most of us as developers think when designing processes. we don't think about using an MVC for example, but many of us implement some level of MVC in many of our projects. Design patterns are best used when used as a guide for particular types of processes but when you start limiting yourself to that type of thought you become very narrowly focused. So how do you look at all this? OO is about one thing only! Organization and encapsulation of both data and logic. This is where OO truly shines way beyond procedural programming. However, it comes at a cost since most OO is not very efficient internally, especially when using polymorphism. It also can lead to as much confusion when written in esoteric fashion as any other programming language construct. I have been in the field over 35 years and still going quite strong at it as a senior software engineer. Everything has its place and its good points but putting too much emphasis on concepts and not enough on the natural abilities of the candidates you interview will have you always looking for the wro

[Rama Krishna Vavilala]

LenaBr wrote:

I had no problem learning the OOP style of programming

... and that's what is more important as I said. An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.

[Rajesh R Subramanian]

Rama Krishna Vavilala wrote:

An experience developer comes up with solutions automatically without reading about them. He may design using IOC pattern without knowing that whatever he designed is called IOC.

Somehow, I missed it in your previous post. Now, it all makes perfect sense. :)

It is a crappy thing, but it's life -^ Carlo Pallini

[Jordan Marr]

He knows how to use interfaces but doesn't understand OOP? I say go for it if he has the experience to back him up. It sounds like you're not looking for a lead programmer, which makes it even more of a moot point. On a side note... When it comes to design patterns, most people are thinking of GoF, but I think that Martin Fowler's PoEAA is much more applicable for the kind of software I am usually hired to write. The next time I am asked to name some design patterns at an interview, my response will be "Repository, MVP, Domain Model, Layer Super Type, Lazy Load, IoC, Plugin, Etc...." Those are patterns I actually use. It seems like a lot of the GoF patterns have been implemented (at least in Visual Studio) in Microsoft's own way. For example, observer is baked into the event keyword. Bridging a base class is as simple as using the built-in refactor tools. Iterator is baked into the foreach keyword. Factory / strategy can both be done using other techniques, and it usually boils down to preference. (MS tends to promote using ctors instead of factories when possible to keep code more readable anyway). If I was writing an OS, or a development lanuguage, or some manufacturing software, I might get some good usage out of the GoF stuff. But for business programming, PoEAA all the way, since it builds on the GoF patterns and makes them more relevant to my problem domain. Jordan