FeedbackHelper 5.0

and what it taught me about academic software development

Michael Young

Introduction

The Problem

  • Marking is time-consuming
  • Hugely repetitious
  • Expertise is lightly used

Old Solutions

  • Copy and paste?
  • “Master” document with used phrases?
  • Something with spreadsheets?
  • Or just spend a long time?

FeedbackHelper

  • MSc project advertised in 2021
  • Make a tool for reuse of phrases
  • Minimise clicking
  • Designed for St Andrews and MMS

FeedbackHelper 1.0

  • Bhuvan Bezawada made a prototype
  • Functional and useful (for me)
  • “Cool” additional features

Ongoing work

  • Forked by MY for further development
  • Contributions from J. Zelger, O. Fadare, Y. Cao
  • Various little improvements and fixes
  • Releases up to 4.0

(Demo of early version)

Problems with the old version

Barriers to use

  • “Check your Java version”
  • “Run the tool from the command line by running java -jar .jar”
  • “You might need to set the file to be executable”

Performance

  • Long launch time
  • Slows down as an assignment gets bigger
  • Huge executable

UI madness

  • Unintuitive and hidden features
  • Scrolling all over the place
  • Resizing badly broken

Save file problems

  • Save to three different files
  • Not portable
  • Fails invisibly if anything gets moved

Technical debt

  • Questionable structure of code
  • New features introduced in weird places
  • Hacks to get around other hacks

Last semester

Goals for EDL

  • Increase bus number
  • Eliminate technical debt
  • Make it easy to add features
  • Widen the audience

Philosophy

  • Write as little code as possible
  • Avoid dependencies
  • Prioritise stability and maintainability

The Process

  • Procrastination
  • Deletion
  • Endless refactoring
  • Improvement
  • New features
  • Testing
  • Release

The Result

FeedbackHelper 5.0 (and up)

  • New features
  • Jank gone
  • Tiny size: 605 MB → 47 MB → 3 MB
  • Easy install

(Demo of new version)

Lessons I learned

Swing still works

  • Let go of pixel-perfection and embrace Swing idioms
  • “Preferred size”, “Look & Feel”, standard components
  • Reject the myth of “modern”

Code deleted is code debugged

  • Many problems with software are problems we create ourselves
  • Code is perfect when there is nothing left to delete
  • Conservative approach to all changes
  • Source code: 7500 lines → 6000 lines

Look for the bigger question

  • Many issues reported were “it does this thing badly”
  • Obvious solution is “make it do that thing better”
  • We should try to ask “why are we doing that thing at all?”

Academic software is free software

  • Software with no incentive except to be useful for markers
  • Freedom from commercial anti-patterns
  • No need to impress or hook users
  • No AI mode ✨ to be pushed
  • Sustainability of open source

Build it and they will come

  • Apparent wide use in this building
  • Home-cooked meal → School canteen

Conclusion

It’s good enough

  • Ready to be shared with other schools
  • I’m no longer panicking about it crashing and losing data

Future

  • Listening to feedback and carefully improving
  • StARIS students expected
  • Small features now easier to implement
  • Major ambition: siloed app → composable software

Do try this at home