Sanity check
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Why did mgmt hire developers if they obviously know how to implement it themselves? While I don't always agree with the CTO at work at least he knows how to tell the CEO what the CEO's job is and what the CTO's job is. He'd have a cadensa with your situation.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Nope. Your sane. This is rediculous. What about arguments supporting Mono? Its fairly mature now in supporting .NET 1.1. I would push for that personally. The cost of developer training and the efforts of getting to a competent level will be more expensive than migrating the required portions in the future.
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Josh Smith wrote:
Am I going crazy, or is this hypothetical situation completely ridiculous?
Sounds like part of the app i'm working on right now. So, yes. :->
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Why did mgmt hire developers if they obviously know how to implement it themselves? While I don't always agree with the CTO at work at least he knows how to tell the CEO what the CEO's job is and what the CTO's job is. He'd have a cadensa with your situation.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
Percival Watson wrote:
Why did mgmt hire developers if they obviously know how to implement it themselves?
Because...umm....well....errr.......XML! That's right, XML! :~
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Josh Smith wrote:
No particular reason why, but it must be XML
ROTFL !!!!
Josh Smith wrote:
Am I going crazy, or is this hypothetical situation completely ridiculous?
Hypothetically, this sounds like a ripe opportunity for someone to start a Dilbert like cartoon, or film an 'Office Space' type movie.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
Nope. Your sane. This is rediculous. What about arguments supporting Mono? Its fairly mature now in supporting .NET 1.1. I would push for that personally. The cost of developer training and the efforts of getting to a competent level will be more expensive than migrating the required portions in the future.
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
Chris S Kaiser wrote:
Nope. Your sane. This is rediculous.
Phew! That's a relief. :)
Chris S Kaiser wrote:
What about arguments supporting Mono?
I tried that route. It was like trying to sell flamethrowers to retarded eskimos.
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Well, the crummy part is your the employee. The sanity check really comes down to staying there and doing the work (I mean after all, work is work. Learn C++ and savor it you'll miss coding in it the rest of your life.) or leaving the job to find one more sane. So you have some hard requirements. Can you do them by March? How big is your team? If not then present clear concise arguments to management and ask them to change. There's nothing sane when you are an employee. It's the employees job to add sanity to the conundrum's that could only evolve from a managers brain. Remember, "Excuse me I'm a manager?". That thought prevails in all of them. Your job is to bring sanity where there is only awareness of titles and bonuses and butt-kissing. Good Luck Soldier! Some of you will probably die.:-D
-
Josh Smith wrote:
No particular reason why, but it must be XML
ROTFL !!!!
Josh Smith wrote:
Am I going crazy, or is this hypothetical situation completely ridiculous?
Hypothetically, this sounds like a ripe opportunity for someone to start a Dilbert like cartoon, or film an 'Office Space' type movie.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
Christian Graus wrote:
Hypothetically, this sounds like a ripe opportunity for someone to start a Dilbert like cartoon, or film an 'Office Space' type movie.
Nah, I just got a job working on a kick ass WPF application and gave my two week notice (plus a pay raise and a bunch of bennies).
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Well, the crummy part is your the employee. The sanity check really comes down to staying there and doing the work (I mean after all, work is work. Learn C++ and savor it you'll miss coding in it the rest of your life.) or leaving the job to find one more sane. So you have some hard requirements. Can you do them by March? How big is your team? If not then present clear concise arguments to management and ask them to change. There's nothing sane when you are an employee. It's the employees job to add sanity to the conundrum's that could only evolve from a managers brain. Remember, "Excuse me I'm a manager?". That thought prevails in all of them. Your job is to bring sanity where there is only awareness of titles and bonuses and butt-kissing. Good Luck Soldier! Some of you will probably die.:-D
code-frog wrote:
It's the employees job to add sanity to the conundrum's that could only evolve from a managers brain.
:-D I got a new job and resigned. ;)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
code-frog wrote:
It's the employees job to add sanity to the conundrum's that could only evolve from a managers brain.
:-D I got a new job and resigned. ;)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleIf I were in that hypothetical situation, I'd use my position as someone who doesn't care anymore about what management thinks, to present an honest appraisal of their approach. Politely, I'd do it in the hope it could help, not to take a parting shot.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
If I were in that hypothetical situation, I'd use my position as someone who doesn't care anymore about what management thinks, to present an honest appraisal of their approach. Politely, I'd do it in the hope it could help, not to take a parting shot.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
Christian Graus wrote:
I'd use my position as someone who doesn't care anymore about what management thinks
Who said anything about mgmt thinking?
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Josh Smith wrote:
Am I going crazy, or is this hypothetical situation completely ridiculous?
Sounds like part of the app i'm working on right now. So, yes. :->
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
Sounds like part of the app i'm working on right now.
At least I'm in good company. :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
To me the scenario sound so "ideal" that looks like somebody took it from a book as it is and giving the requirements having zero notions about "reality". I don't know how complex the application will be, but will appears several problems to interact C# with C++ throw just XML, unless it can export simple data the recursive object serialization/deserialization will take a good amount of time, especially because C++ doesn't have reflection, so you can't scan the types on the fly, so the data to be interchanged between the layers has to be "hard" defined in the code and every data to be serialized/deserialized in C++ will have to come with a helper function to do the serialization/deserialization. Also if in a future part of the app can run on Linux then also you can’t make like a simple dll for the C++ functionality or you could but then when this portion runs on Linux, the client would not be able to connect to the server portion. So you better think from the very beginning run the C++ as different process but now that brings other problem how to interchange the data. You can’t use remoting because is MS dependant, so you will have to run a TCP pipe between the two process, and what you do? You will have to use a proprietary binary protocol to send the XML transaction back and forth…. Or install a HTTP server and send HTTP request/response from the client application. Mmmm how many problems I see with that requirement. For me those are cases that are so out of the reality that instead discuss everything and lose the battle because "you are against everything" I opt to "Yes, sir" and when asks for a date I reply, I can't give a date for a project where requires to resolve so many "unknown" compatibility issues we will find. So, I'll do it but I'm not responsible for the deadline. The reality is that it is a hypothetical scenario and it can works well, but is far from reality if you want to do it for march, how many people are involved in the project?
-- If you think the chess rules are not fair, first beat Anand, Kasparov and Karpov then you can change them. Moral is, don't question the work of others if you don't know the reason why they did it.
-
Chris S Kaiser wrote:
Nope. Your sane. This is rediculous.
Phew! That's a relief. :)
Chris S Kaiser wrote:
What about arguments supporting Mono?
I tried that route. It was like trying to sell flamethrowers to retarded eskimos.
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle:laugh::laugh::laugh: Yer screwed then. :doh:
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
To me the scenario sound so "ideal" that looks like somebody took it from a book as it is and giving the requirements having zero notions about "reality". I don't know how complex the application will be, but will appears several problems to interact C# with C++ throw just XML, unless it can export simple data the recursive object serialization/deserialization will take a good amount of time, especially because C++ doesn't have reflection, so you can't scan the types on the fly, so the data to be interchanged between the layers has to be "hard" defined in the code and every data to be serialized/deserialized in C++ will have to come with a helper function to do the serialization/deserialization. Also if in a future part of the app can run on Linux then also you can’t make like a simple dll for the C++ functionality or you could but then when this portion runs on Linux, the client would not be able to connect to the server portion. So you better think from the very beginning run the C++ as different process but now that brings other problem how to interchange the data. You can’t use remoting because is MS dependant, so you will have to run a TCP pipe between the two process, and what you do? You will have to use a proprietary binary protocol to send the XML transaction back and forth…. Or install a HTTP server and send HTTP request/response from the client application. Mmmm how many problems I see with that requirement. For me those are cases that are so out of the reality that instead discuss everything and lose the battle because "you are against everything" I opt to "Yes, sir" and when asks for a date I reply, I can't give a date for a project where requires to resolve so many "unknown" compatibility issues we will find. So, I'll do it but I'm not responsible for the deadline. The reality is that it is a hypothetical scenario and it can works well, but is far from reality if you want to do it for march, how many people are involved in the project?
-- If you think the chess rules are not fair, first beat Anand, Kasparov and Karpov then you can change them. Moral is, don't question the work of others if you don't know the reason why they did it.
You mention many good points. I brought some of those issues up and the general reply from mgmt was "Don't burden me with details, just get it done."
CastorTiu wrote:
how many people are involved in the project?
They had 6 devs, but soon they will only have 5. (I resigned)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
:laugh::laugh::laugh: Yer screwed then. :doh:
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
Chris S Kaiser wrote:
Yer screwed then.
No, they are. I resigned. :laugh:
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Chris S Kaiser wrote:
Yer screwed then.
No, they are. I resigned. :laugh:
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleHaha.. that's what I get for not reading the thread before replying. :laugh:
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
You mention many good points. I brought some of those issues up and the general reply from mgmt was "Don't burden me with details, just get it done."
CastorTiu wrote:
how many people are involved in the project?
They had 6 devs, but soon they will only have 5. (I resigned)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleWOW :) I admire you. How I'd like to that in those cases... but I can't :~ I'm tie to my employer for another year. >> "Don't burden me with details, just get it done." Details?? that's why the project is kind out of the reality because they don't know the details. -- modified at 20:45 Thursday 25th January, 2007 [EDIT] I think it can be done before March with 5 or 6 people with good management, but looks like is especially what your company lacks, a good management.
-- If you think the chess rules are not fair, first beat Anand, Kasparov and Karpov then you can change them. Moral is, don't question the work of others if you don't know the reason why they did it.
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Anyone who adds features or design constraints because they might someday need them is certifiable, and will soon be broke and out of business. If there is no solid business case for a feature, forget it. I would have found another job too, simply because that employer clearly isn't going to be an employer much longer...