steveintoronto
Superstar
I'm not a software engineer, by any means. By I do design and build logic circuits in the equipment and I design and build, mostly for user interface to prevent conflicting commands. I'm a tech. Mostly hardware, mostly audio, and a lot of 'glass audio' with logic controlled channel switching. Worked in three nations on two continents with it. Nuff said on that...
Why?
Because.
C'mon. You mean to tell me that Presto's and the transfer issuing machines coding (most likely I2C or Python or upscaled equiv in the latter's case for most of its operation) aren't written with options to be enabled by simple 'yes' or 'no' tags attached?Of course it's possible, but the effort required to do it is likely not worth it. As someone who works in software, I know that even minor changes can sometimes take a lot of effort to implement. They need to go through the whole software development life cycle which includes updating all sorts of documentation with the changes being made, doing the actual coding, and doing thorough testing before implementing the change.
Huh? On what basis do you reach that conclusion? Are you inferring that the success is based on how transfers are honoured or not upon inspection?Another issue with implementing 2 hour transfers on King immediately is that you'd no longer be able to measure success of the pilot accurately.
I suggest your 'reprogram' your thinking processing. Let me reduce the logic inherent in your process: "You can't do that".How would you be able to know whether an increase in ridership was the result of the pilot, or the result of 2 hour transfers being implemented?
Why?
Because.
Last edited: