May 29, 2008

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.

- 8 comments by 4 or more people Not publicly viewable

[Skip to the latest comment]
  1. Mathew Mannion

    It’s one of the main “benefits” of an agile approach that a working, usable prototype is available very, very early in the process – but the fact of the matter is that the feature in question borders dangerously on the “deal breaker” level – something that the application can’t really be released to users without. In that sense, it’s not really that surprising that you focussed so much time on trying to get it to work…

    Kieran’s working in Flex? Mock, I shall!

    29 May 2008, 23:13

  2. Steven Carpenter

    Flex is the future. Kieran is a convert to the dark side. ;-)

    Yes, you’re right – while I didn’t get there this time around, I’m sure it’s possible but perhaps beyond the limits of my current Flex skillz. The ‘next-best’ solution still enables the user to do something similar, so getting that implemented and coming back to it later on seems a better solution.

    30 May 2008, 09:07

  3. Kieran

    I am indeed working Flex and generally loving it. Beats fighting CSS/HTML/JS any day…at least for the project we’re working on right now anyway :)

    30 May 2008, 10:17

  4. Mathew Mannion

    Fighting? Being gently caressed by the intricacies, more like…

    30 May 2008, 10:28

  5. Steven Carpenter

    I love platform wars, except when the rival platform is better.

    30 May 2008, 10:47

  6. Chris May

    I think you’re not comparing like with like. This isn’t an agile/not agile distinction, it’s about different processes to acheive different end goals

    Kieran’s working to get a commercial product out of the door. He probably has a deadline, and so it’s crucial that he get something out, and so long as the client’s satisfied, that’s enough.

    You’re evaluating AIR as a future technology standard for the WebDev team, by producing a sample application. Simply getting an app out the door would be cool, but it’s not the only goal – in fact IMO it’s not even the most important one.
    We also need to get out of this process an idea of what works well in AIR, and what it’s not good for – so the knowledge that there are 5 different ways to do drag-to-desktop, and none of them work, is worth the week or so of delay to the end product. And, of course, you’re also increasing your the team’s knowledge of what development techniques work/don’t work for this kind of project – and your own experience. All that knowledge is the ‘product’ that you’re developing, just as much as the application itself.

    04 Jun 2008, 15:32

  7. Steven Carpenter

    Yes, you’re right; the distinction is more about the end-goals/pressures involved; while getting something out of the door isn’t my priority I’m also conscious that part of any evaluation might reasonably include time taken, and that the reason I may not be succeeding with this particular feature may be simply because I don’t know enough about the platform yet to know for sure that it can’t be done. At some point I guess it becomes prudent to assess if the lack of that feature is a showstopper and stop trying, or see if there are alternatives that would provide something close.

    04 Jun 2008, 16:11

  8. Sara Lever

    Hey Steve,

    Win some, lose some, just the way it goes. Instead of bashing your head against a brick wall might be worth parking it for a while, have a break and maybe come back to it fresh again a few weeks/months later, new ideas, new approaches might then come to light, you never know their might yet be method six that works.

    06 Jun 2008, 22:51

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.


MXNA link



    Other blogs I like...

    Black Pepper Software

    Eismann-sf Go to 'Comments on: Design News for Web, Graphic Designers'

    Ted On Flex Go to 'Ted On Flash'



    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXII