Having worked on similar things on a smaller scale but higher up the chain, I can tell you the list of possible issues is a mile long. Everything from lack of leadership and conflicting goals to ever-changing scopes and insufficient resources is a candidate for the big blame. A lot of people, organizations, and systems have to work well together to succeed.
As techies, we think the technical solution is the most superior solution but that is not always the case. Here is an example of something that just happened to me 2 hours ago today. User called and said osTicket system I manage treats '0' as blank. So when they fill out a form with question 'How many X happened today?' and they enter '0', the system just treats the field as unfilled and does not print '0'. That's a big problem for auditing because they absolutely need to be able to show that it was '0'. I started digging into the source code to see where '0' int was treated as a blank. osTicket being PHP where 0, '', null, and false can all be treated as FALSE, it could've been 8+ hours worth of work digging into the right piece of code to figure out the fix.
So I called the user up and we discussed the best way to handle this. In the end, I added a new question above this one: 'Did one or more X happen today? YES/NO'. If it's 'NO', it doesn't matter the 'How many X happened today?' with '0' doesn't get printed.
To make a major implementation work, this kind of discussion needs to happen 10000x a day among 1000+ people, many of whom may not have the authority to just decide things on the fly.
I would have gone for the 8 hrs option. Polluting the ui with redundant information and flow on impact to reporting potentially. The impact of saving some hrs might end up amounting to even more. Also, testing and lifecycle of this approach could be worse. And a sign of how we sometimes get carried away by tge tech definition. Why call it 1 or more tickets rather than any tickets?
That's the point I was trying to make. This was something where we could've bikeshedded for weeks with numerous interdepartmental meetings and spent way more hours than necessary to try to come to the optimal solution. Instead since both the user and I had the power to come to the final decision together, we picked this option.
If it works, then we spent less time on the business problem than I've spent writing my two comments here. If it doesn't work, we go back and decide if 8 hours to fix osTicket is worth it or not. Or maybe we find an osTicket consultant to do it for us. Or we find a hosted, mobile-friendly alternative to replace osTicket. Or we integrate this feature into our existing ERP system.
There are a million ways to do anything. Nobody has the time to do any of them in the real-world when we all have hundreds of things to do on a daily basis. The right/optimal/correct solution isn't often the most appropriate solution and vice-versa. People willing to take risks and defend their stances on difficult decisions can get work done. Otherwise you get 'Nobody Ever Got Fired for Buying IBM'.
And, often times that discussion leads to a decision maker saying - that shouldn't be the case, it's your problem, not ours that you can't handle that.
So you end up assigning someone to 8+ hours of work to do it, you also have to end up having 2-4 meetings on the topic, and on and on.
You're right, but at the same time, it's a totally unhelpful statement in a project.
Everything is bad design everywhere, at least when you're a consultant. You're generally not brought into projects that have good design, and everything's roses.
I've been on a few projects with amazing design, and it was a very different experience. I didn't even argue for more work for them, because they had it all under control.
They essentially, wanted to be confirmed how great they were. I don't know if the CIO was curious if it was true, or if they all just wanted pats on the back, but we taught them a few really detailed things they didn't know, helped on a few really tricky edge cases, and said you're golden, keep killing it.
As techies, we think the technical solution is the most superior solution but that is not always the case. Here is an example of something that just happened to me 2 hours ago today. User called and said osTicket system I manage treats '0' as blank. So when they fill out a form with question 'How many X happened today?' and they enter '0', the system just treats the field as unfilled and does not print '0'. That's a big problem for auditing because they absolutely need to be able to show that it was '0'. I started digging into the source code to see where '0' int was treated as a blank. osTicket being PHP where 0, '', null, and false can all be treated as FALSE, it could've been 8+ hours worth of work digging into the right piece of code to figure out the fix.
So I called the user up and we discussed the best way to handle this. In the end, I added a new question above this one: 'Did one or more X happen today? YES/NO'. If it's 'NO', it doesn't matter the 'How many X happened today?' with '0' doesn't get printed.
To make a major implementation work, this kind of discussion needs to happen 10000x a day among 1000+ people, many of whom may not have the authority to just decide things on the fly.