> 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.
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.
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
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.