Are OO skills important when someone has a good technical knowledge
-
KramII wrote:
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).
Lot of feel good words. Which could be applied to anything at all. The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern. And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs. There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction. Patterns are quantification of common practices that existed before the term "pattern" existed. And good programmers (presumably) created them without knowing either the names or attributes of them.
...which could be applied to anything at all.
I'm not sure what you mean. They certainly wouldn't to the "all we care about is the deliverables" school of thought that I (mistakenly) attributed to the original comment. There is far more to good practice than producing an apparently good result for the customer, but which neglects the longer-term interests of both the cleint and the developer.
The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern.
Absolutely! But that really can be said about pretty much any skill.
And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs.
I don't think I said "by itself". I think I said they are *one* of the tools we have available to us. Combined with those other tools (some of which are, I admit, *far* more important) patterns can indeed lower the cost of maintenance. Moreover, the I am convinced that the language of patterns (including their names, the literature) can be a useful comminication tool between developers. And good communication leads to lower costs.
There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction.
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
Patterns are quantification of common practices that existed before the term "pattern" existed.
Of course. But were they as widely used? As well understood? A tool for communication?
And good programmers (presumably) created them without knowing either the names or attributes of them.
And we will continue to do so. But not all of us are "good" programmers - at least not all the time. Not all of us want to re-invent the wheel. And some of us see the benfit of a shared language and approach. Don't get me wrong. I really do think there are more important things than patterns - perhaps they are over-emphasised in some circles - but I also find them a useful tool in providing best value for my clients.
-
...which could be applied to anything at all.
I'm not sure what you mean. They certainly wouldn't to the "all we care about is the deliverables" school of thought that I (mistakenly) attributed to the original comment. There is far more to good practice than producing an apparently good result for the customer, but which neglects the longer-term interests of both the cleint and the developer.
The fact that someone can recite a pattern definition has absolutely nothing to do with whether they can apply the pattern.
Absolutely! But that really can be said about pretty much any skill.
And I seriously doubt that by itself patterns have any significant impact on lowering maintenance costs.
I don't think I said "by itself". I think I said they are *one* of the tools we have available to us. Combined with those other tools (some of which are, I admit, *far* more important) patterns can indeed lower the cost of maintenance. Moreover, the I am convinced that the language of patterns (including their names, the literature) can be a useful comminication tool between developers. And good communication leads to lower costs.
There are proven ways of doing that and they all involve methodologies that for the most part exist entirely outside of actual code construction.
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
Patterns are quantification of common practices that existed before the term "pattern" existed.
Of course. But were they as widely used? As well understood? A tool for communication?
And good programmers (presumably) created them without knowing either the names or attributes of them.
And we will continue to do so. But not all of us are "good" programmers - at least not all the time. Not all of us want to re-invent the wheel. And some of us see the benfit of a shared language and approach. Don't get me wrong. I really do think there are more important things than patterns - perhaps they are over-emphasised in some circles - but I also find them a useful tool in providing best value for my clients.
KramII wrote:
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
No. I did however just take another look at "Rapid Developement" by the same author and nothing jumped out at me. So perhaps you could provide a summary of one of the points and the savings that it generated.
-
KramII wrote:
Ever read "Code Complete"? McConnell shows that there are also proven ways - and importent - ways of lowinging maintenance costs within code construction, too.
No. I did however just take another look at "Rapid Developement" by the same author and nothing jumped out at me. So perhaps you could provide a summary of one of the points and the savings that it generated.
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
"design patterns, handling the class responsibilities etc." Keep in mind that, until relatively recently (~1994), the term "Design Patterns," didn't exist. The patterns themselves existed, but they didn't have commonly used names. I've been programming for 27 years, so when I learned all these patterns, they were just known as "good architecture." When I started my current job, one of my colleges was steeped in these design patterns, and when we would talk programming, he'd throw out these terms all the time, and I wouldn't know what he was talking about. Turned out all of the design patterns are just things that I already know and use. I just didn't know the commonly-used terminology for them.
-
_Damian S_ wrote:
Hire him and expand his knowledge to include OO if that's important to your company/project.
Problem is I can't take the final decision. My company management is a crap and they think OO is the biggest thing in the world.
Navaneeth How to use google | Ask smart questions
N a v a n e e t h wrote:
My company management is a crap and they think OO is the biggest thing in the world.
I think this really sums up your problem. Based on your own description, the candidate is clearly capable. And I can tell you from doing interviews that the pool of capable candidates on the market is quite small. If your company is unwilling to invest time in a candidate who has most of the skills they need, that's not a good sign. I mean, let's face it, most programmers are short somewhere. But fundamentally, if your management is crap and they're responsible for the direction of your career, do you really want to bring this guy on to sinking ship with you? Maybe you should both be applying to work with whatever competitor is likely going to win the war in your industry.
-
I'd probably fail that OOP interview because I haven't bothered to learn the GOF lingo. I have 20+ years of experience programming and I learned OOP directly from the people who invented the concept (this was long before C++). I was writing OO production code in the mid 80's. I browsed through the GOF design patterns book once and couldn't figure out what the big deal was. Practically every design pattern in there was something I'd done before -- I didn't see any reason to read about something I've already been doing for years. And don't tell me having a common language to describe something makes it easier to communicate designs. It's my experience that as soon as you put a label on something and say it's a "foo" then people think they know what it is even when they don't have a clue and couldn't write one themselves. And, by the way, OOP is not the holy grail of programming. It's a tool and it's appropriate for certain problems. It's not appropriate for others. You are way better off with a programmer who is familiar with all the tools and pick the tool that's right for the job.
-
Recently I interviewed one guy and found that he is very good in technical stuff. He got a good understanding about C++ and C#. But his OO skills was not up to the level that my company was expecting. He knows and can create classes or interfaces, create good and readable code but he doesn't know to apply design patterns, handling the class responsibilities etc. IMO, OO skills like these can be developed easily when one starts working on projects. Technical knowledge and the willingness to learn matters. What will you do if you were in my position? Do you think advanced OO knowledge is needed to work on a project? Any thoughts?
Navaneeth How to use google | Ask smart questions
Navaneeth, all of these writers have excellent thoughts and all should be considered. I would keep the position open a little longer and interview other candidates to see how your one guy compares with the others. Someone mentioned that problem solving skills are the best set of skills to have. I would consider bringing him in for a second interview, but also let him know about which design patterns you work with. Give him time to study them. When he returns, ask him about his thoughts, the strengths and weaknesses of some of the patterns, where they can be used best, and his general thoughts. This will also give you a perspective on how his problem solving skills are as well as his research capability. Yes, sometimes, you need to research Google and other sources to get the pertinent information do your job. If he is serious (and sufficiently hungry), then he will do an excellent job and wow you with his new found knowledge and thinking. Design patterns are nice to know and use in conversation when expressing a design idea. But, over reliance on it or fitting the design to a pattern is not justified in its efficiency. And, yes, I prefer simplicity over complex patterning.
-
OO is way more than a "tool" - it is a way of thinking and designing (checks and balances). If you think of it only as a tool, you have missed the whole point.
If you think that a method of thinking and designing isn't a tool, then you are in the wrong profession. The most important tool you have in this game is how you think. If the only way you think is OO, then there are whole classes of problems that you won't come up with an optimal solution for. Having a hammer is great if all you ever work with is nails.
-
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
KramII wrote:
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
You said that they were "important" from you first response when I stated that there were proven methodogies that do improve code which do not have specific impact on code production. What you posted is a negative assertion. As an analogy I would suppose that code without any line breaks at all is going to be hard to understand. And in both cases a code review/walkthough, which is one of the proven techniques for increasing code quality, would discover both of those. I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
-
KramII wrote:
I am not aware of McConnell placing a monetary value on his arguments. However, he does make a strong case for many code construction practices. For example, McConnell (pg. 445, CC2) references a number of studies that imply that nesting if statements more than 3 or 4 layers deep makes them difficult to understand for most programmers. He then goes on to describe methods to avoid deep nesting in actual code construction.
You said that they were "important" from you first response when I stated that there were proven methodogies that do improve code which do not have specific impact on code production. What you posted is a negative assertion. As an analogy I would suppose that code without any line breaks at all is going to be hard to understand. And in both cases a code review/walkthough, which is one of the proven techniques for increasing code quality, would discover both of those. I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
jschell wrote:
I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples. I agree with your comment about the benefits of code reviews - these can be very useful for improving code.
-
jschell wrote:
I would like to see a positive assertion about code structures which measurably impacts code quality. That would be analogous to your assertions about patterns.
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples. I agree with your comment about the benefits of code reviews - these can be very useful for improving code.
KramII wrote:
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples.
Avoiding deep-nesting is a negative assertion. By not doing something there is a positive benefit. A positive assertion is where by doing something, like using patterns, there is a positive (and supported with data) gain.
-
KramII wrote:
The structures that McConnell proposes to avoid deep-nesting (1) are positive (2) measurably impact code quality. He provides *hundreds* similar examples.
Avoiding deep-nesting is a negative assertion. By not doing something there is a positive benefit. A positive assertion is where by doing something, like using patterns, there is a positive (and supported with data) gain.
-
jschell wrote:
Avoiding deep-nesting is a negative assertion. By not doing something there is a positive benefit.
Oh, I see what you're getting at. In that case: Use shallow nesting. Is that positive enough for you? :rolleyes: