At an established company after hours projects should be reserved for cool new developments, neat hacks and other such refinements. Not for updating, upgrading and migrating existing software tools infrastructure during an high intensity release schedule. That’s the gist of the conversation I just had with one of the over achieving yet completely demotivated founders of the company I currently call my day job.
About the day job: It’s for a company that’s been around for a couple of years. It’s gone beyond the startup phase and really pushing toward the adolescence phase where a company is growing from 20 people to 100. Even the slightest impact on the release schedule at this point is detrimental.
Anyways, I am all about adding, updating and modifying the tools that we use on a day to day basis in order to achieve our goal of developing good software. But there are some really basic requirements that have to be met in order for these changes to be effective:
- Changes need to planned. If the work needs to be done during a tight release schedule, add it as an actual task so that the impact can be understood.
- We can’t negatively impact the existing workflow of the existing toolset while implementing the new one.
- The addition, change or modification needs to be throughly tested before introducing it into the tool chain.
- The change needs to make the workflow of the tool chain easier. Otherwise users will balk at the change.
- And above all else, it’s not a side project when you’re changing development tools. The impact is important enough to take the work seriously.
Did I miss anything?
No Comments Yet
No comments yet.
Comments RSS TrackBack Identifier URI
Leave a comment
