Features vs Functionality
I’ve just spent a few days trying to implement a specific feature in my current AIR project. Having tried several approaches and workarounds with varying degrees of nearly-but-not-quite-ness, I’ve had to admit defeat for now and have moved to a different implementation that I’m less happy with, but still allows basic functionality. At the same time Kieran has recently started work on his first Flex project and it’s been interesting to see how an experienced developer, when faced with a feature or issue he can’t easily implement or find a solution for, has quickly fallen back to a ‘next best’ solution, and moved onto getting the application functional and usable.
Time pressures obviously play a part here – the amount of time you have available before the project has to go out the door is going to impact on how much you are able to include desirable features over essential ones, but I think what I’ve picked up from this is that as soon as you encounter an issue, if you can’t predict reasonably accurately how long it’s going to take you to solve it, you need to set limits on how long you spend trying to make it work and at same time identify what is achievable if you fail to get it done within that limit.
If all this sounds like common sense, it is of course – but I found that in this instance I got too focused on a specific feature, rather than on getting the application functional enough that users can start using it sooner rather than later.