4 ms·

Of course this is a false dichotomy, but one I encounter quite a lot. It usually comes from younger inexperienced coders, or procedurally-minded coders who neve

Of course this is a false dichotomy, but one I encounter quite a lot. It usually comes from younger inexperienced coders, or procedurally-minded coders who never took the time to understand OOP. The false assumption is that "good code" takes longer to write than "good software." In reality "good code" only takes longer if you don't know what you're doing. If you haven't internalized good OOP, and you haven't applied good OOP principles enough to be efficient and judicious in your application of those principles, then yes, you'll probably do more harm than good, and you'll take longer to get there. If that's the experience level your team has, then you're faced with two bad options: 1) write a lot of duplicated, procedural-style code that you'll despise in 3 months and be begging the Software Gods for 6 weeks of clear time just to clean that crap up; or 2) attempt to design some nice DRY-ed up, SRP classes with all the right GOF patterns applied, more than likely get it wrong and really end up in the same place as 1). But if you understand and have experience (there's the rub) with good design (see: POEAA, GOF, Clean Code, Effective Java, etc.) then there's no choice to make, because it's much faster to write clean, well-architected code. It's must faster now, it will be much faster later. Of course there will always be that guy on the team that doesn't think in OOP and still writes 600 line methods and glazes over if there's interfaces or abstractions involved. That guy is just as bad as Hey Look At My Handy Dandy Patterns Guy. The solution to over-architecture is not bad architecture. It's understanding architecture and developing experience with it. While I have encountered OP's situation often, even more often I've encountered the consequences of haphazard design for those very same projects that "shipped fast": two guys in a back room refactoring for six weeks so that -- please please dear God -- we can get our bug rates down and start shipping features "like we used to."

pacala 15y ago
Thank you!
alexobenauer 15y ago
Nice discussion. I agree whole-heartedly, when it comes to full systems and programs. As in the article, when it comes to a simple plug-in to a system however, rewriting an entirely new version of an API just for the plugin was simply unnecessary.
- davesims 15y ago
  Agreed, YAGNI is just as important as SRP. That's good design too. But hopefully if you do eventually need an API, your design was good enough to allow easy interface extraction, etc.
  - alexobenauer 15y ago
    Absolutely; that's a fantastic point.
- hippich 15y ago
  If your API is not flexible enough and require to write ad-hoc code - it is broken and require refactoring. I know this is not lines up with "customer want it now and do not care", but code do not magically become less broken because of it.
  - alexobenauer 15y ago
    API of objects, not public-facing API. The internal API objects had to be re-written in a new language.
johnrob 15y ago
One problem with OOP is that it's highly dependent on getting it right. If your design is correct, that's great, but otherwise you end up in increasingly hot water. The problem I have with OOP for new projects is that it's hard to see the correct design until you have enough mileage.
- hippich 15y ago
  If you do not see correct design - you do not have enough information to start project anyway. Usually, this happens when modeled business process is a mess.
  - johnrob 15y ago
    The trick is to use a prototyping-friendly paradigm, and mentally write it off as a research project.
- davesims 15y ago
  Bad design is usually inexperienced design. 99% of the design problems you'll encounter have been encountered before and are probably cataloged. If you have doubts, read up, and bring in other experienced coders. In fact, if you don't have doubts, you're probably in trouble and need to bring in other coders. If you're not using UML or at least sketching class relationships out in some visual form, you're likely to get it wrong. Good OOP is hard, and requires experience and at lot of reading and concentration to get right. And even then, it usually requires a good bit of collaboration to get right, even for very experienced architects. But once a good clear design has been identified, it's much faster to code and much much easier to maintain.
  - cop359 15y ago
    " 99% of the design problems you'll encounter have been encountered before and are probably cataloged. " Bonus: It's already been done! http://en.wikipedia.org/wiki/Design_Patterns_(book) http://en.wikipedia.org/wiki/Design_Patterns_(book) I heard that when they wrote the book they basically mailed a whole bunch of people in the field to find out all the patterns people were using and they weren't able to find more then 23. After getting 23 every other pattern they would hear about would be just an iteration of one of the ones they had. Full Disclosure: I haven't actually read the book yet. But I'm planning to...
