Design change...so just move the washer/dryer to the other wall?
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
kmoorevs wrote:
employees working different shifts of non-contiguous hours.
I can think of a couple. On call contractors Law enforcement, First, Second, Power Shift (Power shift, are just added people offset between Second and Third Shift), and Third Shift.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
It's only a small step from senior to senile :-\
-
what? surely the presentation layer is fully separate from the business logic? I think somebody missed a few too many classes.
Signature ready for installation. Please Reboot now.
-
kmoorevs wrote:
employees working different shifts of non-contiguous hours.
I can think of a couple. On call contractors Law enforcement, First, Second, Power Shift (Power shift, are just added people offset between Second and Third Shift), and Third Shift.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
even 24 hour shops, supermarkets and food outlets have this. OP perhaps hard coded too much "logic" or/an assumptions of what/when shifts are. Doing a similar project for a manufacturing company, in particular they want to capture real project man hours, sure they very concisely told me what the typical scenario is including a very precise definition of what a "shift" was (need to to capture OT) - there were no exceptions. 3 months on there's never been a single job that fit the standard scenario, and yes, what they define as a shift now has variants (heck, what they define as a "man hour" has variants.) There's nothing to hard code, but regardless there nothing that should be hard coded. For sure shifts have nothing to do with time of day, duration, break intervals... and even less to do with any other shifts parameters even in the same role. I don't understand the OP's issue - regardless situation if "shifts" overlap or not (which seems to be his "problem") should have been irrelevant from the very start. Sounds like a very poor implementation, and I will go as far to say there's really no excuse for that.
Signature ready for installation. Please Reboot now.
-
even 24 hour shops, supermarkets and food outlets have this. OP perhaps hard coded too much "logic" or/an assumptions of what/when shifts are. Doing a similar project for a manufacturing company, in particular they want to capture real project man hours, sure they very concisely told me what the typical scenario is including a very precise definition of what a "shift" was (need to to capture OT) - there were no exceptions. 3 months on there's never been a single job that fit the standard scenario, and yes, what they define as a shift now has variants (heck, what they define as a "man hour" has variants.) There's nothing to hard code, but regardless there nothing that should be hard coded. For sure shifts have nothing to do with time of day, duration, break intervals... and even less to do with any other shifts parameters even in the same role. I don't understand the OP's issue - regardless situation if "shifts" overlap or not (which seems to be his "problem") should have been irrelevant from the very start. Sounds like a very poor implementation, and I will go as far to say there's really no excuse for that.
Signature ready for installation. Please Reboot now.
Lopatir wrote:
what/when shifts are.
Makes me wonder, if there isn't a component to it to find unscheduled work hours / periods. Though that should be equally configurable.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
I think you need to talk with your so called senior partner and put the idea on paper first and tackle all the problems that may arise implementing the new requirement.Then document the design change (including UI and BL) in a new design document and do a review and both of you agree that this is what is needed to be done to achieve the solution to your new customer. Then you could design your objects, classes and functional business logic as a separate layer and then implement test cases for your processing function to ensure that all the outcomes and test are covered. You need to implement functions that take into consideration the duty,shift,24hrs....then I'm sure you knew all this already...
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
We are in the beginning of a mass extinction. - Greta Thunberg
-
I think you need to talk with your so called senior partner and put the idea on paper first and tackle all the problems that may arise implementing the new requirement.Then document the design change (including UI and BL) in a new design document and do a review and both of you agree that this is what is needed to be done to achieve the solution to your new customer. Then you could design your objects, classes and functional business logic as a separate layer and then implement test cases for your processing function to ensure that all the outcomes and test are covered. You need to implement functions that take into consideration the duty,shift,24hrs....then I'm sure you knew all this already...
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
abmv wrote:
Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things
And money is made by early risers catering to lazy men and giving them the products they wish for.
The difficult we do right away... ...the impossible takes slightly longer.
-
even 24 hour shops, supermarkets and food outlets have this. OP perhaps hard coded too much "logic" or/an assumptions of what/when shifts are. Doing a similar project for a manufacturing company, in particular they want to capture real project man hours, sure they very concisely told me what the typical scenario is including a very precise definition of what a "shift" was (need to to capture OT) - there were no exceptions. 3 months on there's never been a single job that fit the standard scenario, and yes, what they define as a shift now has variants (heck, what they define as a "man hour" has variants.) There's nothing to hard code, but regardless there nothing that should be hard coded. For sure shifts have nothing to do with time of day, duration, break intervals... and even less to do with any other shifts parameters even in the same role. I don't understand the OP's issue - regardless situation if "shifts" overlap or not (which seems to be his "problem") should have been irrelevant from the very start. Sounds like a very poor implementation, and I will go as far to say there's really no excuse for that.
Signature ready for installation. Please Reboot now.
Lopatir wrote:
I don't understand the OP's issue
Agreed...it was a rant. To clarify, the issue is whether or not to allow manual edits for multiple shifts in the same view.
Lopatir wrote:
Sounds like a very poor implementation
That's presumptive based on the facts given. I was purposefully vague to avoid being tagged as a programming question. No question, no problem, just a rant. :)
"Go forth into the source" - Neal Morse
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
kmoorevs wrote:
employees working different shifts of non-contiguous hours.
I don't see why the computer should care. WHere I work, now, aside from those who earn overtime (ad-hoc hours), there are about six different schedules that overlap to varying degrees - they never abut.
Two cases really exist:1. Totally random starting times for shifts.
2. Specific sets of hours scattered throughout the day.The first requires values to be set as their schedule The second can use a lookup table (in database) for scheduling sanctioned sets of hours. One could add further complexity: * Random hours vary continuously. Just get a time-clock and read-back the data. * Fixed hours change daily (lookup schedule for employees on days 0-6), but are constant with respect to the day of the week. So - if any sort of regular scheduling exists, create hours list in table and assign them for each day of the week, reference back to the worker. All of this, of course, will work fine for a standard office with a fixed schedule. Just hope you don't have to set up the schedule. Too much info.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Lopatir wrote:
I don't understand the OP's issue
Agreed...it was a rant. To clarify, the issue is whether or not to allow manual edits for multiple shifts in the same view.
Lopatir wrote:
Sounds like a very poor implementation
That's presumptive based on the facts given. I was purposefully vague to avoid being tagged as a programming question. No question, no problem, just a rant. :)
"Go forth into the source" - Neal Morse
-
kmoorevs wrote:
employees working different shifts of non-contiguous hours.
I don't see why the computer should care. WHere I work, now, aside from those who earn overtime (ad-hoc hours), there are about six different schedules that overlap to varying degrees - they never abut.
Two cases really exist:1. Totally random starting times for shifts.
2. Specific sets of hours scattered throughout the day.The first requires values to be set as their schedule The second can use a lookup table (in database) for scheduling sanctioned sets of hours. One could add further complexity: * Random hours vary continuously. Just get a time-clock and read-back the data. * Fixed hours change daily (lookup schedule for employees on days 0-6), but are constant with respect to the day of the week. So - if any sort of regular scheduling exists, create hours list in table and assign them for each day of the week, reference back to the worker. All of this, of course, will work fine for a standard office with a fixed schedule. Just hope you don't have to set up the schedule. Too much info.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
Ill give you two options 1: a system will work for 90% of use cases, covers 99.9% of information being generated, but someone will need to spend lots of time setting up and managing the schedules. 2: a system which requires minimal management but only works for 20% of use cases but covers 95% of the information trying to generate. bonus option: I take 2 years training in Machine Learning, then come back and give you a solution of with the benefits of both.
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
Although I can understand your frustration, my immediate thought is that maybe the real reason for your frustration is the software design rather than your serious partner. Maybe you should take it as a hint to go for a major resign that allows for future changes of similar kinds without lots of plumbing and rewiring.
-
even 24 hour shops, supermarkets and food outlets have this. OP perhaps hard coded too much "logic" or/an assumptions of what/when shifts are. Doing a similar project for a manufacturing company, in particular they want to capture real project man hours, sure they very concisely told me what the typical scenario is including a very precise definition of what a "shift" was (need to to capture OT) - there were no exceptions. 3 months on there's never been a single job that fit the standard scenario, and yes, what they define as a shift now has variants (heck, what they define as a "man hour" has variants.) There's nothing to hard code, but regardless there nothing that should be hard coded. For sure shifts have nothing to do with time of day, duration, break intervals... and even less to do with any other shifts parameters even in the same role. I don't understand the OP's issue - regardless situation if "shifts" overlap or not (which seems to be his "problem") should have been irrelevant from the very start. Sounds like a very poor implementation, and I will go as far to say there's really no excuse for that.
Signature ready for installation. Please Reboot now.
When systems collide... We have one system that tracks time/costs. Another that generates work. Load the work, get the costs. LONG AFTER Implementation, they mention parallel efforts? Oh, so we have a MACHINE that cuts stuff up. We load it, cut it, move to the next load. Oh, but that next load was processed by hand to PREP it for loading. Oh, so we need to create a VIRTUAL Work Center that tracks that effort, because it happens in parallel. A design that makes sense, in the end, but WHERE was the original business analyst that approved the first version that we coded to? Oh, they had NEVER TALKED to a single actual worker. The ONLY watched the first shift, while starting, that does not have this opportunity, so it looked like 2 steps on one machine. Don't get me started about the COST of going to lunch when they forgot to hit the right button on the machine! LOL
-
I hate it when my senior partner gets an idea in her head, like changing the presentation/logic for an application without understanding how much plumbing and re-wiring will be required to implement. :sigh: (while at the same time remaining largely unchanged for a previous customer) BTW, it's a totally weird situation with a new customer where they have employees working different shifts of non-contiguous hours. :confused: I've now spent almost a week on a solution that apparently doesn't fit with the vision. X| Oh well, time to break out the jackhammer! :laugh:
"Go forth into the source" - Neal Morse
Programming is a good way to prove to yourself that everything you think you know about the universe is wrong. You think shifts are contiguous? Someone out there disagrees. The company I work for tracks vehicles and as part of that we record the VIN of the vehicle. The program was originally written to require VINs be unique but then we ran into a set of vehicles that lie and always say their VIN is 00000. So we had to go and remove the requirement that VINs be unique.
