Infrastructure... just because.
-
Well, I can't write all the code here because I'd have to write it out 5 times. Ok, we were supposed to use this company's architeture for a new project because we deal with that company for other unrelated technology. I guess the executive thought that since they do one thing ok, they must have a good architecture for this unrelated technology as well. So...I check into it. Now I suppose they got an idea in their heads, and that was that "no layer of architecture will trust any other layer of architecture, and the data transfer object will not trust anything". Maniacal Coding. They had identical business code duplicated in at least 5 places because each layer dealt with, and massaged, the data on it's own. I say 5 because, not only was there the logical tiers of processing, but everything existed as a service, and each layer processed each service to see if the user, who existed in a company, in a region, had access to that service in that tier. After all that, then each service would also run its little happy fingers through the data. By the time the data reached the database, the bits were worn pretty thin (hobo data). The user interface was the same: the business analyst just stopped and said 'no f****** way I'm teaching the client to use this thing', after taking over 30 min *just* to set up a user just with the ability to log in. Hahahah I threw it all out, and said "Thanks for your suggestion.Thanks for your suggestion.Thanks for your suggestion.Thanks for your suggestion."
GaltSalt maker of .Net thingys
-
Well, I can't write all the code here because I'd have to write it out 5 times. Ok, we were supposed to use this company's architeture for a new project because we deal with that company for other unrelated technology. I guess the executive thought that since they do one thing ok, they must have a good architecture for this unrelated technology as well. So...I check into it. Now I suppose they got an idea in their heads, and that was that "no layer of architecture will trust any other layer of architecture, and the data transfer object will not trust anything". Maniacal Coding. They had identical business code duplicated in at least 5 places because each layer dealt with, and massaged, the data on it's own. I say 5 because, not only was there the logical tiers of processing, but everything existed as a service, and each layer processed each service to see if the user, who existed in a company, in a region, had access to that service in that tier. After all that, then each service would also run its little happy fingers through the data. By the time the data reached the database, the bits were worn pretty thin (hobo data). The user interface was the same: the business analyst just stopped and said 'no f****** way I'm teaching the client to use this thing', after taking over 30 min *just* to set up a user just with the ability to log in. Hahahah I threw it all out, and said "Thanks for your suggestion.Thanks for your suggestion.Thanks for your suggestion.Thanks for your suggestion."
GaltSalt maker of .Net thingys
-
Well, I can't write all the code here because I'd have to write it out 5 times. Ok, we were supposed to use this company's architeture for a new project because we deal with that company for other unrelated technology. I guess the executive thought that since they do one thing ok, they must have a good architecture for this unrelated technology as well. So...I check into it. Now I suppose they got an idea in their heads, and that was that "no layer of architecture will trust any other layer of architecture, and the data transfer object will not trust anything". Maniacal Coding. They had identical business code duplicated in at least 5 places because each layer dealt with, and massaged, the data on it's own. I say 5 because, not only was there the logical tiers of processing, but everything existed as a service, and each layer processed each service to see if the user, who existed in a company, in a region, had access to that service in that tier. After all that, then each service would also run its little happy fingers through the data. By the time the data reached the database, the bits were worn pretty thin (hobo data). The user interface was the same: the business analyst just stopped and said 'no f****** way I'm teaching the client to use this thing', after taking over 30 min *just* to set up a user just with the ability to log in. Hahahah I threw it all out, and said "Thanks for your suggestion.Thanks for your suggestion.Thanks for your suggestion.Thanks for your suggestion."
GaltSalt maker of .Net thingys
Wow! talking about doing unnecessary extra work! We have to build a software with an sql Database that will have to check for Orders in our ERP DB (Oracle) So, what was my boss idea? He made us create a trigger that each time an order was created or modified a record with it's primary key was added in a table, Then we had an oracle process that run each 10' that looked at that table, recollected all the order information and saved it to another table in oracle, hen he made us install Oracle Gateway so we can access the sql server from oracle, So when there was New orders in the processed table oracle would connect to Sql Server and add a record to a Sql Tabla that said there was new data,Then we had another process in sql server that checked this table every 1' if the table said there was new data then another process was run that read the now processed tables with the order informations in oracle and extracted the data, once it extracted the data the process checked for modification o inserts against the Final Sql Server Orders Table! So after all that we Could access the sql server table from the Software and just list the content of the table.. When i told my boss why don't we just Access the orders table in Oracle from the software he told me: Noooo, if they change their TnsNames.ora file it would stop working!!! :wtf: