Well, I’ve finished the PartBuyDetailPanel, or the “thing that shows details about what part you clicked on and lets you decide to buy it or not.” Now I’m wiring it in, and while I’ve been testing the Buy Screen I realized I’m forced to implement logic that tracks the game state (finally).
Wait, forced? Yeppers. Mech Retriever is Agile, baby!
…Ok, so what does that mean?
It means that instead of a big design up front, or BDUF, I’ve been designing the code as I go. At first bluff, that sounds irresponsible, but in reality that couldn’t be farther from the truth… As long as you’re whole-hearted about it. The half-cocked version of Agile some people espouse is, in fact, horribly irresponsible.
I’ve noticed that successful Agile development is marked by a few things:
- Using Test-Driven Development
- Doing the simplest thing that could work
The first and last bit are the parts I’ve seen most frequently neglected. Some teams, due to management pressure or whatever else, will skimp on TDD and Refactoring. They tend to like phrases like “shortest path to value,” which is what some of the business people fixate on, but really this just ends up turning “Agile” into “Corner-Cutting,” which results in long term crippling of productivity.
“Tech Debt” is a term developers use to communicate to non-developers that if we don’t do something correctly now, we will still end up having to pay for it later. Personally, I like referring to the “Tech Debt Pay-day Loan Cycle,” because sometimes people here “Tech Debt” and assume that it’s like a friend covering 20$ for a meal and you can pay them back whenever, interest free. The reality is that the interest compounds viciously. And what’s worse, you could’ve been investing that money.
What do I mean? In Mech Retriever, for example, I spent a bunch of extra time really making sure that the implementation for Part Slots, which are a UI element used to display part info, was really solid. And guess what? It not only resolved the problem I was working on at the time, it paid off in other, future problems immediately afterward. Like in the PartBuyDetailPanel–I was able to use the PartSlot to solve a large chunk of the design problems for the panel even though I hadn’t conceived of the panel yet when I made the PartSlot.
That’s the Refactoring bit. If you’ve got good tests, and do the simplest thing that could work at first, you can go back and look at the result and figure out how to improve it, much like an artist refines a sketch.
But some people have never felt what it’s like to see profits come in from investment. When you’re always caught up in the Tech Debt Pay-day Loan cycle, you never see how much better it is when you invest. Which is why some shops still don’t invest enough.