Sanity check
-
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.
-
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. - AristotleWait until they tell you it has to be SOA. And integrate with the Oracle, BEA an IBM SOA suites. Then the XML will make sense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
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.
Hell wishes it was Bullhead.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
Wait until they tell you it has to be SOA. And integrate with the Oracle, BEA an IBM SOA suites. Then the XML will make sense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
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
Andy Brummer wrote:
What is Enterprisey[^]? For the win Alex.
Man, you hit the nail on head. Good one! :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
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.
Stuart Dootson wrote:
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.
Ah, keep in mind that all communication with the data access layer must be done via XML because it is written in C++. So, directly querying the schema is out. One option is embedding schema info in the XML resultset like <foo id="0" id_type="int" />. Another is to include the XML resultset schema in the resultset itself, but both of these options are completely absurd, IMO. Also, providing a generic means of specifying how to validate some new column in a grid is involved. When a new field is included in a query result, that new field must show up in a grid and be validated before saving it. It's possible to do, but "sometime in March" is not. Mono was mentioned earlier in this thread. No way, Jose.
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle