About Entreprisey patterns...
-
The more parts and pieces a machine has, the greater the chance for failure at any given point. I am highly-against overly complex architectures and designs. I have never seen one live up to the sales pitch, and they have been nothing but a nightmare to maintain. KEEP IT SIMPLE STUPID (KISS)
100%. I concur.
Regards, Rob Philpott.
-
Jeroen_R wrote:
Also: a lot of developers don't want to work vertically.
Really?! :omg:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
It's terribly boring. I'm "the communications and hardware guy" (quoted because it's informal and I still do anything that must be done) and there are months where I have to implement all the new hardware communications and interfaces. After a month my productivity falls... to thep oint I start losing confidence in my abilites. Then an emergency arises and I solve it in record time - basically doing the same kind of work over and over dulls me to the point of uselessness. Also vertical works are always clunky, integrated and customzed environments work better - that's why in manifacturing plants verticalization is very loose and broad and the systems are basically ad-hoc solutions with nothing similar to layers, they are more like interconnected clouds of components which try to expose the same interfaces. They usually are more flexible, at the cost of greater complexity in the system.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
In larger companies: yes, very much so. And there's also the possibility that one of you management went golfing with a sales person from Oracle and now you're stuck exchanging your SQL server code with Oracle code. Which is easier if it lives separately from everything else. Also: a lot of developers don't want to work vertically. They don't want to do GUI or SQL work. Is it ideal? No it isn't, but with the shortage of good developers that want to work for big companies, there is not a lot you can do about it.
Jeroen_R wrote:
Also: a lot of developers don't want to work vertically
I once met a "C# expert" who would replace me at my old job. He refused to do anything but C# as that was his "expertise". He was so experienced that disposing wasn't necessary because the garbage collector handled that for him :laugh: When asked if he could look at a SQL issue he simply refused. This was an expensive contractor and we were a small company. He was cocky too, calling my code bad and me a "little man" (which is an insult). First fix he made crashed production though, he "optimized" my code because a 20 line function was too big to his tastes. Got me to stay in late and fix his code (once I found the problem I simply reverted to the previous revision) :sigh: Since then, whenever someone calls himself "expert" and refuses to work on anything else I punch them in the face :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Jeroen_R wrote:
Also: a lot of developers don't want to work vertically
I once met a "C# expert" who would replace me at my old job. He refused to do anything but C# as that was his "expertise". He was so experienced that disposing wasn't necessary because the garbage collector handled that for him :laugh: When asked if he could look at a SQL issue he simply refused. This was an expensive contractor and we were a small company. He was cocky too, calling my code bad and me a "little man" (which is an insult). First fix he made crashed production though, he "optimized" my code because a 20 line function was too big to his tastes. Got me to stay in late and fix his code (once I found the problem I simply reverted to the previous revision) :sigh: Since then, whenever someone calls himself "expert" and refuses to work on anything else I punch them in the face :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I usually warn if something is outside my main area of expertise but stop against nothing. In 4 years I did VB6, C++, Assembler, C# and C++\CLI. If soemone asks me C# things I clearly state that I have very little experience in C#, especially good C# (nobody uses it where I work and we have no code base in C#). Then I start working on it.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
-
I was having some deep thinking about what I call, disdainfully, "enterprise architecture", those bloated multi layerssss (the more the merrier) monsters... When it suddenly hit me how it might make sense in some environment. And I am looking for feedback on my conclusions. First I came from the point of view of an experienced developer who has mostly worked in small teams and I personally find that a vertical approach to development gives better results. i.e. When one is in charge of a feature, one does the SQL, the data exchange class, the webservice, service proxy and the UI and/or whatever else is needed for the feature to be fully functional. If one don't know how to solve a particular problem, ask a colleague! And as for code reuse, regular chat with your colleagues make sure every body use some common utility (or even business utility) library whenever possible. I think it gives better overall results. But now, for an other point of view, if I imagine an environment with high turn over and lots of graduate who don't know very well how to do SQL, HTMl/MVC, WPF, WCF/WebAPI, etc... Nor do they talk to the customer and understand the feature they are working on very well... It might seem like a good idea to have a GUI team, a SQL team, a Business layer team that each focus on one technology and one layer. Hence the layer monster comes to life with some reason to be such. Not that I agree on the long term benefit of that approach. But it kind of makes sense in that light. Am I on track here, as to why enterprise architecture is so wide spread?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Over the years I've learned the following enterprise patterns: The postpone pattern: useful when decisions need to be made. The we-will-get-back-to-you pattern: useful for when they don't want to get back to you. The clueless pattern: very widely adopted in the enterprise! The outdated pattern: because keeping up-to-date with technology requires decisions and a fraction of the money it costs in the long run to not update. The XML pattern: because deep down XML is the only technology that's really enterprise ready. XML everywhere. XML 4 teh win! The save-pennies pattern: the other patterns cost millions, but when you're an hour over budget they'll have your head in a meeting (which costs even more). The meetings-meetings-meetings pattern: to discuss the issues that arise because of the other patterns (only discuss, never solve though!). :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Jeroen_R wrote:
Also: a lot of developers don't want to work vertically
I once met a "C# expert" who would replace me at my old job. He refused to do anything but C# as that was his "expertise". He was so experienced that disposing wasn't necessary because the garbage collector handled that for him :laugh: When asked if he could look at a SQL issue he simply refused. This was an expensive contractor and we were a small company. He was cocky too, calling my code bad and me a "little man" (which is an insult). First fix he made crashed production though, he "optimized" my code because a 20 line function was too big to his tastes. Got me to stay in late and fix his code (once I found the problem I simply reverted to the previous revision) :sigh: Since then, whenever someone calls himself "expert" and refuses to work on anything else I punch them in the face :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I usually warn if something is outside my main area of expertise but stop against nothing. In 4 years I did VB6, C++, Assembler, C# and C++\CLI. If soemone asks me C# things I clearly state that I have very little experience in C#, especially good C# (nobody uses it where I work and we have no code base in C#). Then I start working on it.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
Yeah, I do that too. "Sure, I can have a look at it, but it's all new to me. So if it's in a hurry..." something like that :) But just saying "no, I don't do that." is a no-no. I'm not sure how the guy I just mentioned could've put his incapability into words though, we'd have to invent some new words :laugh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
A person's actions should always weigh more than their words.
Sander Rossel wrote:
I punch them in the face
Somehow, I don't believe this. Just saying. :thumbsup:
I completely agree with you *punches you in the face* :D Alright, I don't really punch people in the face, but not because I don't want too.
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I was having some deep thinking about what I call, disdainfully, "enterprise architecture", those bloated multi layerssss (the more the merrier) monsters... When it suddenly hit me how it might make sense in some environment. And I am looking for feedback on my conclusions. First I came from the point of view of an experienced developer who has mostly worked in small teams and I personally find that a vertical approach to development gives better results. i.e. When one is in charge of a feature, one does the SQL, the data exchange class, the webservice, service proxy and the UI and/or whatever else is needed for the feature to be fully functional. If one don't know how to solve a particular problem, ask a colleague! And as for code reuse, regular chat with your colleagues make sure every body use some common utility (or even business utility) library whenever possible. I think it gives better overall results. But now, for an other point of view, if I imagine an environment with high turn over and lots of graduate who don't know very well how to do SQL, HTMl/MVC, WPF, WCF/WebAPI, etc... Nor do they talk to the customer and understand the feature they are working on very well... It might seem like a good idea to have a GUI team, a SQL team, a Business layer team that each focus on one technology and one layer. Hence the layer monster comes to life with some reason to be such. Not that I agree on the long term benefit of that approach. But it kind of makes sense in that light. Am I on track here, as to why enterprise architecture is so wide spread?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I am currently involved in a large scale application - creating a reporting warehouse environment for a segment of our organization. The end result will be that ALL of the data needed for reporting will be available in SQL Server databases. Since I'm not working on the DB part, I can't comment on the number of databases or their complexity. What I do like about the project is this: I have my section I am responsible for: get data from the system I work on into 10 minutes buckets and exception buckets. That's it... I do my part and my part only. I will provide the general structure of the SQL statements needed to pull the data, but I am not responsible for the implementation of that. So, can it work? Yes, if management provides a reasonable time frame and assigns resources to attend to it.
-
Over the years I've learned the following enterprise patterns: The postpone pattern: useful when decisions need to be made. The we-will-get-back-to-you pattern: useful for when they don't want to get back to you. The clueless pattern: very widely adopted in the enterprise! The outdated pattern: because keeping up-to-date with technology requires decisions and a fraction of the money it costs in the long run to not update. The XML pattern: because deep down XML is the only technology that's really enterprise ready. XML everywhere. XML 4 teh win! The save-pennies pattern: the other patterns cost millions, but when you're an hour over budget they'll have your head in a meeting (which costs even more). The meetings-meetings-meetings pattern: to discuss the issues that arise because of the other patterns (only discuss, never solve though!). :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
XML pattern! yeah! ^_^
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I was having some deep thinking about what I call, disdainfully, "enterprise architecture", those bloated multi layerssss (the more the merrier) monsters... When it suddenly hit me how it might make sense in some environment. And I am looking for feedback on my conclusions. First I came from the point of view of an experienced developer who has mostly worked in small teams and I personally find that a vertical approach to development gives better results. i.e. When one is in charge of a feature, one does the SQL, the data exchange class, the webservice, service proxy and the UI and/or whatever else is needed for the feature to be fully functional. If one don't know how to solve a particular problem, ask a colleague! And as for code reuse, regular chat with your colleagues make sure every body use some common utility (or even business utility) library whenever possible. I think it gives better overall results. But now, for an other point of view, if I imagine an environment with high turn over and lots of graduate who don't know very well how to do SQL, HTMl/MVC, WPF, WCF/WebAPI, etc... Nor do they talk to the customer and understand the feature they are working on very well... It might seem like a good idea to have a GUI team, a SQL team, a Business layer team that each focus on one technology and one layer. Hence the layer monster comes to life with some reason to be such. Not that I agree on the long term benefit of that approach. But it kind of makes sense in that light. Am I on track here, as to why enterprise architecture is so wide spread?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The bank I work for is just starting the reverse engineering of a major rule based engine, definitely enterprisy! Thankfully I won't be coding in the project as there are a whole plethora of technologies being chucked into the mix. Data storage is Hadoop with a couple or 4 management packages/applications then MariaDb with another couple of apps to manage that. UI in Java, service layer in TibCo each with another couple of apps/packages to help manage them. I've probably missed a couple. To say I'm horrified is an understatement but it seems to be the way enterprisey architecture is put together. :sigh: I probably won't be around to see the outcome but I don't think it will be good.
Never underestimate the power of human stupidity RAH
-
The bank I work for is just starting the reverse engineering of a major rule based engine, definitely enterprisy! Thankfully I won't be coding in the project as there are a whole plethora of technologies being chucked into the mix. Data storage is Hadoop with a couple or 4 management packages/applications then MariaDb with another couple of apps to manage that. UI in Java, service layer in TibCo each with another couple of apps/packages to help manage them. I've probably missed a couple. To say I'm horrified is an understatement but it seems to be the way enterprisey architecture is put together. :sigh: I probably won't be around to see the outcome but I don't think it will be good.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
I've probably missed a couple. To say I'm horrified is an understatement but it seems to be the way enterprisey architecture is put together. :sigh: I probably won't be around to see the outcome but I don't think it will be good.
Haha! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Over the years I've learned the following enterprise patterns: The postpone pattern: useful when decisions need to be made. The we-will-get-back-to-you pattern: useful for when they don't want to get back to you. The clueless pattern: very widely adopted in the enterprise! The outdated pattern: because keeping up-to-date with technology requires decisions and a fraction of the money it costs in the long run to not update. The XML pattern: because deep down XML is the only technology that's really enterprise ready. XML everywhere. XML 4 teh win! The save-pennies pattern: the other patterns cost millions, but when you're an hour over budget they'll have your head in a meeting (which costs even more). The meetings-meetings-meetings pattern: to discuss the issues that arise because of the other patterns (only discuss, never solve though!). :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
You left out the hurry-up-and-wait pattern: your boss presses you really hard to get things in a test-ready state in two weeks only to find that the test team can't get to it for another two weeks :doh:
if (Object.DividedByZero == true) { Universe.Implode(); } Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
-
I was having some deep thinking about what I call, disdainfully, "enterprise architecture", those bloated multi layerssss (the more the merrier) monsters... When it suddenly hit me how it might make sense in some environment. And I am looking for feedback on my conclusions. First I came from the point of view of an experienced developer who has mostly worked in small teams and I personally find that a vertical approach to development gives better results. i.e. When one is in charge of a feature, one does the SQL, the data exchange class, the webservice, service proxy and the UI and/or whatever else is needed for the feature to be fully functional. If one don't know how to solve a particular problem, ask a colleague! And as for code reuse, regular chat with your colleagues make sure every body use some common utility (or even business utility) library whenever possible. I think it gives better overall results. But now, for an other point of view, if I imagine an environment with high turn over and lots of graduate who don't know very well how to do SQL, HTMl/MVC, WPF, WCF/WebAPI, etc... Nor do they talk to the customer and understand the feature they are working on very well... It might seem like a good idea to have a GUI team, a SQL team, a Business layer team that each focus on one technology and one layer. Hence the layer monster comes to life with some reason to be such. Not that I agree on the long term benefit of that approach. But it kind of makes sense in that light. Am I on track here, as to why enterprise architecture is so wide spread?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The user requirement by it leads/forces you to have enterprisey architecture. You might see a repetition from project to projects so at the end some modules goes to services other goes to library and so on and so forth.
-
Jeroen_R wrote:
Also: a lot of developers don't want to work vertically.
Really?! :omg:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
There's that famous saying: "Coding's more fun when your horizontal"... something like that anyway.
-
Jeroen_R wrote:
Also: a lot of developers don't want to work vertically
I once met a "C# expert" who would replace me at my old job. He refused to do anything but C# as that was his "expertise". He was so experienced that disposing wasn't necessary because the garbage collector handled that for him :laugh: When asked if he could look at a SQL issue he simply refused. This was an expensive contractor and we were a small company. He was cocky too, calling my code bad and me a "little man" (which is an insult). First fix he made crashed production though, he "optimized" my code because a 20 line function was too big to his tastes. Got me to stay in late and fix his code (once I found the problem I simply reverted to the previous revision) :sigh: Since then, whenever someone calls himself "expert" and refuses to work on anything else I punch them in the face :)
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I think I met this guy... We are talking building blocks or black boxes which can be plugged into each other once they have been made to do their individual function. It makes sense for rapid development but, as you say, no one gets to see the full picture.
We're philosophical about power outages here. A.C. come, A.C. go.
-
Over the years I've learned the following enterprise patterns: The postpone pattern: useful when decisions need to be made. The we-will-get-back-to-you pattern: useful for when they don't want to get back to you. The clueless pattern: very widely adopted in the enterprise! The outdated pattern: because keeping up-to-date with technology requires decisions and a fraction of the money it costs in the long run to not update. The XML pattern: because deep down XML is the only technology that's really enterprise ready. XML everywhere. XML 4 teh win! The save-pennies pattern: the other patterns cost millions, but when you're an hour over budget they'll have your head in a meeting (which costs even more). The meetings-meetings-meetings pattern: to discuss the issues that arise because of the other patterns (only discuss, never solve though!). :sigh:
Read my (free) ebook Object-Oriented Programming in C# Succinctly. Visit my blog at Sander's bits - Writing the code you need. Or read my articles here on CodeProject.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
You forgot one... "The Stupid Manager" pattern, where if they can place an incompetent in charge of a project, they will...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
I usually warn if something is outside my main area of expertise but stop against nothing. In 4 years I did VB6, C++, Assembler, C# and C++\CLI. If soemone asks me C# things I clearly state that I have very little experience in C#, especially good C# (nobody uses it where I work and we have no code base in C#). Then I start working on it.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
No C#? poor you... Anyhow I am not too worry, you seemed to have fun too! :D
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
You forgot one... "The Stupid Manager" pattern, where if they can place an incompetent in charge of a project, they will...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
Another great pattern! It even has a name! Peter principle - Wikipedia, the free encyclopedia[^]
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I am currently involved in a large scale application - creating a reporting warehouse environment for a segment of our organization. The end result will be that ALL of the data needed for reporting will be available in SQL Server databases. Since I'm not working on the DB part, I can't comment on the number of databases or their complexity. What I do like about the project is this: I have my section I am responsible for: get data from the system I work on into 10 minutes buckets and exception buckets. That's it... I do my part and my part only. I will provide the general structure of the SQL statements needed to pull the data, but I am not responsible for the implementation of that. So, can it work? Yes, if management provides a reasonable time frame and assigns resources to attend to it.
Truly no offense meant but as a "full stack" developer that sounds like hell to me. I left my last career because it became like that - a largely restricted sense of creativity and license in my daily activity. It does sound a bit like a "9 to 5" punch in, punch out mentality - which I'll admit can have its upsides.
