• Matt Miller (#4) (8/25/2016)


    Eric M Russell (8/25/2016)


    Matt Miller (#4) (8/25/2016)


    SQLBill (8/25/2016)


    Eric M Russell (8/25/2016)


    I'm not surprised that a small group of students could take a public dataset and spin up a better application than the original government IT contractors. When dealing with non-sensitive datasets, perhaps the government should approach this from the bottom up, rather than the top down. For example, start by publishing the data and a set of high level requirements, see who can create the best prototype solution that meets the requirements, and then award them a contract to finish off the project.

    If some some bloke from Denver named Dan can create BI solutions better, faster, cheaper than a billion dollar corporation that specializes in manufactoring jet planes and electionics, then why not just hand the job over to Dan?

    Here I'm just talking about the application development itself. The government could still farm out the infrastructure and support to the usual contractors.

    Because 'Dan' is designing it on his own...not following the Government's criteria. This is where the issues really happen. The government can be really specific on what they require. Read a government contract sometime. There's been lots in the news about the cost of the toilets on the shuttle or the space station. Also, costs of military aircraft/ships. But when the requirement includes a specific description of a wrench and that description means you have to create a process to make that wrench because the $5 one you can find in the store doesn't exactly match the requirement....there go the costs up and up.

    -SQLBill

    Agreed- as a friend who was a veteran pointed out to me: you go design a toilet that can be airdropped from 500 feet out of the back of a plane without a parachute, that won't break, doesn't require extensive assembly and can run without a water or power supply, and see what price tag YOU come up with :w00t:

    Like I said, the government would publish requirements (both internal and public facing) for the web application along with the dataset. If the data is aggregated properly, then the securing the application is straightforward. The analogy of an indestructable military grade hammer doesn't pertain to a public website for visualizing census data. If someone thinks it does, then that's part of the problem.

    Look I am fairly confident that no one cares if the census web server can be dropped from 500 feet and still work....:-D

    Seriously though - designing something to simply capture data is trivial, if you don't care about securing it, session management, validation of who's filling the data in, ensuring that it actually does store the data, etc..... There's no denying that there should be public requirements and a review/bid process - but pretending like the non-functional requirements are "the easy part" is like assuming that the part of the iceberg you see is the only part. I could build an accounting system out of Microsoft access - but I wouldn't want to manage the size of Microsoft out of it....

    I wouldn't doubt that in this case - some requirements made no sense or artificially pushed up complexity or otherwise destabilized the solution. Still - I wouldn't go so far as calling it trivial.

    My point was that the client's requirements could cause a 're-tooling' instead of an 'off the shelf solution'. Re-tooling or redesigning will always be more expensive.

    There are petitions, letters, etc. to the U.S Census Bureau asking them to increase the Gender/Sex option. Currently it is Male/Female. When you are creating an application/backend/process that needs Gender/Sex information, you can probably find an existing application/backend/process to use and convert/update to do what you need. But what if you have to include different gender/sex options? Most likely, it will cause a major re-write of an existing process or the creation of something entirely new. Where a company could save money by repurposing an existing application/backend/process if two gender/sex option is needed, it could be more expensive to make an existing one meet the criteria of multiple gender/sex options.

    So, while the students came up with something less expensive...did it meet all the requirements of the client? Did the expensive one cost so much because of the client requirements?

    -SQLBill