4 ms·
It's not a terribly hard job actually. I worked for a startup in 2004 that was doing this with haulage companies. We had 8000 data points moving around the UK c
by custardcream 12y ago
It's not a terribly hard job actually. I worked for a startup in 2004 that was doing this with haulage companies. We had 8000 data points moving around the UK coming in via GPRS and 3rd parties, traffic information aggregated and routing and mapping data, pick up corridors and event data.
It was (bar the web front end) a relatively modest sub-30kloc chunk of C++.
Now the scale is different but in 10 years, the problem isn't necessarily much more complicated, just larger.
In fact I think a derivative of it now runs some of Yodel's operations.
- mattmanser 12y ago30kloc is not a trivial problem, that's a year's worth of programming. I also love this: the problem isn't necessarily much more complicated, just larger If a programmer ever said this to me, it'd be a massive red flag that the estimate they're about to give me is going to be very wrong.
- custardcream 12y agoWell the dataset is about the same size now, perhaps 10% larger. The individual problem to solve is easily distributed across a large cluster of systems. 30kloc of COM/IDL as well that is. The actual routing engine was about 12kloc and the rest was the object model and deserializers. The routing engine was built on a two week binge of Red Bull, TAOCP and some papers printed out. It really wasn't rocket science even though we charged them like it was. From scratch by a non red bull enhanced team using c# instead it would probably about 3 months' work for two people to reproduce.
- Retric 12y agoIt's a larger data-set not a more complex problem. Also, there is no need to get a perfect solution anything better than what's out there is useful.
- stevenbedrick 12y ago> It's a larger data-set not a more complex problem. Ummmm... yeah, scaling the kinds of algorithms that one might apply to this sort of problem up to larger data sets is often extremely difficult.