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[
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...
-
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[
Hi Josh, My thoughts on this are: The user is depending on the server in some way, so it should start as server app that provides the user with the needed data, with a user (client) part that takes care for the user part of the experience. So you need both parts since a fat client is an extended client program that relies partially on the server but is almost standalone. Since they want to be independent in choosing the platform it runs on the server part of the application, it should be written in C++ since it works as a unmanaged standalone application on linux and windows and provides the needed functionallity on both platforms. So there should be a programm written that provides the fat clients needs. The task is to communicate by XML between both sides and to establish business rules between both parts to establish data exchange and commands from the client side of the application. The Server and client parts needs to have some methods to add, or delete the tables and field in the database and the client side can order these changes to take place, so you need a flexible repeating system to keep both databases the same with altering or creating on both sides the edit, insert, update and delete commands and also the creation and deleting of tables and fields and the methods i named, plus the screens on both parts to work with them including the menu options etc. I a way they ask you to write a flexibe server client enviroment:)
With friendly greetings,:) Eric Goedhart Interbritt
-
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:
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."
It's amazing how management can entirely miss the irony. I've heard that it was snowing recently in Bullhead Arizona, but really, there is zero chance this is going to be done "sometime in March". :)
Chris Meech I am Canadian. [heard in a local bar] I agree with you that my argument is useless. [Red Stateler] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
-
Josh Smith wrote:
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."
It's amazing how management can entirely miss the irony. I've heard that it was snowing recently in Bullhead Arizona, but really, there is zero chance this is going to be done "sometime in March". :)
Chris Meech I am Canadian. [heard in a local bar] I agree with you that my argument is useless. [Red Stateler] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
Chris Meech wrote:
I've heard that it was snowing recently in Bullhead Arizona,
Conclusively proving that, contrary to some rumors, Bullhead is not Hell.
-
Josh Smith wrote:
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."
It's amazing how management can entirely miss the irony. I've heard that it was snowing recently in Bullhead Arizona, but really, there is zero chance this is going to be done "sometime in March". :)
Chris Meech I am Canadian. [heard in a local bar] I agree with you that my argument is useless. [Red Stateler] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
-
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...
Rob Graham wrote:
and will soon be broke and out of business
I highly doubt that. I forgot to mention that in this "hypothetical situation" the employer is a multi-billion dollar financial services firm. Small companies must be run by samurais if they are to survive. Big companies have lots and lots of room for "blubber."
: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. - AristotleSeriously?
-
Hi Josh, My thoughts on this are: The user is depending on the server in some way, so it should start as server app that provides the user with the needed data, with a user (client) part that takes care for the user part of the experience. So you need both parts since a fat client is an extended client program that relies partially on the server but is almost standalone. Since they want to be independent in choosing the platform it runs on the server part of the application, it should be written in C++ since it works as a unmanaged standalone application on linux and windows and provides the needed functionallity on both platforms. So there should be a programm written that provides the fat clients needs. The task is to communicate by XML between both sides and to establish business rules between both parts to establish data exchange and commands from the client side of the application. The Server and client parts needs to have some methods to add, or delete the tables and field in the database and the client side can order these changes to take place, so you need a flexible repeating system to keep both databases the same with altering or creating on both sides the edit, insert, update and delete commands and also the creation and deleting of tables and fields and the methods i named, plus the screens on both parts to work with them including the menu options etc. I a way they ask you to write a flexibe server client enviroment:)
With friendly greetings,:) Eric Goedhart Interbritt
You bring up a lot of great ideas. The problem is, they make too much for sense the hypothetical situation to which I refer. :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Seriously?
code-frog wrote:
Seriously?
100% serious, my man. As they say, "homey don't play dat."
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Josh Smith wrote:
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."
It's amazing how management can entirely miss the irony. I've heard that it was snowing recently in Bullhead Arizona, but really, there is zero chance this is going to be done "sometime in March". :)
Chris Meech I am Canadian. [heard in a local bar] I agree with you that my argument is useless. [Red Stateler] Hey, I am part of a special bread, we are called smart people [Captain See Sharp] The zen of the soapbox is hard to attain...[Jörgen Sigvardsson] I wish I could remember what it was like to only have a short term memory.[David Kentley]
Chris Meech wrote:
It's amazing how management can entirely miss the irony.
Considering the crackhead ideas they produce, I must disagree with you. :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
You bring up a lot of great ideas. The problem is, they make too much for sense the hypothetical situation to which I refer. :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleNo the problem was that i was a little drunk and getting a little sober the same time since since my six pack was finsihed while being confronted with a hypothetical situation:)
With friendly greetings,:) Eric Goedhart Interbritt
-
code-frog wrote:
Seriously?
100% serious, my man. As they say, "homey don't play dat."
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleI think that's very cool. You did your employer a favor. You got out of their way so that if they are intent on this they can find the right people and shake it out. You also did them a favor by sending a strong message that maybe they are on the wrong track.:cool:
-
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[
What is Enterprisey[^]? For the win Alex.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -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[
Why write *any* of it in C# - write it all in C++ with MFC/WTL/wxWindows (plus generous helpings of Boost (the serialisation library could be handy) - then the interop problems go away (apart from the inconvenient thing that none of you have C++ experience). All uses of XML in that scenario are dumb - the rules engine would be better off using a DSL and custom parser, I suspect. The database schema changing thing doesn't sound too tricky - the queries need to be written to just fetch all columns (the joins would stay invariant, I presume) and obviously you need to query the schema for column details. The biggest issue of the lot is the obvious disconnect between management and the proletarian rabble ;P PS - have you mentioned Mono[^] to the management at all? Cross -platform in .NET...although I don't know what the class library's like.