Difficult Projects
-
David Knechtges wrote:
interfacing it with the Micros ISLs for the Micros POS. It communicates with the C# server library using WCF (which I had not used before).
I beg your pardon for my ignorance, how's anything "Micro" or "Embedded" to understand WCF? I'd explore just plan socket on both end (hope string/int representation be same on both ends)
dev
Well, Micros is the POS application - one that is used in many retail stores and restaurants. It is PC based with a way to run custom DLLs - which are native code interface DLLs. The embedded system I am using is communicated with over a 900MHz radio. The PC communicates with it using an antenna attached to it that runs on an RS232 port on the PC. So essentially, what I have is: 1 or more Micros POS terminals talking to my custom C# server over WCF (using C++/CLI to wrap the classes/communications) C# server communicating with the embedded system using the antenna on the RS232 port C# server communicating with a IIS web server on the same intranet C# server communicating with another windows application over WCF on the same intranet Sheesh, even me writing it out is confusing!
-
Well, Micros is the POS application - one that is used in many retail stores and restaurants. It is PC based with a way to run custom DLLs - which are native code interface DLLs. The embedded system I am using is communicated with over a 900MHz radio. The PC communicates with it using an antenna attached to it that runs on an RS232 port on the PC. So essentially, what I have is: 1 or more Micros POS terminals talking to my custom C# server over WCF (using C++/CLI to wrap the classes/communications) C# server communicating with the embedded system using the antenna on the RS232 port C# server communicating with a IIS web server on the same intranet C# server communicating with another windows application over WCF on the same intranet Sheesh, even me writing it out is confusing!
-
The project I am working on now is pretty tough. Was wondering about some other projects that others here have worked on that were ultimately successful? This project I am working on involves taking a C# library running on one server type machine, and interfacing it with the Micros ISLs for the Micros POS. It communicates with the C# server library using WCF (which I had not used before). Of course, Micros uses native DLLs so I had to write C++/CLI wrappers for everything else too. In addition, this C# library I wrote has to load an embedded system and put the Micros sales into our web server. It is going to work, as I prototyped it a while ago, but now I am deep in the muck of implementation..... I will get quite a bit of personal satisfaction when this project is working, especially since my company has paid for 2 different implementations of POS software that ultimately did not work and cost a small fortune.
AFAIK none of the projects I've worked on has failed, although that might be a reflection of the fact that most of them were engineering type projects (digital broadcasting, defence, marine navigation etc.) rather than internal line of business systems. The hardest one was undoubtedly the first team I led. We were developing an automatic test system for helicopter avionics, in conjunction with our arch competitor in order to stitch up another competitor. Although it was technically tricky, the worst aspects were political in nature - and the politics went all the way down to the dev teams. Every lunchtime the team leaders were receiving faxes from their opposite numbers stating "please respond by close of play today" - and that was just the start of it. Put a foot wrong and you effectively had the management of both companies on your back. It was horrible, but I survived and learnt a great deal from it - most notably when to stick your neck out and say "No. I don't care what they say - it cannot work this way" (I did, and although it caused a huge row which went on for months I was eventually vindicated) and when to just get on with it as best you can. Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide. No matter how stressful a job becomes, nothing should ever come to that.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
okay, clear. Thought you are saying embedded system is communicating with a windows box via WCF!!!
dev
Clearly what is meant is that the application that communicates uses WCF (but an existing driver probably exists to do all the low-level bits) So the application can use the higher-level functionality provided by the drivers and windows to open sockets or rawIO connections. On the Project itself, it seems to me (Sorry if this offends) that the design of the system (not application) is flawed. It's like using a sledgehammer to whack in nails, and while it will work it may be a little over-engineered. Truely the POS equipment / software for scanners should interface to the DB already (how it gets it's prices anyway) and you could then just add-in some SQL triggers to decrement "instock" (or similar) of item. Raising a purchase ledger (should be done automatically through stock system), can then be stored online, but it should only ever be stock, prices and promo's that are read by online anyway... Just my two-cents, but might have saved you a lot of headache. Difficult projects for me are all about difficult clients, they either have other contractors in poking about what you've done breaking things, or they change their mind about what they want (both result in a fresh bill)
-
Clearly what is meant is that the application that communicates uses WCF (but an existing driver probably exists to do all the low-level bits) So the application can use the higher-level functionality provided by the drivers and windows to open sockets or rawIO connections. On the Project itself, it seems to me (Sorry if this offends) that the design of the system (not application) is flawed. It's like using a sledgehammer to whack in nails, and while it will work it may be a little over-engineered. Truely the POS equipment / software for scanners should interface to the DB already (how it gets it's prices anyway) and you could then just add-in some SQL triggers to decrement "instock" (or similar) of item. Raising a purchase ledger (should be done automatically through stock system), can then be stored online, but it should only ever be stock, prices and promo's that are read by online anyway... Just my two-cents, but might have saved you a lot of headache. Difficult projects for me are all about difficult clients, they either have other contractors in poking about what you've done breaking things, or they change their mind about what they want (both result in a fresh bill)
-
AFAIK none of the projects I've worked on has failed, although that might be a reflection of the fact that most of them were engineering type projects (digital broadcasting, defence, marine navigation etc.) rather than internal line of business systems. The hardest one was undoubtedly the first team I led. We were developing an automatic test system for helicopter avionics, in conjunction with our arch competitor in order to stitch up another competitor. Although it was technically tricky, the worst aspects were political in nature - and the politics went all the way down to the dev teams. Every lunchtime the team leaders were receiving faxes from their opposite numbers stating "please respond by close of play today" - and that was just the start of it. Put a foot wrong and you effectively had the management of both companies on your back. It was horrible, but I survived and learnt a great deal from it - most notably when to stick your neck out and say "No. I don't care what they say - it cannot work this way" (I did, and although it caused a huge row which went on for months I was eventually vindicated) and when to just get on with it as best you can. Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide. No matter how stressful a job becomes, nothing should ever come to that.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
Anna-Jayne Metcalfe wrote:
Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide.
Glad I never come even close! Colleague suicide!? That's unheard of. My superior officer (luckily) has very steady mind and never breakdown (even if our system does)
dev
-
Anna-Jayne Metcalfe wrote:
Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide.
Glad I never come even close! Colleague suicide!? That's unheard of. My superior officer (luckily) has very steady mind and never breakdown (even if our system does)
dev
It came as a huge shock to all of us. Never again.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
AFAIK none of the projects I've worked on has failed, although that might be a reflection of the fact that most of them were engineering type projects (digital broadcasting, defence, marine navigation etc.) rather than internal line of business systems. The hardest one was undoubtedly the first team I led. We were developing an automatic test system for helicopter avionics, in conjunction with our arch competitor in order to stitch up another competitor. Although it was technically tricky, the worst aspects were political in nature - and the politics went all the way down to the dev teams. Every lunchtime the team leaders were receiving faxes from their opposite numbers stating "please respond by close of play today" - and that was just the start of it. Put a foot wrong and you effectively had the management of both companies on your back. It was horrible, but I survived and learnt a great deal from it - most notably when to stick your neck out and say "No. I don't care what they say - it cannot work this way" (I did, and although it caused a huge row which went on for months I was eventually vindicated) and when to just get on with it as best you can. Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide. No matter how stressful a job becomes, nothing should ever come to that.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
Anna-Jayne Metcalfe wrote:
one of the hardware engineers on the team committed suicide
That happened to us earlier this year :omg:. While I'm sure job stress contributed (the company is under Chapter 11 bankruptcy proceedings), we believe his suicide was mostly motivated by a health concern.
Software Zen:
delete this; -
The project I am working on now is pretty tough. Was wondering about some other projects that others here have worked on that were ultimately successful? This project I am working on involves taking a C# library running on one server type machine, and interfacing it with the Micros ISLs for the Micros POS. It communicates with the C# server library using WCF (which I had not used before). Of course, Micros uses native DLLs so I had to write C++/CLI wrappers for everything else too. In addition, this C# library I wrote has to load an embedded system and put the Micros sales into our web server. It is going to work, as I prototyped it a while ago, but now I am deep in the muck of implementation..... I will get quite a bit of personal satisfaction when this project is working, especially since my company has paid for 2 different implementations of POS software that ultimately did not work and cost a small fortune.
The most difficult job I've worked on in recent memory was a contract job I did on the side. We had a couple interface libraries for a piece of hardware we were using. The libraries were horribly buggy. The manufacturer supplied source code for all but the core library that handled communications with their device driver. The code was awful. It looked like it had been written by an E.E. intern with one class in C++. We had to replace all but the core library, and that we had to develop workarounds for ridiculous bugs. The worst was having to place
Sleep(1)calls after most calls to the core library. They were doing something odd with threading, and the calls wouldn't execute unless you forced a thread switch immediately after the call. We would have replaced the core library as well, but the manufacturer refused to give us their existing source code or even a spec for communicating with their driver. Of course, all of this is happening on a job that was running behind schedule. I was lucky; I only lost $2500 on the job. The guy doing the hardware, whom I was working for, lost more.Software Zen:
delete this; -
AFAIK none of the projects I've worked on has failed, although that might be a reflection of the fact that most of them were engineering type projects (digital broadcasting, defence, marine navigation etc.) rather than internal line of business systems. The hardest one was undoubtedly the first team I led. We were developing an automatic test system for helicopter avionics, in conjunction with our arch competitor in order to stitch up another competitor. Although it was technically tricky, the worst aspects were political in nature - and the politics went all the way down to the dev teams. Every lunchtime the team leaders were receiving faxes from their opposite numbers stating "please respond by close of play today" - and that was just the start of it. Put a foot wrong and you effectively had the management of both companies on your back. It was horrible, but I survived and learnt a great deal from it - most notably when to stick your neck out and say "No. I don't care what they say - it cannot work this way" (I did, and although it caused a huge row which went on for months I was eventually vindicated) and when to just get on with it as best you can. Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide. No matter how stressful a job becomes, nothing should ever come to that.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
I find any code I work on is getting harder - it sucks to get old.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
The most difficult job I've worked on in recent memory was a contract job I did on the side. We had a couple interface libraries for a piece of hardware we were using. The libraries were horribly buggy. The manufacturer supplied source code for all but the core library that handled communications with their device driver. The code was awful. It looked like it had been written by an E.E. intern with one class in C++. We had to replace all but the core library, and that we had to develop workarounds for ridiculous bugs. The worst was having to place
Sleep(1)calls after most calls to the core library. They were doing something odd with threading, and the calls wouldn't execute unless you forced a thread switch immediately after the call. We would have replaced the core library as well, but the manufacturer refused to give us their existing source code or even a spec for communicating with their driver. Of course, all of this is happening on a job that was running behind schedule. I was lucky; I only lost $2500 on the job. The guy doing the hardware, whom I was working for, lost more.Software Zen:
delete this;Hahahaha, reminds me of a conveyor project I did once. The system was supposed to support 2 transactions a second and communicate them to a DEC VAX via a software package of theirs called PAMS. They claimed it was as reliable as the mail in communications. At first they wanted the network card in my sort controller but I refused because my system was heavily interrupt driven and I had another computer specified that my program would send the transaction to through RS-232 communications and from that computer into the VAX via their interface card. Best decision I ever made. Even though they knew the transactions were going to come in at 2 per second, their interface protocol would take 15 seconds (per transaction!) to determine if the VAX was down before they would store the transaction locally and then return control to my communications software. They disabled interrupts during that time so I couldn't use interrupts to receive my transactions, but had to resort to using the Clear To Send pin to mediate communication between my sort controller and the communications computer. It was even more hilarious when communications with the VAX was reestablished and their software seized control once again until all the backed up transactions had been transmitted. Should I be cruel and mention they did not dynamically allocate disk buffer space for the locally saved transactions but instead predefined the buffer size and locked up when it became full? Of course DEC was not going to take the blame, instead of sending a programmer to meetings with the client, they sent a lawyer. I finally said I was willing to throw down printouts of my code for them to crawl over and tell me where I had gone wrong. Were they willing to do the same? They finally conceded that there might be a problem with their interface card. It would have been far less of a hassle if they had let me write the communications protocol to the VAX as well, but hey, I was not an employee of the All and Powerful Digital Equipment Corporation, so what did I know?
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
It was both a reply to you and the OP, most was for the OP but the first bit was for you "Clearly what is meant is that the application that communicates uses WCF (but an existing driver probably exists to do all the low-level bits) So the application can use the higher-level functionality provided by the drivers and windows to open sockets or rawIO connections." This was a reply to your comment "okay, clear. Thought you are saying embedded system is communicating with a windows box via WCF!!!" Which was also a reply (not to the OP) :-\
-
I worked real hard to eliminate any innuendo from my post. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
My grandmother used to have a word of advice on getting old. She said, "Don't."
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
It was both a reply to you and the OP, most was for the OP but the first bit was for you "Clearly what is meant is that the application that communicates uses WCF (but an existing driver probably exists to do all the low-level bits) So the application can use the higher-level functionality provided by the drivers and windows to open sockets or rawIO connections." This was a reply to your comment "okay, clear. Thought you are saying embedded system is communicating with a windows box via WCF!!!" Which was also a reply (not to the OP) :-\
-
Anna-Jayne Metcalfe wrote:
one of the hardware engineers on the team committed suicide
That happened to us earlier this year :omg:. While I'm sure job stress contributed (the company is under Chapter 11 bankruptcy proceedings), we believe his suicide was mostly motivated by a health concern.
Software Zen:
delete this;I'm so sorry to hear that. :rose: Regardless of the cause, when someone takes their own life it's a tragedy that could probably have been avoided if they had the right support around them in the first place.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
ouch! looking back I am sure you can say I saw some signs. I have been stressed but never that stressed.
To err is human to really mess up you need a computer
We were all under severe pressure, but everyone absorbs that pressure in a different way. Looking back it at, the engineer who took his life didn't seem to show the stress everyone else was obviously carrying around. I now know that that's a warning sign - when someone internalises severe stress, it can build up to a point where they can't contain it anymore, and something has to give. In that position I know I'll end up crying, screaming (usually back at whoever is dumping on me) or taking it out on some inanimate object (TV remotes do make a satisfying cracking noise when you hurl them at a wall....). He did none of that - just kept taking it until he popped. :(
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
BrainiacV wrote:
She said, "Don't."
She say how? (I don't want to use the one sure-fire method to do so. My sister was 20 years older than me, now I'm 9 years older than her.)
-
AFAIK none of the projects I've worked on has failed, although that might be a reflection of the fact that most of them were engineering type projects (digital broadcasting, defence, marine navigation etc.) rather than internal line of business systems. The hardest one was undoubtedly the first team I led. We were developing an automatic test system for helicopter avionics, in conjunction with our arch competitor in order to stitch up another competitor. Although it was technically tricky, the worst aspects were political in nature - and the politics went all the way down to the dev teams. Every lunchtime the team leaders were receiving faxes from their opposite numbers stating "please respond by close of play today" - and that was just the start of it. Put a foot wrong and you effectively had the management of both companies on your back. It was horrible, but I survived and learnt a great deal from it - most notably when to stick your neck out and say "No. I don't care what they say - it cannot work this way" (I did, and although it caused a huge row which went on for months I was eventually vindicated) and when to just get on with it as best you can. Others weren't so lucky. The software manager on my site (my immediate boss) had a nervous breakdown amid a festering pile of fantasy Gantt charts and left the project for less stressful pastures, and one of the hardware engineers on the team committed suicide. No matter how stressful a job becomes, nothing should ever come to that.
Anna :rose: Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
Yes I agree. Politics is always the problem in Software Development. Too bad the colleges and Uni's don't invest as much time in teaching their studuents how to manage stress, idiot project managers and hostile customers as they do the "best and most perfect" design.
