Hi, this has been the first year I participated in the HACC and I thought I would give some feedback. But first I think overall HACC is a great idea and it has been mostly a positive experance.
To give a bit of perspective of where this feedback are coming from, I'm a professional software developer and I work 40+ hours a week at my job. My time spent on the hackathon was a few evenings and weekends.
I'm coming at this thinking the state wants viable solutions to issues it currently has, as the primary goal. The state wants help support and educate developers in the community, as a secondary goal. Finally the state wants to help people create a business and monetize their solutions, as a tertiary goal. This is my perspective and my understanding based on being involved in the HACC so far and having friends that were involved last year.
- Overall there could be a lot of improvements to the HACC, some small, some large.
- Overall the process could be a lot more productive than it currently is.
- Some of the HACC procedures don't necessarily line up with the goals above.
First the projects that were presented really had some issues. A lot of them were overly broad with a wide open scope. These types of project are great, but not for a hackathon like the HACC. The projects should be completable within the hackathon timeframe. For example the Aloha+ challenge had a massive scope. The project should have been presented with a single goal in mind with a relatively small scope that could be built on top of. It seemed like the presenters just didn't understand what a hackathon is or what was involved in developing a project like this at all.
The Broadband map project had a smaller scope, but not really a realistic goal. The level of community involvement would be hard to create and prove over the short time of a hackathon. Some projects were overly simple such as the one OHA presented. It was, on a high level, transcribing data into a table and creating graphs. One team that worked on this created a really polished end result but its hard to compare that to say a team that work on the OE volunteer project. Some good projects from this year were the EAL Surfer, Mobile HRS and Volunteer Scheduler, LUC Information Intake. OHA's project was good, just overly simple.
This was just about awful from a developers standpoint. Due dates were different in different locations. Requirements weren't clear up front for what was needed for the technical submission. It wasn't clear it the technical review submission was a hard code freeze, soft code freeze or just a normal check-in. It wasn't clear, upfront, what was being looked at and judged. Comments were made that the technical aspect of the judging, of a hackathon, was a minor part. The amount of emphasis on the code and product compared to the video and presentation are just about reversed from what they should be.
Requiring a video is a very high bar. Not everyone has the ability to create a video, let alone a high quality video. Those that can make videos have to spend a lot of time on it rather than working on the actual project. What does the video actually provide for the departments? What does the video provide for developers? Both, the answer is nothing. Five minuets isn't nearly enough time to present a project, give a demo, talk about technical challenges and decisions made or any sort of Q&A.
- Have a page on http://hacc.hawaii.gov/ that list the full schedule long before the hackathon begins.
- Have the requirements for each deadline listed on the same page.
- Drop the video requirement for presentations, a PowerPoint / keynote presentation should be more than enough
- Review / coach the departments on the projects they want to do.
- For a month long hackathon, give a month to hack, a week to technical review, a day to present
- Only let 5-10 teams present. 20 teams gives 5 minuets and with 5 minuets you really can't present anything, let alone have a Q&A with the judges.
- Set a hard limit on team size 4-5 people. For schools or larger organizations they can have multiple teams.
- Have more, smaller scoped, better defined, projects. Perhaps have each department present two options.
- All the projects should have a defined scope document, nothing fancy, something simple like this: (http://www.expertprogrammanagement.com/wp-content/uploads/2017/06/Project-Scope-Statement-Example.png)
- If this is really about problems, solutions and developers then make the technical review 50% of the score.
- Have the presentation be about the project with a Q&A from the judges. Don't have it be a VC like elevator pitch, rather have the teams talk about development problems and how they overcame them. About why they choose the technologies they did. About how the choices made will benefit the government departments in the long run.
- Have part of the final score be given by the department who suggested the project. Does it meet their needs, is it easy to use, are there missing requirements, are there extra features.
- In the end I would break the score down like this:
- 50% Technical review (technical judges)
- 5% Were checkins made on time, was code freeze on time
- 5% Is there a live site/application that functions
- Android is 0 day wait time to deploy to the app store
- iOS is 0-7 day wait time to deploy to the app store (mostly 1-2 days)
- Both iOS and Android can be installed on a device for judges to use without being live in the store
- There are plenty of free or near free hosting options out there for sites and APIs
- 10% Is the provided documentation adequate to stand up the website or to build the mobile app
- 20% Does it look professional, is this something the government would put in use as is
- 30% Does it function as expected, meeting all the project's requirements
- 30% Is the code clear, easy to follow, easy to maintain and extend
- 30% Department satisfaction (department heads)
- 25% Does it function as expected, meeting all the project's requirements
- 25% Would the department accept the site/application as is
- 50% Team professionalism while working on the project and communicating with the department
- 20% Presentation [10 min.] and Q&A [1 question per Judge] (judges)
- Missing the presentation disqualifies the team