mqqq 15y ago
Thanks for this comment. I'm glad that some people understand OOP. It gets really anoying reading the whining Of developers that don't realize that it is them that suck, not really the patterns, language, or whatever they are attacking. Ruby programmers use to do this a lot.
jodoherty 15y ago
As a younger programmer, I've come to the conclusion that good code shares good interfaces, decoupled relationships, appropriate abstractions, and clear responsibilities regardless of methodology or paradigm used, so that your code is easier to implement, change, and maintain. After all, the end result is less complexity, and you can stub out some interfaces and get coding fairly quickly. However, if you lack experience with certain kinds of problems, the initial investment of designing good code requires quite a bit of thought and care to do right, otherwise there's the risk of introducing lots of unnecessary complexity by adding lots of unnecessary classes and relationships. And that's exactly the problem Alex is addressing in his blog post, because his fellow programmers don't share those same principles of good code. As a result, they get caught up in making large, cluttered interfaces with lots of interwoven objects that have shared responsibilities, and then they call that good Object Oriented code (because there's lots of objects, right?). They might even apply as many acronym riddled patterns as they can, because that's the way some really smart guys who wrote some books suggested, and they want to do things the right way. In other words, there's a cargo cult of OOP, and it loves complexity. In contrast to that, it sounds like what Alex does when he come across something where the architecture necessary isn't very clear is essentially what I do: carefully write code from the bottom up and refactor it as I go, if at all. That way, the relationships inherent in the code become clear, and you can create the minimal number of classes and relationships necessary to decouple those relationships. And so what he's suggesting is that other programmers do the same. Don't waste time trying to develop a solid architecture from the top down when it isn't immediately obvious and start working from the bottom up instead. Of course, in ten years, he'll probably be writing most of his software from the top down, finally capitalizing off all those years of hard earned experience writing code from the bottom up, but that'll be then, not now.
shasta 15y ago
Experience with OOP is certainly essentially, but mostly for the reason that the OOP language you're using sucks. Most of the "handy dandy patterns" that have sprung up are to recover properties that should have come for free, but didn't. As a result, code isn't objectively good or bad -- you must consider how it will be used. All of the boilerplate crap you have to write has a flat cost and a benefit proportional to how things scale in certain ways. The author of this piece is advocating "don't write any boilerplate crap at all", which we agree isn't the right answer. But experience or no, you'll get the design wrong too, because you can't predict how your requirements will change. In summary, repeating my earlier point, your OOP language sucks.
- davesims 15y ago
  I think over time we've seen that this is a good argument, as far as it goes. The old c2 discussion page for this is still good (and particularly relevant here at HN because of pg's contribution): http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu... Also others have weighed in: http://www.snell-pym.org.uk/archives/2008/12/29/design-patterns/ http://www.snell-pym.org.uk/archives/2008/12/29/design-patte... Let's take C#'s advancements over Java as an example. The LINQ features are clearly imported from the functional and/or dynamic world as replacements for iterator patterns. C#'s closures make Strategy and Command patterns basically irrelevant. Events and Delegates replace wiring up an Observer pattern. A meta-concern, if you will, is that general OOP principles don't apply in the same way in dynamic environments the way they do in statically typed environments. When I'm in Ruby I'm not nearly as concerned with coupling and some of the larger architectural concerns the way I am in Java/.NET. Because the language is dynamic, to some degree everything is an interface, and there's no need for complicated frameworks like IOC, etc. There's also no need for all the overhead of learning and managing generics/parameterized types. All those angle brackets and abstractions just to support what amounts to a more robust compile-time unit test. Makes me tired just thinkin about it. Java is Java and I don't know if I would say it "sucks." I do know between it and Ruby/Rails which one makes me about four times more productive.
  - davesims 15y ago
