Hacker News Reader

> And, in spite of our "mid 5 figures" price for the iOS+Android apps for a fairly simple app - the whole program of work the government department included this in, and hence the media reporting of "what the app cost" came to 1.3million dollars.

You're absolutely right. They didn't buy an app; they bought a solution (of which the app was a small part).

Because it's not just the iPads; it's setting up the management structure for the iPads. How to procure them, locking them down so agents can't install Candy Crush, modifying existing IT processes to be able to manage device breakage/reloads/provisioning, etc...

None of this stuff is all that difficult, but nothing in business is free. So while any moron could write the app itself in half an hour, designing an end-to-end system that serves the needs of the customer (can be operated by someone with a GED; doesn't break down often; has simple workarounds for confusing scenarios; etc.) can cost a lot more than that. The software is just a piece of it.

Also, at the beginning of this process, did they know that what they wanted as an end product was an iPad running an app that made an arrow point left/right?

Or did they have a problem they wanted solved, and specing out a way to do it, was just one part of the job? Because often, the output of the contracts I work on, is the just the final step of testing out many possible solutions or version, and actually shipping the one the client finally agreed to.

Have you considered that maybe it's the government's fault that the media reported it in this way because - as in this example - the government intentionally obscured both how much the app cost and what was actually being supplied for the figure they stated.

Maybe, but then again the media has zero incentive to report this truthfully - "bad government wasting taxpayer money" is what sells.

To be quite honest, "bad government wasting taxpayer money" is more than newsworthy.

To your other point, we have in the past seen the media reporting these types of things in incomplete ways for fear of irritating their sources and losing reporting access.

> To be quite honest, "bad government wasting taxpayer money" is more than newsworthy.

If its true. In contemporary journalism the truth doesn't matter. Things can have perfectly reasonable explanations and be working as intended, and the only thing required to turn them into scandal is to omit those explanations and add a clickbait headline instead.

There's plenty of examples for that in Europe in the way journalists paint perfectly reasonable EU directives as utter nonsense handed down by stupid bureaucrats.

Things can also have perfectly reasonable explanations and be working as intended and still be an example of waste and scandalous. Just because you can see how it happened and why it happened doesn't mean you have to agree that the why and how are necessarily good reasons.

"Perfectly reasonable explanations / working as intended" and "example of waste and scandalous" are mutually exclusive IMO. You're right in principle, but what I see in practice is something completely different. Reasonable situations can be - and are - painted as ridiculous with proper application of journalistic freedom. It'd be better if people were thinking more critically about what they read, but outrage seems to be a pretty good mindhack the media learned to exploit. So I believe it is their moral responsibility not to abuse the gullibility of the readers.

It's also likely that government accounting departments only report costs at the project level and not at the line-item level -- it is common practice to just report on CapEx vs. OpEx because there are so many variations as to how things can be bought and sold, especially on technology projects (no idea if CapEx and OpEx make sense in the context of government work since they're primarily for tax purposes, but you know what I mean).

I doubt any company in America can tell you exactly what an app cost them to build. They can tell you what the product cost to develop, but the app itself is kind of beside the point: you don't get an app without the up-front work of determining the requirements, so why bother to separate the costs? Some projects have complex requirements and simple implementations, others have simple requirements and very complex implementations. The project cost is what everyone is concerned with anyway; and while the project manager should have the line-item information for the project, it's often not rolled up higher than that because the reconciliation would be nearly impossible.

Except these are iPad apps. Why the hell would you be doing that with HTML/Javascript?

Ever heard of UIWebView?

Doesn't change the question. Why would you be implementing this in HTML instead of doing it as a regular app?

Because if - as suggested - the _only_ requirement is "an arrow that randomly points left or right every time you tap the screen", the solutions is so simple that it _can_ be done in HTML/JS - quite probably written, tested and delivered for less than the yearly Apple Dev subscription required to do it as a native app.

If I had a friend who needed that functionality and had a decent reason but no budget, say for an art project or a non profit event, I'd certainly offer to build them an HTML/JS thing for nothing. I'd think twice about starting an XCode project, dealing with App Store submission requirements, needing to deal with people asking how they install it on their Android tablets, etc.

At least for me - sometimes the stupidly simple HTML version of a thing is a perfectly good solution. (For the TSA, there are without doubt more requirements than the stupidly oversimplified one proposed here...)

So you're going to make it a web page. How are you going to secure it? How are you going to make sure the website can't go down? How are you going to make sure that the only thing that device is running is the web browser, and that the only page it's allowed is the one to your app?

For my friend's art project? I'm not gonna care about any of that. (Not _quite_ true, I'll "care" about the webserver part by making it an HTML5 offline app - mostly to remove any chance that webserver problems make my phone ring while I'm asleep or out drinking).

You're inventing requirements which, while no doubt genuinely part of the TSA's requirements, go way beyond my single simple requirement as discussed.

"For my friend's art project?"

Your friend's art project is not what we're discussing.

"You're inventing requirements which, while no doubt genuinely part of the TSA's requirements, go way beyond my single simple requirement as discussed."

I am not; as you yourself admitted, these are likely part of the TSA requirements, which is what we're discussing.

Sure, except this subthread starts out with a response from me to which you're objecting saying:

'If the only requirement is "an arrow that randomly points left or right when you tap the screen" - I suspect _anybody_ who reads HN could whip up a provably-correct solution in under 30 mins just using html and javascript.'

In the context of the proposal to do this in HTML/Javascript, I've been explicitly discussing a obviously oversimplified single requirement - not the "likely" requirements for the TSA project about which we can only make assumptions, since we've not seen them.

Sorry if we've been talking at cross purposes here.