DfcukinLite t1_jawjv2e wrote
They tried to fix the timing 8 years ago and there’s a reason it wasn’t fixed. If I recall it was because they legitimately can’t
meeroth OP t1_jawm7rj wrote
This seems highly unlikely. Traffic lights have timers inside. If every light operates on a 60-second cycle for example, it’s possible for the whole road’s worth of signals to be timed perfectly. This is extremely basic traffic engineering. You do not need a graduate degree to understand the science here. And if the timer in a particular control box is broken, replace the timer.
DfcukinLite t1_jawnblj wrote
DfcukinLite t1_jawmdl2 wrote
It’s not unlikely. They literally tired 8 years ago to no avail, because they can’t.
meeroth OP t1_jawn11o wrote
I should clarify that I think the “we can’t” statement is likely a cop-out or flat-out lie. Not that they didn’t try. Sorry for not being clearer.
baltinerdist t1_jawsa2b wrote
Often times "we can't" in a software system does not mean it is a technologically impossible problem. It means that whatever effort is required to solve the problem way outweighs the value represented by solving it.
That can be true of even things that have tremendous value. If creating one feature that everybody will absolutely love takes 500 hours and with that time, you could build 25 other features and bugfixes, sometimes you just have to get the 25 in favor of the one.
That often means the one 500 hour feature will never get built because you will never just have 500 hours available at one time to burn on a single fix or enhancement. And some projects don't have the capability to be incrementally solved, aka we'll budget 10 hours for it this month and that will give us a small improvement. It could very well be that 490 hours don't get you a useable change, only the last 10 hours that wraps it up makes it useable.
Likewise if you can afford to budget 10 hours a month to it, that means it's going to be 50 months before it will ever go live. And in that time, there will be hundreds of other changes to the system that will have to be compatible with the one major feature, which means adding however many hours to the 500 to account for how the system has evolved since you started it.
Lastly, you can sometimes shave off time by putting multiple developers onto a project, but at a certain point, you can't put more people in the same work stream because they won't have anything they can do or they'll get in each other's ways. You can absolutely have two or three or four chefs cracking eggs and stirring batter and making icing, but eventually that cake goes in the oven and it's going to take as long as it takes to bake, no less and no more, no matter how many chefs you hire.
None of this is to excuse the DOT. Whatever it is they aren't doing here may not be anywhere near that complex. There could just be ineptitude at play preventing this from getting solved. But the details above might help explain this or other engineering issues you may come across.
xNetrunner t1_jax2h77 wrote
And then there's always the strong possibility that 500 hours that some group of developers will do will always be inferior to one developer who actually knows what the f*ck they're doing.
I think ^^^ is more likely the case.
baltinerdist t1_jax3omy wrote
You can also throw those 500 hours at a contractor without good oversight and end up burning tens of thousands of dollars on a crap outcome.
Viewing a single comment thread. View all comments