jvandenbroeck 15y ago
I really think the author of the article has no clue about what "good code" is. I could start a whole rant about what's wrong with the post - but davesims summarizes it pretty good.
devs1010 15y ago
completely agree.. it takes experience to be able to quickly write code that is also good, but its a worthwhile effort. The hype of trying to start a startup before having really mastered the art of writing code leads to some buggy products later on
vegas 15y ago
OOP isn't a panacea for bad design. It is a single design strategy that works well for some problems. We can descend deeply into the OOP way of viewing the world . Then we can construct really complicated, epicycle[0] like efforts to model everything under the sun using OOP's ontological system, or we can recognize it as one useful ontology amongst many and use it when it's appropriate. All of the "OOP is the one true way" literature ends up making some good and valid points. Their main effective point can be summarized sarcastically as "Here is how to implement Greenspun's 10th Rule in a way that is allegedly more maintainable, and we can say is object oriented. Buy more books, and also we have some modelling tools you can spend time using instead of writing code that does something." Circles are cool, I agree. Sometimes things are elliptical though, and it's much better to recognize that and use ellipses to model them then to cleave to the circle industry's way of doing business. In summation, this, and most industry(software or otherwise) gripes can be best understood by meditating on this message from beyond the grave from Christopher Latore Wallace Smith[\\] http://www.youtube.com/watch?v=nIyzG8i7Kg0 http://www.youtube.com/watch?v=nIyzG8i7Kg0 [0]http://en.wikipedia.org/wiki/Epicycle http://en.wikipedia.org/wiki/Epicycle [1]http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule [\\]http://bit.ly/4MiIh7 http://bit.ly/4MiIh7

pacala 15y ago

Thank you!

alexobenauer 15y ago

Nice discussion. I agree whole-heartedly, when it comes to full systems and programs. As in the article, when it comes to a simple plug-in to a system however, rewriting an entirely new version of an API just for the plugin was simply unnecessary.

davesims 15y ago
Agreed, YAGNI is just as important as SRP. That's good design too. But hopefully if you do eventually need an API, your design was good enough to allow easy interface extraction, etc.
- alexobenauer 15y ago
  Absolutely; that's a fantastic point.
hippich 15y ago
If your API is not flexible enough and require to write ad-hoc code - it is broken and require refactoring. I know this is not lines up with "customer want it now and do not care", but code do not magically become less broken because of it.
- alexobenauer 15y ago
  API of objects, not public-facing API. The internal API objects had to be re-written in a new language.

johnrob 15y ago

One problem with OOP is that it's highly dependent on getting it right. If your design is correct, that's great, but otherwise you end up in increasingly hot water. The problem I have with OOP for new projects is that it's hard to see the correct design until you have enough mileage.

hippich 15y ago
If you do not see correct design - you do not have enough information to start project anyway. Usually, this happens when modeled business process is a mess.
- johnrob 15y ago
  The trick is to use a prototyping-friendly paradigm, and mentally write it off as a research project.
davesims 15y ago
Bad design is usually inexperienced design. 99% of the design problems you'll encounter have been encountered before and are probably cataloged. If you have doubts, read up, and bring in other experienced coders. In fact, if you don't have doubts, you're probably in trouble and need to bring in other coders. If you're not using UML or at least sketching class relationships out in some visual form, you're likely to get it wrong. Good OOP is hard, and requires experience and at lot of reading and concentration to get right. And even then, it usually requires a good bit of collaboration to get right, even for very experienced architects. But once a good clear design has been identified, it's much faster to code and much much easier to maintain.
- cop359 15y ago
  " 99% of the design problems you'll encounter have been encountered before and are probably cataloged. " Bonus: It's already been done! http://en.wikipedia.org/wiki/Design_Patterns_(book) http://en.wikipedia.org/wiki/Design_Patterns_(book) I heard that when they wrote the book they basically mailed a whole bunch of people in the field to find out all the patterns people were using and they weren't able to find more then 23. After getting 23 every other pattern they would hear about would be just an iteration of one of the ones they had. Full Disclosure: I haven't actually read the book yet. But I'm planning to...

mqqq 15y ago

Thanks for this comment. I'm glad that some people understand OOP. It gets really anoying reading the whining Of developers that don't realize that it is them that suck, not really the patterns, language, or whatever they are attacking. Ruby programmers use to do this a lot.

jodoherty 15y ago

