My first rant in a long time...
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
"Can anyone give me ONE example where layered code has proved to be a major advantage?"
I could give you way more more than one - but here are two. While OOA/OOP (and there is a difference) can, and too often is, overdone, it has practical usage. I had one project where I wrote a network monitoring system (in VB6). I had middleware. including a service, that monitored network equipment, including servers, using SNMP and WMI. One or more central monitoring UIs talked with the distributed systems. The distributed systems would push alerts back to the UIs, and the UIs could query the distributed systems. The UI install had only the UI components, and a set of interface DLLs that define the objects available from the distributed systems. The actual components for the distributed systems only resided there. I could have hacked up something using RPC calls and delimited strings, but using DCOM and objects was a better approach. I had one project where the business layer was OO, and in doing so all I needed to do to increase the number of users was to add another middleware server to the farm, and now I could handle a lot more users. The UI depended on a set of interfaces, and thus my UI could be a Win32 app and ASP (or now Win32, Win64, ASP.NET, Win7, etc.) No object oriented design is properly done without applying the KISS principle, IMHO. But trying to do distributed apps without OO is a waste of time, resources, and very hard to debug.
-
I can't but maybe that's why I'm working on a project where we just removed one of the 4 layers in the application, and are simplifying and whittling down things in the remaining code. You left out that not only does it slow down the application, it slows down the build and compile times too. :-D Also, each one of the devs ends up having a favorite layer and they write crazy complicated code in their favorite, and crap code in the others, nobody ends up owning or caring about the system as a whole. Or, the architect writes a ton of complicated data access code and turns a bunch of junior devs loose on the UI.
nobody ends up owning or caring about the system as a whole
That is where developer managers aren't doing their job.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
You may want to read this, http://blog.dmbcllc.com/2008/05/13/object-oriented-programming-has-failed-us/[^] someone else who agrees with your sentiments. I don't program for a living so I don't have much of an opinion either way. I can see some of the benefits of OOP; but I can also see how those benefits can be easily incorporated into structured programming.
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Sorry but OOP is a great tool. Your problem is the insane implementation. Turns out that just about anybody can turn the best ideas in the world into a steaming pile of crap. I feel your pain, my condolences.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
First thing, Object Oriented and Layered and not the same thing. Often they are both used, and often they are not. The science and art of Software Engineering is about managing complexity. Of course, if you have a very simple system, you will probably want a very simple software design - one or few layers, no object-oriented constructs. But, as your system grows with just the slightest complexity, be it hardware, timing, protocols, etc., you need some sort of layering or you'll have a huge mess of code. Layering and Object Oriented methods MANAGE COMPLEXITY. That's all they do. One example of layering not discussed in the thread is the ability to divide the work amongst a team by areas of expertise. Without layering, everyone would have to know everything. Does the USB protocol expert need to know about the application? Maybe not. Does the UI guy need to know about TCP/IP? Does the battery charger guy need to know about the application? Layering also makes testing much more thorough. You can test one layer independently from another. Of course, without layers, you could never integrate third party software libraries, stacks, etc. Object Oriented also thrives in this department. Take a nice library from someone and subclass their objects to your needs. So, I do believe that your software and the people you work with suck. No argument here. But, in my experience, thoughtful up-front design of layers of abstraction are the best, quickest, most efficient, and safest (I'm a medical device guy route. Stuart
-
The definition of layer is that it only sees the layer directly above and below it. So by layering, you can reduce the amount of the whole system that is seen from one single layer. This is just one way of reducing dependencies between parts of the code base, and this is a good thing (divide an conquer). Throwing all code in one namespace in one big file is not a very good approach. If your project's architecture is crap, it has nothing todo with OO or layering, it is caused by bad modelling by the architect.
Wout
wout de zeeuw wrote:
If your project's architecture is crap, it has nothing todo with OO or layering, it is caused by bad modelling by the architect.
:thumbsup: And someone who doesn't understand the difference when trying to figure out what's wrong with the project is programming like it's still '95. The OP wasn't a rant, it was a confession.
“The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary.” ~ H.L. Mencken
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
hi, like others already said, a system without abstraction is not maintainable. There are a lot of good examples out there, and most of them are working pretty well. Guess if you really want to know any, you would be pretty good in finding some. I have another question: What do you think would be the right approach? Functional? Procedural? Dynamic? Isn't it the task that has to accomplished that defines which is the best language and paradigm to use? I guess in your case you really should have an eye on some pretty well working (open source) projects. What about NHibernate? Eclipse? Mono? Is that all crap because of the architect in your team that wants to win the price of the worldwide-most-layers in a project? :) Holger
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Waytogo, man! I feel your pain. As I read your rant I was figuring the follow-up comments would argue against; I was pleasantly surprised to find that was not the case. I made myself learn OOP for the obvious reasons. I wrote c code for 15 years and when we needed OOP-like stuff, we wrote it.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Object Oriented design is a tool. Like any tool, a micrometer say, it can be used well to do fine and delicate work, or you can turn it over and use it like a hammer, which has predictably bad results for both the tool and the project. An OO system architected into more than three layers is probably being used like a hammer by somebody who doesn't know what his tool is for. It's a poor workman who blames his tools, but it's not too unreasonable to blame the workman. One thing I see is that the number of people capable of good OO design, as a fraction of all working programmers, is declining. I propose that OO design was invented during a time when only the geekiest and most motivated became programmers, and average developer I.Q. was higher. Nowadays, with every retreaded poet and astronomer writing code, there is perhaps a case to be made that object oriented programming shouldn't be taught to people who are really only cut out for add/change/delete screens and login pages.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
I like the rant, Johnny, particularly because it led to such great responses. Your pain here was worthy of a rant. I don't think I've ever had to work on a project designed in 7 layers. My mom use to make a great 7-layer bar, and my friend makes a killer 7-layer dip, but a 7-layer app sounds like a nightmare. There is great benefit though for those projects in which multiple presentations or supported devices are required (e.g. a web front-end + a desktop app + a mobile app all having to work with the same underlying business logic) and for the developer that needs or wants to support multiple database engines. When one presentation or data layer can simply be swapped out for another as needed, it is so much easier to support multiple platform use cases (and I would argue easier to develop for them too). But to me there is no question: if one creates layers in a way that isn't smart in design, the resulting app & development work gain none of the advantages of layers but only magnify the disadvantages.
-
First thing, Object Oriented and Layered and not the same thing. Often they are both used, and often they are not. The science and art of Software Engineering is about managing complexity. Of course, if you have a very simple system, you will probably want a very simple software design - one or few layers, no object-oriented constructs. But, as your system grows with just the slightest complexity, be it hardware, timing, protocols, etc., you need some sort of layering or you'll have a huge mess of code. Layering and Object Oriented methods MANAGE COMPLEXITY. That's all they do. One example of layering not discussed in the thread is the ability to divide the work amongst a team by areas of expertise. Without layering, everyone would have to know everything. Does the USB protocol expert need to know about the application? Maybe not. Does the UI guy need to know about TCP/IP? Does the battery charger guy need to know about the application? Layering also makes testing much more thorough. You can test one layer independently from another. Of course, without layers, you could never integrate third party software libraries, stacks, etc. Object Oriented also thrives in this department. Take a nice library from someone and subclass their objects to your needs. So, I do believe that your software and the people you work with suck. No argument here. But, in my experience, thoughtful up-front design of layers of abstraction are the best, quickest, most efficient, and safest (I'm a medical device guy route. Stuart
Stuart Rubin wrote:
Object Oriented and Layered and not the same thing
I've never said it was...
1f y0u c4n r34d 7h15 y0u r3411y n33d 70 g37 14!d Gotta run; I've got people to do and things to see... Don't tell my folks I'm a computer programmer - They think I'm a piano player in a cat house... Da mihi sis crustum Etruscum cum omnibus in eo!
-
I like the rant, Johnny, particularly because it led to such great responses. Your pain here was worthy of a rant. I don't think I've ever had to work on a project designed in 7 layers. My mom use to make a great 7-layer bar, and my friend makes a killer 7-layer dip, but a 7-layer app sounds like a nightmare. There is great benefit though for those projects in which multiple presentations or supported devices are required (e.g. a web front-end + a desktop app + a mobile app all having to work with the same underlying business logic) and for the developer that needs or wants to support multiple database engines. When one presentation or data layer can simply be swapped out for another as needed, it is so much easier to support multiple platform use cases (and I would argue easier to develop for them too). But to me there is no question: if one creates layers in a way that isn't smart in design, the resulting app & development work gain none of the advantages of layers but only magnify the disadvantages.
Thanks - I'm very pleased with the responses myself - both the pros and cons...
1f y0u c4n r34d 7h15 y0u r3411y n33d 70 g37 14!d Gotta run; I've got people to do and things to see... Don't tell my folks I'm a computer programmer - They think I'm a piano player in a cat house... Da mihi sis crustum Etruscum cum omnibus in eo!
-
Waytogo, man! I feel your pain. As I read your rant I was figuring the follow-up comments would argue against; I was pleasantly surprised to find that was not the case. I made myself learn OOP for the obvious reasons. I wrote c code for 15 years and when we needed OOP-like stuff, we wrote it.
GamleKoder wrote:
As I read your rant I was figuring the follow-up comments would argue against; I was pleasantly surprised to find that was not the case.
Me too... :)
1f y0u c4n r34d 7h15 y0u r3411y n33d 70 g37 14!d Gotta run; I've got people to do and things to see... Don't tell my folks I'm a computer programmer - They think I'm a piano player in a cat house... Da mihi sis crustum Etruscum cum omnibus in eo!
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
You are absolutely right. The OO/layering religion has been a MASSIVE failure. I've seen so many systems fail under this weight of this paradigm. It seems that developers like to prove how smart they are by "architecting" systems like this, but then they leave when the $%%&** hits the fan and its impossible to work with the monster they've created.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Try taking a monolithic application that no one understands, ripping it apart into its constituent atoms, and rebuilding it with a layered architecture. Now THAT will teach you why layering is good paradigm. FWIW, layering is also a good idea when you want to account for future technologies/growth/expansion, so one day you can replace your C++ GUI front end desktop app with a Silverlight GUI fron end web app without needing to also change the underlying "business layer" code. OOP may encourage and provide sound approaches for good software design, but it neither garauntees nor requires it.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Johnny J. wrote:
I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage? I'm not talking about hypothetics like "Oh, what if we have to change to another type of database?" crap, because that is never going to happen in 99.9% of systems. Give me an example where someone has actually leaned back at a meeting and calmly said: "THANK GOD that we broke all the foobar code out in a separate foobar layer!" I challenge you - you can't.
Sure I can. EASILY. I'm building a time and attendance system. Needed code to handle the badge (magstripe) reader. Built an object to represent the reader. Now in my code I say: 1) Create a reader at port COM6 2) Read card The object knows to do everything associated with reading the badge which includes resetting the device, making sure the COM port is open to it, setting the LED to indicate it's in read mode, taking the swipe and returning 3 tracks of card data to the 3 variables I presented to it. The code associated with those two actions took me a couple of weeks to write and debug. It now exists in a "layer" that I can call with two lines of code. I don't have to worry whether it will work or not, I can create the object anywhere in my application and it will work exactly the same way everywhere I call it. If a bug turns up in it somewhere then I fix it in ONE place - then all callers get the fix. Ultimate in modular design. To my application the MSR605 IS an object and he doesn't need to know anything about it - he just tells it what to do and it does it. Back 35 years ago we'd have done the same thing - with a library. I "fought" the OO paradigm until I had a chance to really work with it. Once I did a few of these things I now wonder why I fought it so hard - the abstraction really raises the bar on what you can accomplish. Without such "layering" you would be writing all the code to handle the device manually each time. I don't think you are advocating going back there. What I think you're having a problem with is not the layering issue - you're having a people issue! I've worked in a lot of shops where the problems were just like yours. It's not an underlying problem with the technology -it's a lack of organization on the people using it! In the case of my last gig, we had 7 or 8 different functions that performed the same time conversions. If we'd had a "librarian" keeping track of the central code base maybe that wouldn't hav
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
An example is simple - I wrote a WPF application. Now there is a desire from our customers to have pieces of it available from the web. Since I separated the UI layer from the business logic layer, it is easy to build some Silverlight pages to show the information through a webpage. If I hadn't separated the layers, I'd basically be re-writing the application. Just because your bone-headed architect went overboard doesn't mean the fundamental idea is flawed - lots of good ideas can suffer through poor implementation. And crappy programmers can screw up code in any genre... that doesn't mean we should all go back to coding in assembly. (And for the record, I spent a good chunk of my career programming in RPG (procedural language) before switching to primarily OO languages, and I much prefer the OO languages).
-
Johnny J. wrote:
I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage? I'm not talking about hypothetics like "Oh, what if we have to change to another type of database?" crap, because that is never going to happen in 99.9% of systems. Give me an example where someone has actually leaned back at a meeting and calmly said: "THANK GOD that we broke all the foobar code out in a separate foobar layer!" I challenge you - you can't.
Sure I can. EASILY. I'm building a time and attendance system. Needed code to handle the badge (magstripe) reader. Built an object to represent the reader. Now in my code I say: 1) Create a reader at port COM6 2) Read card The object knows to do everything associated with reading the badge which includes resetting the device, making sure the COM port is open to it, setting the LED to indicate it's in read mode, taking the swipe and returning 3 tracks of card data to the 3 variables I presented to it. The code associated with those two actions took me a couple of weeks to write and debug. It now exists in a "layer" that I can call with two lines of code. I don't have to worry whether it will work or not, I can create the object anywhere in my application and it will work exactly the same way everywhere I call it. If a bug turns up in it somewhere then I fix it in ONE place - then all callers get the fix. Ultimate in modular design. To my application the MSR605 IS an object and he doesn't need to know anything about it - he just tells it what to do and it does it. Back 35 years ago we'd have done the same thing - with a library. I "fought" the OO paradigm until I had a chance to really work with it. Once I did a few of these things I now wonder why I fought it so hard - the abstraction really raises the bar on what you can accomplish. Without such "layering" you would be writing all the code to handle the device manually each time. I don't think you are advocating going back there. What I think you're having a problem with is not the layering issue - you're having a people issue! I've worked in a lot of shops where the problems were just like yours. It's not an underlying problem with the technology -it's a lack of organization on the people using it! In the case of my last gig, we had 7 or 8 different functions that performed the same time conversions. If we'd had a "librarian" keeping track of the central code base maybe that wouldn't hav
Max Peck wrote:
Ultimate in modular design
So would putting the same functionality in a dll file. ;P Everything that can be done in OOP can be done conventionally just as easy. How do you think operating systems were written before some bright spark came up with the idea of OOP?
Nobody can get the truth out of me because even I don't know what it is. I keep myself in a constant state of utter confusion. - Col. Flagg
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
I can provide what I think would be a pretty common example. I work for an online retailer. We have a main retail site, a mobile site, two APIs, and a number of windows services that perform the back end processing that keeps the business chugging. Each of these apps, or clients, tap into a common service layer that in turn uses a common data layer. Layers in this case prevent a massive amount of duplicate code from having to be written and maintained for each app.
-
OK, so here's the deal: I've been programming for many years now. In the beginning was sequential code execution. Then, with the introduction of Windows we got event driven code execution. So far so good. Then some day some jackass thought to himself: "This is too simple, let's complicate it further and invent Object Orientation. And just as a bonus, let's get everybody to divide their code in a huge amount of layers so that noone will be able to get the full view of everything." And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped. The last three projects I've worked on have been totally over-OO'd and layered to death. In all of the cases, I have not been a part of the initial development, but steeped in and developed on a running system. The current project I'm working on is by far the worst. The system architecht one day proudly told me that the code was divided in SEVEN different layers. To be honest, I can't tell if he's right or not, because I can't be bothered to verify it. The codebase is growing, because not even the developers that did it in the first place can keep track of everything, so duplicate objects, properties and methods are constantly written because noone knows that they exist already. And of course, noone can clean it up either because after some time noone knows what is dead code and what code actually serves a purpose. And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system. I'm not the least bit surprised, with each code call having to pass back and forth through seven layers, some of them connected by WCF (for scalability, hah - that's the biggest joke!) and the fact that each time you want to know something, you fill a list of objects with perhaps 30 properties (and child objects) when you're really only interested in one or two. And that's just a couple of examples... In all of my latest projects, the code has been layered in at least 3 layers - and for what bleedin' use? I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage?
Johnny J. wrote:
And now, everybody's doing precisely that. And if that's not enough, all companies have their OWN understanding of how the object oriented structure and the layering should look and feel. And the developers want everybody to know that they understand the latest technologiest so they throw in every new hype they can think of even when it's completely unnecessary. I hate it. It's a major misunderstanding. I know I'm going to get downvoted for this, but that can't be helped.
Technology does not and will not solve process problems. Technology does not and will not solve bugs in the architecture/requirements. Technology and will not help solve problems in design that are not specifically technological. Thus for example XML might solve a problem but ONLY if the designer understands the architecture, requirements and both the advantages and disadvantages of XML.
Johnny J. wrote:
And the system is slow as hell, and it's growing slower each days as more users use it and more data is added to the system.
Again technology will not solve process problems.
Johnny J. wrote:
I have a task for you: Can anyone give me ONE example where layered code has proved to be a major advantage? I'm not talking about hypothetics like "Oh, what if we have to change to another type of database?"
Real personal cases. 1. Application was originally developed to target MS SQL Server because the developers interpreted the known contract language (done via numerous management layers) to suggest database choice didn't matter. Then the customer, via direct communication, insisted that Oracle must be used. The database layer, part of the design, was changed. Absolutely nothing else changed in the application. 2. Application needed to support multiple (30+) interfaces to external service providers using varying sorts of IP protocols. Application was designed with a Plugin layer. Plugins work. 3. Application needed to support 3rd party device with 3rd party proprietary interface code. That code would crash (system exception) at odd times. Application layer interface added which allowed 3rd party code to run in another process managed by the first. Thus it could not crash the original app. (Actually this idiom is the one I now design for always in both C# and Java for 3rd party native code regardless of perceived stability.)