Boggle the Mind

My MS in CS at Georgia Tech was a pretty good experience, and I don’t usually say that for anything regarding school.

One of the more enjoyable projects that I worked on was a group project to implement a Boggle game for Android. Honestly, this might appear to be a pretty “rudimentary” project but several things have stuck with me throughout my professional career that I learned from this project.

Mostly, as my background is in chemistry, there are several practices we adopt as “standards” in other technical fields, that I think software engineers should adopt as well. Mainly, we tend to write down so much more in other disciplines than we do in software engineering. This is a shame, because writing is fun and fun is profitable :)

Let my learnings be yours - UML, visual design, and collaborative documentation have no substitute in software engineering. In a world full of AI outputs, it is in fact more critical than ever to practice designing code collaboratively, so that we maintain interpretability of even “simple” practice projects like this one. It was remarkable how after so many years I was able not only to run the project from detailed documentation… but also understand and remember the internals!

The Project

This was part of my coursework so let me set the stage. Our rubric requirements involved:

1. Individual designs that we then critiqued as a team, synthesizing the best elements into our final approach.
2. UML diagrams for modeling the core game mechanics and ensuring our design met the requirements.
3. Creating an intuitive UI that would allow players to select letters to form words on the Boggle board.
4. Implementing the game logic to validate words against a dictionary and track scoring.

We needed to focus on delivering a playable and working game rather than all the fancy visual bells and whistles…

(Really, who would have thought that this simulation of software development very much mirrors many discussions we have day to day in… software development?)

So that led to a lot of niceities being forgone up front, like a basic SQLite database to persist user state or game data, or a more complex UI framework that would allow for more interactivity.

Some Results

Despite the time constraints, we managed to deliver a functional Boggle game that ran smoothly on the target SDK versions. The UI was simple and responsive, allowing players to trace paths through the letter grid to form words.

One of the more interesting challenges was designing the word validation system.

We needed to make sure that selected letters were adjacent on the board, that words were actually in our dictionary, and that the interface responded appropriately to valid and invalid selections.

Do you know what made work like that easier when some of us had rotating roles to work on the game logic, UI, and testing?

The Value of Design

Design documents. Yes that is what made it so much easier. I hear much discussion about “TDD” or “BDD” in my professional career but I think the most important thing we learned from this project was the value of design documents and UML diagrams…

“DDD” if you will - Design Driven Development. Is it really so hard to have a kickoff meeting, write down the critical requirements, and just do some visual code design before we start writing code? I think many teams are allergic to the idea that engineers benefit from drawing things and manually writing down their documentation before projects start - you cannot sell that to users after all, right?

But… seriously, this project was a great example of how design documents can help align a team around a shared vision, clarify requirements, and ensure that everyone is on the same page before diving into implementation. I run into problems related to these fundamentals quite often in my professional career, and I think it is a real missed opportunity that we don’t do more of this upfront work.

Anyway… in no particular order, here are some of the many things I learned from this project:

• UML is more than just a classroom exercise - it genuinely helped us validate our design against requirements and ensure our test coverage was comprehensive.
• Mobile development has unique constraints around UI responsiveness and performance. What works on a desktop might feel slow on a mobile device.
  • I had made Android apps before with Kivy - but it was interesting to see how doing it in Java with Android Studio was a more “scalable” approach.
• Scope management is critical with tight deadlines. Focusing on core functionality first and making explicit decisions about what to defer saved us from having an incomplete product.
• The Android ecosystem’s version compatibility issues are real my dudes. Making sure our app worked across the target SDK range required careful consideration during development.

Overall this project was a nice introduction to mobile development and a real key demonstration of the importance of design in software engineering. I also took from this that what makes a great engineer isn’t their ability to crank out code, but their ability to communicate well, and develop solid fundamentals including sensible project management and design practices.