Working Environment Factors in Development Roles

Every company has its own culture - a unique blend of methodologies and people that form the working environment. The world of IT perhaps boasts some of the most diverse conditions - partly due to the diverse range of skills within, and partly due to misconceptions around the requirements of technical workers.

Good Practices, Best Practices and the Worst

There are generally two ways to get something done: There's the quick way, and then there's the right way. The right way isn't always the cheapest, nor is it feasible in some cases, but it generally pays greater dividends than the shortcuts in the long run.

For programmers, there are a number of indicators of a given environment's preferred approach. Source control, testing and documentation are all part of a good programmer's vocabulary, and are key indicators of how the programmer (and the department/team they are a part of) will work.

Such things as source control, testing and documentation are not always required - indeed, quite often they are overkill - but the lack of such procedure within core projects is a sign that the environment within the organisation in question may tend towards the 'quick and dirty' school of development.

For critical business development, safeguards such as source control and testing act not as impediments but as a hedge against potential failures - failures that can (and frequently do) cost more than the relatively minor time invested in such safeguards.

Documentation, in the same way, is a pre-emptive investment in a developer's time made with the intent of saving effort in the future - for improved ease of redevelopment, or for training purposes. A little time spent doing things in the correct way can pay greater dividends in the future.

The use of such tools and methods will heavily influence a working environment - for instance, in a situation without documentation or testing, a developer might find themselves bogged down with an endless stream of bug reports, whilst struggling to get to grips with an existing system. This cycle can be exacerbated by pressure to enhance or release new features - and such pressure usually comes from above.

Management Styles

The way an organisation is managed will have a direct effect on the working environment for IT staff. A better working environment will stem from more technically-aware management, with less focus on continually churning releases and new features and with at least some investment on some of the methods and tools mentioned above.

Those organisations that choose to ignore such needs will inevitably waste time dealing with the problems that arise, and inevitably it is the developers that have to deal with these problems. It is usually far better for an organisation to invest at least some time in defensive measures against future problems.

Of course, some places do - indeed, some places will adhere to protocols to their own detriment - but in my experience there are a great many that do not adhere to any sort of routine, and suffer as a result.

Improving Working Environment Factors

In some cases, bad practice is endemic- and as such it's not always easy to rally against deep-set problems with department work flow or with management interference, but being aware of the issues involved with a particular environment is the first step to making improvements.

An effort to improve the safeguards in place in the development work cycle (such as proper source control, testing and documentation) should be a priority, as in the long term they can save time from bug fixing premature releases. In addition, a good IT manager will also be aware of the best practices for developers, and will serve as a go-between from the developers to the exterior management.