As a younger programmer, I've come to the conclusion that good code shares good interfaces, decoupled relationships, appropriate abstractions, and clear responsibilities regardless of methodology or paradigm used, so that your code is easier to implement, change, and maintain. After all, the end result is less complexity, and you can stub out some interfaces and get coding fairly quickly. However, if you lack experience with certain kinds of problems, the initial investment of designing good code requires quite a bit of thought and care to do right, otherwise there's the risk of introducing lots of unnecessary complexity by adding lots of unnecessary classes and relationships. And that's exactly the problem Alex is addressing in his blog post, because his fellow programmers don't share those same principles of good code. As a result, they get caught up in making large, cluttered interfaces with lots of interwoven objects that have shared responsibilities, and then they call that good Object Oriented code (because there's lots of objects, right?). They might even apply as many acronym riddled patterns as they can, because that's the way some really smart guys who wrote some books suggested, and they want to do things the right way. In other words, there's a cargo cult of OOP, and it loves complexity. In contrast to that, it sounds like what Alex does when he come across something where the architecture necessary isn't very clear is essentially what I do: carefully write code from the bottom up and refactor it as I go, if at all. That way, the relationships inherent in the code become clear, and you can create the minimal number of classes and relationships necessary to decouple those relationships. And so what he's suggesting is that other programmers do the same. Don't waste time trying to develop a solid architecture from the top down when it isn't immediately obvious and start working from the bottom up instead. Of course, in ten years, he'll probably be writing most of his software from the top down, finally capitalizing off all those years of hard earned experience writing code from the bottom up, but that'll be then, not now.

shasta 15y ago

Experience with OOP is certainly essentially, but mostly for the reason that the OOP language you're using sucks. Most of the "handy dandy patterns" that have sprung up are to recover properties that should have come for free, but didn't. As a result, code isn't objectively good or bad -- you must consider how it will be used. All of the boilerplate crap you have to write has a flat cost and a benefit proportional to how things scale in certain ways. The author of this piece is advocating "don't write any boilerplate crap at all", which we agree isn't the right answer. But experience or no, you'll get the design wrong too, because you can't predict how your requirements will change. In summary, repeating my earlier point, your OOP language sucks.

davesims 15y ago
I think over time we've seen that this is a good argument, as far as it goes. The old c2 discussion page for this is still good (and particularly relevant here at HN because of pg's contribution): http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatu... Also others have weighed in: http://www.snell-pym.org.uk/archives/2008/12/29/design-patterns/ http://www.snell-pym.org.uk/archives/2008/12/29/design-patte... Let's take C#'s advancements over Java as an example. The LINQ features are clearly imported from the functional and/or dynamic world as replacements for iterator patterns. C#'s closures make Strategy and Command patterns basically irrelevant. Events and Delegates replace wiring up an Observer pattern. A meta-concern, if you will, is that general OOP principles don't apply in the same way in dynamic environments the way they do in statically typed environments. When I'm in Ruby I'm not nearly as concerned with coupling and some of the larger architectural concerns the way I am in Java/.NET. Because the language is dynamic, to some degree everything is an interface, and there's no need for complicated frameworks like IOC, etc. There's also no need for all the overhead of learning and managing generics/parameterized types. All those angle brackets and abstractions just to support what amounts to a more robust compile-time unit test. Makes me tired just thinkin about it. Java is Java and I don't know if I would say it "sucks." I do know between it and Ruby/Rails which one makes me about four times more productive.
- davesims 15y ago

jvandenbroeck 15y ago

I really think the author of the article has no clue about what "good code" is. I could start a whole rant about what's wrong with the post - but davesims summarizes it pretty good.

devs1010 15y ago

completely agree.. it takes experience to be able to quickly write code that is also good, but its a worthwhile effort. The hype of trying to start a startup before having really mastered the art of writing code leads to some buggy products later on

vegas 15y ago

OOP isn't a panacea for bad design. It is a single design strategy that works well for some problems. We can descend deeply into the OOP way of viewing the world . Then we can construct really complicated, epicycle[0] like efforts to model everything under the sun using OOP's ontological system, or we can recognize it as one useful ontology amongst many and use it when it's appropriate. All of the "OOP is the one true way" literature ends up making some good and valid points. Their main effective point can be summarized sarcastically as "Here is how to implement Greenspun's 10th Rule in a way that is allegedly more maintainable, and we can say is object oriented. Buy more books, and also we have some modelling tools you can spend time using instead of writing code that does something." Circles are cool, I agree. Sometimes things are elliptical though, and it's much better to recognize that and use ellipses to model them then to cleave to the circle industry's way of doing business. In summation, this, and most industry(software or otherwise) gripes can be best understood by meditating on this message from beyond the grave from Christopher Latore Wallace Smith[\\] http://www.youtube.com/watch?v=nIyzG8i7Kg0 http://www.youtube.com/watch?v=nIyzG8i7Kg0 [0]http://en.wikipedia.org/wiki/Epicycle http://en.wikipedia.org/wiki/Epicycle [1]http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule [\\]http://bit.ly/4MiIh7 http://bit.ly/4MiIh7