Finishing a project
In my experience it is not just an artist who has trouble finding a point to lay the last stroke and call it finished. Software is a nightmare in that regard because not only does it have to satisfy the client but often also many, many users and stakeholders. Therefore, finding a solution is difficult until you're almost at the point of completion, where you say "we've satisfied the requirements, we're sick of this software and you're sick of waiting, it's finished".
So how do you not only finish a project but finish it to spec and on time?
First point is obvious... get the spec right. If the spec is right then a solution will be the point at which the spec is satisfied. Some problems will make do with a solution which satisfies the spec. But how often is a spec written which encompasses both something that can be verified and something that the client wants? You can make a spec so that it can be a checklist and every requirement can be ticked off and verified... but will that mean the software produced will be useful to the client?
I think this is why iterative processes come to the fore. They accept that you cannot get the spec perfect and build the perfect system. Can't be done, 'cos software invariably deals with "problems" or "messes" and not "puzzles". Iterative says we'll get what we think is right done and then we'll assess it and changes can be made and new functionality added. It does this by reducing the temptation to change things on the fly... "just wait 'til the next iteration, we can do it then"... rather than with a conventional approach where if it's not implemented now it's not implemented.
But does that help you finish? It may not help you finish, but the changes will be implemented in an organised and planned fashion rather than continuously tweaking this and that to get it to a state of acceptability.
I still haven't learnt how to finish a project properly without just coming to a point and saying "it's done" 'cos to improve it further wouldn't be economically viable. But then that's half the fun. If all the projects were just puzzles then life would be boring.
So how do you not only finish a project but finish it to spec and on time?
First point is obvious... get the spec right. If the spec is right then a solution will be the point at which the spec is satisfied. Some problems will make do with a solution which satisfies the spec. But how often is a spec written which encompasses both something that can be verified and something that the client wants? You can make a spec so that it can be a checklist and every requirement can be ticked off and verified... but will that mean the software produced will be useful to the client?
I think this is why iterative processes come to the fore. They accept that you cannot get the spec perfect and build the perfect system. Can't be done, 'cos software invariably deals with "problems" or "messes" and not "puzzles". Iterative says we'll get what we think is right done and then we'll assess it and changes can be made and new functionality added. It does this by reducing the temptation to change things on the fly... "just wait 'til the next iteration, we can do it then"... rather than with a conventional approach where if it's not implemented now it's not implemented.
But does that help you finish? It may not help you finish, but the changes will be implemented in an organised and planned fashion rather than continuously tweaking this and that to get it to a state of acceptability.
I still haven't learnt how to finish a project properly without just coming to a point and saying "it's done" 'cos to improve it further wouldn't be economically viable. But then that's half the fun. If all the projects were just puzzles then life would be boring.


0 Comments:
Post a Comment
<< Home