
14 million lines of code?
14 million lines of code - just to sell train tickets over the internet. Really? Mr Stanley shouldn't be proud of this - he should be apologising. Cut'n'paste outsourced development gone mad, I expect.
For a business that processes 120 customer transactions per minute, the fear of IT outages is never far from the mind of Trainline's head of IS operations, Dave Stanley. Just 15 minutes of downtime can have a serious impact on revenue. Last year Trainline.com turned over £2bn in train ticket revenue, making it the fifth …
These days, what counts as a line of code anyway?
How many lines is an XML config file? What about CSS? Or a server markup page? Is a SQL query one line, or does it depend on how you format it? And do you count table definitions?
Etc.
Ridiculously stupid measure of development complexity. Should be banned from places like The Register, who really should know better.
A line of code is a sequence of bytes that can be interpreted by software running on the machine, and ending with the accepted line terminator sequence for the platform being used. And however 'large' or 'long' the lines are, having 14 million of them for a train ticket selling application is beyond daft.
This is some serious feature! So depending on OS it either included a cunningly disguised 'rm -rf' somewhere or someone ticked the wrong box in one of those setup wizard things, selecting 'forcibly remove' instead of 'do not touch this you bstrd I am not making any changes to this bit why are you even running and why is there no Cancel'.
So is the Dev that is now in Ops placed there as a guide or as a hostage?
This post has been deleted by its author
I thought CMM was a purely Military thing? I didn't know that they'd borrowed from NASA.
Can't say that I'm too impressed either as an outsider to the world of development, I thought you were always supposed to make sure new code didn't break existing stuff, and test it before deployment in the first place. I mean you're always going to have something unexpected happen, but having new code break the part that's actually selling something like in the example sounds like a piss poor QA/testing regime.
I am regularly amazed that people use Trainline which charges all sorts of fees, instead of the National Rail system which doesn't.
Is there more than advertising to this?
Of course, I don't often book journeys which span several different train companies. However I can book online with the local rail franchise after National Rail hand me off to their system. I can also pick up the tickets from a ticket machine.
So, no, not seeing the USP.
Which is a good moment to remind everyone of the wonderful http://traintimes.org.uk, which as well as providing clean, simple information can also do journey-splitting to find cheaper fares.
It helps that you can simply type an url like http://traintimes.org.uk/london/eastcroydon/1000/tuesday/ and it will show you the scheduled services.
"So, no, not seeing the USP."
It even worse than you think.
I'm pretty certain that all of the TOCs and other ticket selling entities all use the same codebase.
Because of this it's almost always possible to buy *all* of your tickets from a single source, so it's worthwhile "shopping around" for a site that doesn't - for example - charge you postage if you want an actual ticket as opposed to a paper printout or e-ticket.
In any case, it's almost always possible to improve on a single through-ticket price by breaking your journey at the appropriate boundaries though you do have to be careful that the train on which you are travelling does actually stop at the boundary station(s) you have chosen!
I wonder why there are no automated tools to inform the buyer what the actual cheapest options are?
If your developers have not already a clue about it, you hired the wrong developers and never trained them properly. With or without devops.
Any company who threats developers as code monkeys that should just implement the lines of codes assigned to them without any chance of looking at (and understanding) the big picture deserve any fault they get.
And any developer who believes his or her job is just to implement some code with a minimal effort as long as it works in his or her little world without any care for the big picture too, deserve any fault too.
"Maybe you should call it ZeroDevOps and write a PowerPoint presentation extolling its virtues."
The crazy thing is that this would probably work. All you need besides the PPP is a guy who looks good in suit and can convincingly talk weapons-grade BS for a couple of hours with a straight face. Oh, and be careful with the pricing. The package you sell must be insanely expensive. It won't be convincing if it's too cheap (which, in this context, means reasonable priced). Also, if it was really, really expensive, no-one who actually bought it would ever admit he was conned. If they ever notice. Aim for the C-suite-types.
"The crazy thing is that this would probably work. All you need besides the PPP is a guy who looks good in suit and can convincingly talk weapons-grade BS for a couple of hours with a straight face. "
Hmm. Yes I can think of a few of those.
"Oh, and be careful with the pricing. The package you sell must be insanely expensive."
I think they prefer the word "reassuringly."