|
 Features
Indie Postmortem: 'FishEd'
 What Went Wrong:
1. Coding Inexperience
Despite my industry experience working on hundreds of projects and meeting thousands of deadlines, I’d never been in the position where I’d had to program under pressure. All of my past programming experience had been within an extremely flexible freelance framework, and like many hobbyist programmers I was simply way too comfortable in old habits and working practices. Planning a schedule was one thing, keeping to it was entirely another, and at times I suffered severe whiplash watching the deadlines whooshing past.
This lack of experience was particularly evident when bugs surfaced. The support of friends and forums can only extend so far, and the more complicated routines would be impossible to post online for evaluation. Coupled with the fact that there was simply no time scheduled in to fix bugs, addressing problems and making tweaks was left until the very last minute.
2. The Wrong Language
Roughly half-way through FishEd’s development, just as the project was really beginning to hit its stride, I learned that Blitz Research were releasing their latest creation, Blitz Max. While the language itself wasn’t a quantum-shift from what I was used to, the Object-Oriented approach was. Furthermore, faced with an increased schedule and thousands of lines of code to convert, it seemed like I’d already gone past the point of no return and would have to finish the project in Blitz+.
The final version of FishEd.
While this didn’t impact the finished product too heavily in terms of planned functionality, it did mean that many features had to be hard-coded rather than relying on Blitz Max’s rather gorgeous array of additional graphics capabilities. This ultimately tied up valuable time and resources, and was the source of a number of extremely stubborn bugs.
3. Lack of Testing
Despite receiving a lot of interest from various programmers and friends who were interested in testing FishEd, real life usually took priority and thus the bulk of the testing fell on my shoulders. While this wasn’t particularly difficult in theory, given my past experience in QA, in practice it was often very hard to uncover bugs due to the fact that I was so close to the project and thus had written the program around my preferences.
The net result was a plethora of bugs which would only show up by accident, usually when writing documentation, modifying existing code or adding new features. Though most were easily fixed, the release date was pushed back twice due to these unforeseen issues.
|
|
|
|
|
Previous