2 ms·

> Good code is readable code, but not when the gap is too huge. For instances, they didn't know what is the difference between inheritance and composition. See

> Good code is readable code, but not when the gap is too huge. For instances, they didn't know what is the difference between inheritance and composition. Seems a standard problem when people talk about methodologies, they need to work in the real world not with what's expected of programmers. Probably 4th time to me means OP needs to adapt to how things actually work. Lots of working code earning $$$ doesn't use inheritance or composition. It gets the job done, is made redundant and new code is written for the next task.

shoo 10y ago
Or sometimes you end up in situations where common "antipatterns" are at least locally optimal. E.g. if you are working on projects with people making low quality changes & bad automated test coverage it can be better to have a bunch of duplicate/near duplicate code if it lets you decouple things.
joslin01 10y ago
> Seems a standard problem when people talk about methodologies, they need to work in the real world not with what's expected of programmers. I guess, but what project doesn't end up using a library that does indeed use inheritance or composition? You can say oh black box, I don't need to care, but inheriting from a library's base class is programming in the real world 101. It's just kinda silly really if you're a working programmer and don't understand the difference. It takes like 1-15m of googling and reading to be like "oh ok, ya I see now." Furthermore, how can you plan effectively if you can't even see these things? From Joel on Software "Painless Functional Specification - Part 1: Why bother?": > Why won't people write specs? People claim that it's because they're saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it." Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for. -- http://www.joelonsoftware.com/articles/fog0000000036.html http://www.joelonsoftware.com/articles/fog0000000036.html So if you don't really know how to plan because you don't understand the common set of patterns (but instead just treat everything like a nail cause all you got is a hammer), you're gonna just write code like crazy and eventually hit a wall and be like what happened? This could occur if the code becomes way too entangled or you do things in some unique idiosyncratic style and then just ditch the project and the next guy is like uh? I think business risk here is pretty obvious. Patterns create cohesive, uniform solutions that can be expanded on. Antipatterns slowly eat away at the project. So if this guy's components are intelligently decoupled -- and he took the time to plan that -- but the other programmers can't understand the pattern, who's really at fault? That's the crux of the issue if you're a guy like Joel working with gunslingers. It's not long before they turn their guns on you as the problem 'cause they're threatened. Now, just being realistic here, I think if this happened to the guy 4x he either is amazing and should go work for Google or has some other kinda attitude problem. I just wanted to counter the point that real world code doesn't need to concern itself with inheritance or composition patterns.

shoo 10y ago

Or sometimes you end up in situations where common "antipatterns" are at least locally optimal. E.g. if you are working on projects with people making low quality changes & bad automated test coverage it can be better to have a bunch of duplicate/near duplicate code if it lets you decouple things.

joslin01 10y ago

> Seems a standard problem when people talk about methodologies, they need to work in the real world not with what's expected of programmers. I guess, but what project doesn't end up using a library that does indeed use inheritance or composition? You can say oh black box, I don't need to care, but inheriting from a library's base class is programming in the real world 101. It's just kinda silly really if you're a working programmer and don't understand the difference. It takes like 1-15m of googling and reading to be like "oh ok, ya I see now." Furthermore, how can you plan effectively if you can't even see these things? From Joel on Software "Painless Functional Specification - Part 1: Why bother?": > Why won't people write specs? People claim that it's because they're saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it." Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for. -- http://www.joelonsoftware.com/articles/fog0000000036.html http://www.joelonsoftware.com/articles/fog0000000036.html So if you don't really know how to plan because you don't understand the common set of patterns (but instead just treat everything like a nail cause all you got is a hammer), you're gonna just write code like crazy and eventually hit a wall and be like what happened? This could occur if the code becomes way too entangled or you do things in some unique idiosyncratic style and then just ditch the project and the next guy is like uh? I think business risk here is pretty obvious. Patterns create cohesive, uniform solutions that can be expanded on. Antipatterns slowly eat away at the project. So if this guy's components are intelligently decoupled -- and he took the time to plan that -- but the other programmers can't understand the pattern, who's really at fault? That's the crux of the issue if you're a guy like Joel working with gunslingers. It's not long before they turn their guns on you as the problem 'cause they're threatened. Now, just being realistic here, I think if this happened to the guy 4x he either is amazing and should go work for Google or has some other kinda attitude problem. I just wanted to counter the point that real world code doesn't need to concern itself with inheritance or composition patterns.