Almost every time when you hope to escape a little known effort with the help of some less-known trick, you are guaranteed to end up doing more work than was planned.
Fresh example.
We needed to provide a Subversion account for beta-testers (at that moment, there were not too many of them, due to the nature of the project). It could be done by adding one more user to the "real" subversion database, and giving him restricted access to one sandbox directory only. However, this was considered to be too much of a burden (also because until now, there was no per-directory policy). So it was decided to establish a new "sandbox" subversion repository to be used for this project (which was not a bad decision in fact, only it should have been made much earlier).
As a result of that, we've got a week or so delay until all problem with new Subversion repository (which also happened to be established on a newly arrived machine and was using different protocol than the other one - svn instead of http) were cleared up.
Those were:
- some research to adapt the SVN connection layer to svn protocol;
- discovery that if we have SVN with anonymous access (easiest option) then SVN doesn't log the users which breaks some project requirements -> some time to set up the non-anonymous access;
- discovery that the SVN server on that machine was too old in comparison with the one used in the "real" repository, which manifested in the nasty side effects. As a matter of fact, there was a bit of luck, because the machine was using Solaris and the support for a suitable SVN has just been introduced. If it was not the case, the whole effort of setting up SVN there would have to be considered waste;
- discovery that updating SVN server required updating quite a few other services on the same machine and spending time doing that;
- last but not least, one more workaround had to be provided to solve a problem with one library that was mysteriously not found while SVN was running.
To sum up: as a result, we have got some knowledge and lost some time. It was not 100% critical for the given project, but in more pressing situation, a week of delay might have very bad implications. May be, in the research-like project it even makes sense to go untested routes in order to gain knowledge (and actually, this one could be defined as a research).
In the hindsight, at the moment when it was decided to do the less known thing it had to be communicated that the time estimations become risky. But the nice additional twist was that the person who made that decision was sure that "it was supposed to be easy".
How to anticipate that? Via micromanagement, asking everybody to come up with a sketch of what they are going to do? But then you might end up with the other type of waste; besides, in case the person responsible for the task is considered to be a senior specialist, he/she might take such requirement as an offence. (Well, I know how to handle that part in theory: by establishing a formal procedure everybody must follow prior to make any changes... these things don't happen overnight, and I've yet to see the place where they really work).
It all seems to be boiling down to convincing the people to follow these procedures. They can't be forced if nobody sees their value. How to convince people to change? May be they have some deeper reasons to behave like thay behave? (Like the ones described in this article, for example :) )
Remains an open question.
Fresh example.
We needed to provide a Subversion account for beta-testers (at that moment, there were not too many of them, due to the nature of the project). It could be done by adding one more user to the "real" subversion database, and giving him restricted access to one sandbox directory only. However, this was considered to be too much of a burden (also because until now, there was no per-directory policy). So it was decided to establish a new "sandbox" subversion repository to be used for this project (which was not a bad decision in fact, only it should have been made much earlier).
As a result of that, we've got a week or so delay until all problem with new Subversion repository (which also happened to be established on a newly arrived machine and was using different protocol than the other one - svn instead of http) were cleared up.
Those were:
- some research to adapt the SVN connection layer to svn protocol;
- discovery that if we have SVN with anonymous access (easiest option) then SVN doesn't log the users which breaks some project requirements -> some time to set up the non-anonymous access;
- discovery that the SVN server on that machine was too old in comparison with the one used in the "real" repository, which manifested in the nasty side effects. As a matter of fact, there was a bit of luck, because the machine was using Solaris and the support for a suitable SVN has just been introduced. If it was not the case, the whole effort of setting up SVN there would have to be considered waste;
- discovery that updating SVN server required updating quite a few other services on the same machine and spending time doing that;
- last but not least, one more workaround had to be provided to solve a problem with one library that was mysteriously not found while SVN was running.
To sum up: as a result, we have got some knowledge and lost some time. It was not 100% critical for the given project, but in more pressing situation, a week of delay might have very bad implications. May be, in the research-like project it even makes sense to go untested routes in order to gain knowledge (and actually, this one could be defined as a research).
In the hindsight, at the moment when it was decided to do the less known thing it had to be communicated that the time estimations become risky. But the nice additional twist was that the person who made that decision was sure that "it was supposed to be easy".
How to anticipate that? Via micromanagement, asking everybody to come up with a sketch of what they are going to do? But then you might end up with the other type of waste; besides, in case the person responsible for the task is considered to be a senior specialist, he/she might take such requirement as an offence. (Well, I know how to handle that part in theory: by establishing a formal procedure everybody must follow prior to make any changes... these things don't happen overnight, and I've yet to see the place where they really work).
It all seems to be boiling down to convincing the people to follow these procedures. They can't be forced if nobody sees their value. How to convince people to change? May be they have some deeper reasons to behave like thay behave? (Like the ones described in this article, for example :) )
Remains an open question.
No comments:
Post a Comment