Hack & Refact
We interrupt your regularly scheduled nonsense for some different nonsense.
When I started working on ARventure, I used a very different sort of development practice than I usually do. This practice probably falls under one of the commonly known methodologies, and I'm going to sound mighty silly for acting like this is the new hotness, but it is actually new to me. Besides, I don't put much stock in those methodologies with fancy names. The actual practices are great, but people just love giving them names like Agile, Scrum, or Waterfall, that don't actually convey any meaning. Anyways, I've seen this practice referred to as "Hack and Refactor" online, but if you subscribe to the silly name society, feel free to call it "Flub" or something.
What I like most about "Hack and Refactor" is that it's the name and the instructions. First, you 'hack' to get the bare functionality down. Then you refactor the hacked implementation into a cleaner, more manageable form. Then you do it all again. I guess you could add a "repeat" to the end, but that doesn't quite have the same ring to it.
This is essentially the complete opposite of the approach I typically use, in which I plan out as much as I possibly can before even starting. Scribbling in notebooks, drawing diagrams, and trying to solve every problem before it even arises sounds good in theory, but in reality there's always something that slips through the cracks. For instance, when working on hxsvr, I thought I had a good base. Then I actually tried using my system and I realized I didn't have a function for closing a server. Silly little oversights undermine all that time spent planning.
With Hack and Refactor, on the other hand, no time is "wasted" with planning. You just get to it and figure out what you're working with once everything is up and running. The earliest working version of ARventure was a very long main function that loaded map data for a single tile and drew some lines. Then functionality was migrated into individual functions, such as loadTile and buildFromData, which allowed me to create multiple tiles. After that, functionality was moved again into separate classes, such as Tile and TileLoader. You get the idea. It's a very iterative process, where you achieve the minimum viable implementation before moving on to the next step. The best part is, unlike the approach I took with hxsvr and so many other projects before, the requirements and use cases for what you're working on unveil themselves as you refactor.
I know it's not exactly groundbreaking, but this was a major shift for me as a developer. Rather than trying to set up all the classes and structure that a game like ARventure would require and then filling in the gaps as they showed, I just got to work. It made the process feel much faster and organic. And as a plus, it's not all too different from the practice myself and many of my peers used during our time at RIT. Though, a more fitting name for that practice would be "Hack and done."
When I started working on ARventure, I used a very different sort of development practice than I usually do. This practice probably falls under one of the commonly known methodologies, and I'm going to sound mighty silly for acting like this is the new hotness, but it is actually new to me. Besides, I don't put much stock in those methodologies with fancy names. The actual practices are great, but people just love giving them names like Agile, Scrum, or Waterfall, that don't actually convey any meaning. Anyways, I've seen this practice referred to as "Hack and Refactor" online, but if you subscribe to the silly name society, feel free to call it "Flub" or something.
What I like most about "Hack and Refactor" is that it's the name and the instructions. First, you 'hack' to get the bare functionality down. Then you refactor the hacked implementation into a cleaner, more manageable form. Then you do it all again. I guess you could add a "repeat" to the end, but that doesn't quite have the same ring to it.
This is essentially the complete opposite of the approach I typically use, in which I plan out as much as I possibly can before even starting. Scribbling in notebooks, drawing diagrams, and trying to solve every problem before it even arises sounds good in theory, but in reality there's always something that slips through the cracks. For instance, when working on hxsvr, I thought I had a good base. Then I actually tried using my system and I realized I didn't have a function for closing a server. Silly little oversights undermine all that time spent planning.
With Hack and Refactor, on the other hand, no time is "wasted" with planning. You just get to it and figure out what you're working with once everything is up and running. The earliest working version of ARventure was a very long main function that loaded map data for a single tile and drew some lines. Then functionality was migrated into individual functions, such as loadTile and buildFromData, which allowed me to create multiple tiles. After that, functionality was moved again into separate classes, such as Tile and TileLoader. You get the idea. It's a very iterative process, where you achieve the minimum viable implementation before moving on to the next step. The best part is, unlike the approach I took with hxsvr and so many other projects before, the requirements and use cases for what you're working on unveil themselves as you refactor.
I know it's not exactly groundbreaking, but this was a major shift for me as a developer. Rather than trying to set up all the classes and structure that a game like ARventure would require and then filling in the gaps as they showed, I just got to work. It made the process feel much faster and organic. And as a plus, it's not all too different from the practice myself and many of my peers used during our time at RIT. Though, a more fitting name for that practice would be "Hack and done."