Project #1: Post-mortem
For the project post-mortems I will start with a template of two questions (“What went well?” and “What was terrible?”) and at least three actions (“Start”, “Stop”, and “Continue”). That was easy – on to it!
What went well?
Guiding Principles – The 24-hour cap was just about perfect for this project and did a great job in keeping me from rat-holing on inevitably unimportant details. I was fully expecting to rev the Guiding Principles in the first few projects, but I think I’ll keep them as-is for now since I they worked very well for Project #1.
Construct 2 – Construct 2 was a great 2D simplified development environment. Since I wasn’t making a game there were a lot of things I didn’t dive into. But! For coming into the system mostly cold, I was able to get up a going and making something that didn’t totally suck in not very much time. Self-hi-fives.
Releasing – I learned a ton about how the Windows, Android, and iOS independent publishing works.
- Windows kind-of cares about what you publish and that you’re not an techno a-hole. Also, they very much care about your application having a somewhat real privacy policy, even if your application doesn’t use anything on the device except for local storage and the screen. Some one (a person!) told me this a number of times as I was submitting package updates to publish.
- Android does not give a shit what you publish.
- iOS will let you do everything you need to publish from not-a-Mac, except upload the binary. You can MAKE the binary, TEST the binary, and PACKAGE the binary all on a PC. Oh, do you want to upload the binary? You’ll need to buy a Mac and download XCode because we hate kittens. I’ll be bitter about this until I borrow a friend’s Mac and upload the stupid thing. I realize I’m complaining in the “What went well” section, which means I realize this is mostly a personal issue.
Work/LifeWork Balance – A hole I have dug on more than one occasion is overcommitting myself resulting in my internal thread scheduler thrashing like an angry monkey on speed. In this case, since I have deliverables and a time frame and a freaking blog, it is easier to say “no” to other projects so far. Or even better, I put the potential project on the backlog for Hello Program and will prioritize it so that I am only actively working on one moonlight project at a time. This kids, is what I’ve been told is called “growing up.”
What was terrible?
Cross-platform Performance – Something between Construct 2’s HTML5 exporting to Windows Phone and Windows Phone 8 HTML5 rendering resulted in garbage performance. I’m not sure if this was something in Construct 2’s inefficiencies or in Windows Phone’s IE JavaScript engine. Since I have no intention on diving into either, I will leave it at that. It seems to work okay if you point your Windows Phone to the web version…sometimes. Sad face since I generally love everything about Windows Phone otherwise.
Art Assets for Publishing – Forty-five is the number of individual icons, logos, and splash screens I had to make to publish into each of the marketplaces. Forty-five! In the worst offense, I had to make icons that were 70×70, 71×71, and 72×72. It’s not like a super big deal but I definitely spent a solid our of the time spent in publishing resizing and adjusting and aligning all the stuff for these assets.
Start Stop Continue
START using VisualStudio.com, because it is great. OneNote is also great, which is what I used for work tracking in the first project. The theory was to have as minimal as possible project management overhead, which worked out alright. But even for a single-person constrained project as this, I was wanting for some straight-up work item tracking, bug tracking, and a scrum or agile task board. I ask and technology shall provide.
STOP using Construct2. Don’t get me wrong, Construct 2 is great and I will sing all the praises for it. But! I am a software developer and there were a number of things I had do weird things for because the coding interface is basically super-good pseudo-code. I will return to my C/C++/C# roots for the next project.
CONTINUE using the time log. I originally started the time log just to make sure I didn’t go over the 24 hours. What ended up being more useful was looking back at how much time I’ve spent doing items such as design, planning, implementation, bugs, redesigns, what-have-you (I posted a near-final time log here). If the 24-hour constraint abstractly kept me on-task, the time log is a concrete implementation of the idea. Each day I could look back on how I was spending my time and quickly figure out if I felt comfortable continuing on something or if I needed to move on.
Ideas for project #2 are in the cupboard, now it’s just time to decide what’s for dinner.