3 Copy edited (e.g. ref. <http://english.stackexchange.com/questions/4645/is-it-ever-correct-to-have-a-space-before-a-question-or-exclamation-mark#comment206109_4645> and <https://en.wiktionary.org/wiki/world-class#Adjective>).
source | link

Your colleague seems to suffer from the NIH syndrome ("Not Invented Here").

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. But this short-term speed doesn't tellsay anything about the maintainability and portability of the code. I'll letgive him the benefit of the doubt: The existing code might indeed be badly structured if it has followed badly a textbook, badly or followed a good recipe in the wrong context.

Avoiding design patterns is really surprising. In my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. Design patterns proved to be real accelerators for mastering complexity!

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease?

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". Or "I don't want to argument onargue about my own design". I really think that patternization could leverage overall understanding, and it could allow less senior colleagues to share valuable opinions. But maybe your senior colleague wantwants to avoid just that.

The layeredLayered approaches have proven to be superior to other architectures in most enterprise applications. World-class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude. Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh! Sorry again: It's about proven patterns; no chance in your colleague's NIH view ;-)

Your colleague seems to suffer from the NIH syndrome ("Not Invented Here").

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. But this short-term speed doesn't tell anything about maintainability and portability of the code. I'll let him the benefit of the doubt: The existing code might indeed be badly structured if it followed badly a textbook, or followed a good recipe in the wrong context.

Avoiding design patterns is really surprising. In my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. Design patterns proved to be real accelerators for mastering complexity!

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease?

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". Or "I don't want to argument on my own design". I really think that patternization could leverage overall understanding, and it could allow less senior colleagues to share valuable opinions. But maybe your senior colleague want to avoid just that.

The layered approaches have proven to be superior to other architectures in most enterprise applications. World-class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude. Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh! Sorry again: It's about proven patterns; no chance in your colleague's NIH view ;-)

Your colleague seems to suffer from the NIH syndrome ("Not Invented Here").

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. But this short-term speed doesn't say anything about the maintainability and portability of the code. I'll give him the benefit of the doubt: The existing code might indeed be badly structured if it has followed a textbook badly or followed a good recipe in the wrong context.

Avoiding design patterns is really surprising. In my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. Design patterns proved to be real accelerators for mastering complexity!

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease?

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". Or "I don't want to argue about my own design". I really think that patternization could leverage overall understanding, and it could allow less senior colleagues to share valuable opinions. But maybe your senior colleague wants to avoid just that.

Layered approaches have proven to be superior to other architectures in most enterprise applications. World-class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude. Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh! Sorry again: It's about proven patterns; no chance in your colleague's NIH view ;-)

2 Copy edited (e.g. ref. <http://english.stackexchange.com/questions/4645/is-it-ever-correct-to-have-a-space-before-a-question-or-exclamation-mark#comment206109_4645> and <https://en.wiktionary.org/wiki/world-class#Adjective>).
source | link

Your colleague seems to suffer from the NIH syndromsyndrome ("Not Invented Here").  

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. ButBut this short term-term speed doesn't tell anything about maintainability and portability of the code. I'll let him the benefit of the doubt: theThe existing code might indeed be badly structured if it followed badly a textbook, or followed a good recipe in the wrong context.  

Avoiding design patterns is really surprising. InIn my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. DesignDesign patterns proved to be real accelerators for mastering complexity  !  

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease  ?  

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". OrOr "I don't want to argument on my own design". I really think that patternization could leverage overall understanding, and it could allow less senior colleagues to share valuable opinions. But may beBut maybe your senior colleague want to avoid just that.  

The layered approaches have proven to be superior to other architectures in most enterprise applications. World classWorld-class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude.  Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh Oh! Sorry again: it'sIt's about proven patterns; nono chance in your colleaguescolleague's NIH view ;-)

Your colleague seems to suffer from the NIH syndrom ("Not Invented Here").  

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. But this short term speed doesn't tell anything about maintainability and portability of the code. I'll let him the benefit of the doubt: the existing code might indeed be badly structured if it followed badly a textbook, or followed a good recipe in the wrong context.  

Avoiding design patterns is really surprising. In my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. Design patterns proved to be real accelerators for mastering complexity  !  

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease  ?  

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". Or "I don't want to argument on my own design". I really think that patternization could leverage overall understanding, and could allow less senior colleagues to share valuable opinions. But may be your senior colleague want to avoid just that.  

The layered approaches have proven to be superior to other architectures in most enterprise applications. World class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude.  Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh ! Sorry again: it's about proven patterns; no chance in your colleagues NIH view ;-)

Your colleague seems to suffer from the NIH syndrome ("Not Invented Here").

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. But this short-term speed doesn't tell anything about maintainability and portability of the code. I'll let him the benefit of the doubt: The existing code might indeed be badly structured if it followed badly a textbook, or followed a good recipe in the wrong context.

Avoiding design patterns is really surprising. In my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. Design patterns proved to be real accelerators for mastering complexity!

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease?

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". Or "I don't want to argument on my own design". I really think that patternization could leverage overall understanding, and it could allow less senior colleagues to share valuable opinions. But maybe your senior colleague want to avoid just that.

The layered approaches have proven to be superior to other architectures in most enterprise applications. World-class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude. Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh! Sorry again: It's about proven patterns; no chance in your colleague's NIH view ;-)

1
source | link

Your colleague seems to suffer from the NIH syndrom ("Not Invented Here").

It's perfectly plausible that his code makes it easier to add new fields: I'm also much faster to update my own code than the code written by other guys. But this short term speed doesn't tell anything about maintainability and portability of the code. I'll let him the benefit of the doubt: the existing code might indeed be badly structured if it followed badly a textbook, or followed a good recipe in the wrong context.

Avoiding design patterns is really surprising. In my last 30 years of coding and managing coders, design patterns helped to put words on things that were done instinctively, helping so to understand more quickly the intent, the advantages, inconveniences, risk, opportunities and related patterns. Design patterns proved to be real accelerators for mastering complexity !

  • Perhaps your colleague is really much more intelligent than most of us and he can afford the overhead of reinventing patterns without noticeable productivity decrease ?

  • The arguments that "programmers don't understand design patterns" sounds like "I can't really explain what I'm doing". Or "I don't want to argument on my own design". I really think that patternization could leverage overall understanding, and could allow less senior colleagues to share valuable opinions. But may be your senior colleague want to avoid just that.

The layered approaches have proven to be superior to other architectures in most enterprise applications. World class leading packages are structured around this idea and outperform artisanal architectures by orders of magnitude. Martin Fowler presents this approach in his excellent book on "Patterns of enterprise architecture". Oh ! Sorry again: it's about proven patterns; no chance in your colleagues NIH view ;-)