Over the Thanksgiving weekend, a Toronto app-development company Lazer Technologies claimed to have reimplemented the ArriveCan over the weekend, calling into question the $54 million dollar price tag the Federal government paid for the application. A second Toronto based tech firm Tribalscale also claimed to achieve the same feat - a working version of the ArriveCan app in a weekend.
The press coverage and social media narratives surrounding these two Hackathons is was what you would expect - outrage at government overspending and mismanagement of public funds. While I'm not here to defend the $54 million dollar price tag the Government paid for the ArriveCan application, anyone claiming they "rebuilt" ArriveCan in under 48 hours is just flat out delusional. Claims like these from developers do the software development industry a major disservice. The average Canadian who's never developed a line of code or worked on an enterprise application will read the headline and think that it really is possible to build ArriveCan in a weekend. It isn't.
From the TribalScale press release, they claimed the following:
The company will be releasing a demo Tuesday afternoon but has, in the meantime, shared a preview of the enhancements and features it implemented, including:
- Sign-up flow
- Created ability to add travel documents
- Created ability to add additional traveler profiles to accounts
- Ability to save travelers' details for future trips
- Ability to complete declaration forms (approximately a dozen questions)
- Ability to input trip information; integration with API for list of airport options
- Created placeholder to scan Passport or PR Card to add traveler details
List of linked traveler resources
To the untrained observer, this sounds like a working ArriveCan application - it has the ability to signup, it lets users enter the required data, and it appears to work the way the current ArriveCan application does. So while this hackathon produced something that looks like the ArriveCan app, it is 100% not a replacement for the real application.
For an application like ArriveCan to work in the real world it requires many additional layers that would never be completed in a hackathon. For example, the application needs to adhere to government security and privacy requirements, needs to integrate with legacy government systems and processes in near-real time, and needs to operate at the scale of Canadas population with near-zero downtime. The project management time for gathering the basic requirements for an application like this across all the stakeholder organizations would be in the six figures at least. These are not trivial tasks you finish in a weekend - they take planning, testing, auditing, and more. You also need to find developers with strong security experience and the appropriate clearance requirements before you can even write the first line of code. As a Government application that needs to work for everyone it also needs to deal with every possible corner case of inputs/outputs/responses from all the involved systems and processes. So while it's possible to create a minimum viable skeleton of an ArriveCan application in 48 hours there is no way you could complete all the required integration, usability, and security requirements in that timeframe.
As an industry we need to be better than this - the PR stunt pulled here by Lazer and TribalScale does nothing more than create fake outrage by hiding the true cost of application development. Do I think that ArriveCan should have cost $54 million dollars? No. This is at least a 7 figure application at the minimum and more likely an 8 figure application when all is said and done. And given the tight timelines and without knowing everything that was included in the price tag it could be a realistic number if it included operating costs. Could another team do it faster and better than it was? Maybe, but claiming it could be done in 48 hours is just a flat out lie that does nothing more undervalue the time and effort that need to go into nationwide scale applications like this and gives people an unrealistic view of what really goes into the application development processes.
Comments