I am creating a reporting engine, it is kind of novel. The only question I have is what are some of the wierder scheduling related things you guys have seen for you cyclical computer programs to date. I am trying to cover as many fringe cases as I can, and just want a little bit of input. This would be fringe cases for example scheduling a quarterly report to be delivered 4 times a year etc.
overwraith 83 Newbie Poster
rproffitt 2,662 "Nothing to see here." Moderator
The absolute worst case scenario was time scheduling in Jordan. Same city but depending on your religious persuasion, the time differs.
Skip to about the 5 minute mark at https://www.youtube.com/watch?v=-5wpm-gesOY
So how will you deal with time without going mad?
AssertNull 1,094 Practically a Posting Shark
So how will you deal with time without going mad?
You pick ONE time zone and ONE method of dealing with time and everyone involved follows it. That, of course, requires cooperation and/or someone being in charge with the power and authority to tell everyone how it's going to be and fire anyone who refuses to cooperate. It may well not be YOUR time, but get over it. Not worth fighting over. The math really isn't that hard. It DOES require the precision of speaking with a time AND a time zone rather than "I'll meet you at 10 o'clock".
Pick Greenwich Mean Time or Pacific Time or Mountain Time or whatever, but pick ONE of them and everything gets based on that. NATO has a bunch of countries, all with a lot of pride, but the commander simply says "We're using Zulu Time" or whatever, and that's it. Watches are synchronized. Yes sir. Drive on. It seems to work. Ditto Air Traffic Controlllers. They somehow make it work.
YMMV.
happygeek commented: What he said, pick one and stick to it +16
rproffitt commented: All good, but when religion gets involved, what can I write here? +14
AssertNull 1,094 Practically a Posting Shark
but when religion gets involved, what can I write here?
What can you write here? Excellent question! We could probably compare notes with all our former consulting colleagues and write 500 pages of stories of dealing with solving time problems, or problems in general, with extremely rigid clients, religiously rigid or otherwise rigid. I'm sure we'd come up with some real doozies, problems that were never solved, most ending with "Bob finally got sick of this nonsense and he (pick one: fired the client, fired the employee, quit, had a heart attack at 30)" or "In the end, it cost 500 times more than it would have with a normal client. See that sweet boat in the driveway? It's there because I billed 5000 hours to some guy who thinks Jesus is returning to Atlanta in 2084 and all time and distance must be relative to that" or "The company went bankrupt as a result".
The young programmer in your video is in the "had a heart attack at 30" category. He's sitting around his office fielding calls from different historians, astronomers, and the "WEST BANK" (capitalized to reflect his clear belief that this was his most exasperating call). Surprise, surprise, the Israelis and the Palestinians are apparently using two different time zones. My guess is that if he takes a break from his time zone project and moves onto his mapping project, surprise surprise again, the Israelis and Palestinians aren't getting along there either and the West Bank won't be called the "West Bank" on one or both of their maps and neither will budge. No relief at all from that heart attack stress.
The young man is going to have to make a decision here, and the key here is to realize that this is an ATTITUDE decision, not a programming decision. If I may quote myself...
get over it. Not worth fighting over.
And not worth stressing over.
I want to add that he thinks his phone call with the astronomer is stressful too. It shouldn't be. He's a Computer SCIENTIST. He should be able to deal with an astronomer's phone call just fine.
Here's the rub. Computer programming is a scientific and engineering discipline and it has to be that way for it to work. Thus the rigid folks who can't accept that reality need to be dumped or need to adjust to us, not vice-versa. The reason I put military and air traffic control examples out there is that the people in charge of those things in religious countries DO accept these things and make them work, by necessity. Or their military plans fail and their planes crash. Their religion may say the world is flat or the sun revolves around the earth, but they ignore that when they fly planes. If your boss dictates that the missile must be pointy because round is not scary, you nod yes and you leave the country in the middle of the night (+rep for anyone who can name the movie this came from).
In short, as a programmer, you build programs and systems like scheduling algorithms using measurement systems accepted by the international scientific and engineering communities and you build it for the masses. If someone needs something else, it's decision time. How much am I being paid? Is it enough to deal with the extra hassle and stress?
Edited by AssertNull
rproffitt 2,662 "Nothing to see here." Moderator
How much am I being paid?
There it is. I'm sure we have stories about features that were not in the spec and so on.
Right or wrong, the client's payment as well as their ATTITUDE really sets whether the feature or issue is going to be addressed.
Some will exlaim Heresy! Then tell us we should implement this or that because we know how.
I deal with custom designs (hardware, firmware, apps and what else?) and the more I do this the more I want to see it in the spec.
AssertNull 1,094 Practically a Posting Shark
There it is.
Yes, there it is. Though sometimes not. Sometimes the money, ANY amount of money, just isn't worth it. Those times are very rare, though, in the consulting world. :)
However, when deciding your money cutoff and designing these things, very often folks focus on the immediate payoff and overlook some factors like "Can I use this code again for other clients or is it a complete stand-alone project?", "Does this project and client open or close doors to other contacts?", "Does this project add to or detract from my relevant skills and experience?", and "Can/should/must this code be maintained?" Also, sunk cost, sunk cost, sunk cost.
Quirky and rigid people have a higher incidence of stopping in the middle of the project, being unable to pay, and changing their mind without understanding the ramifications, plus they can be a hindrance to your OTHER clients if they demand that you immediately drop everything to handle their latest whim like "the missile must be pointy".
Cash up front. All of it. If it's enough money so I only have to work for you, well I'm at your service. But even then there are still a few limits, including personal pride and reputation and not wincing at the horrible code you've created.
Edited by AssertNull because: paragraphs
rproffitt 2,662 "Nothing to see here." Moderator
Should I tell? OK, I will.
For AssertNull.
It happened. A good client came up with the impossible to meet the deadline project. Since I know their thoughts on timelines I decided to dodge the bullet. How did I do that?
I don't recall my exact words but it went something like "That's a big project. I'll ask around if any of my contacts will take it on." Those were not the exact words but no one would go near the project due to the deadline. I had to find an out because I didn't want to take a reputation hit.
What happened? The project deadline came and went without any company or person accepting the job. A few months later the client brought it up again (lesson here, don't bring up projects that are an embarassment to your clients) and we chatted a bit then they revealed no one could meet the deadline and wondered if I was interested. I got the job and many months later it was delivered.
How long did they give in the first schedule? Two weeks. (Anyone remember The Money Pit?)
Sometimes it's best for take a vacation.
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.