Development Environments are a configuration of storage, processing and computing resources used to provide developers with a workspace and software development tools.
Development Environments may be virtual or physical and must provide Developers with the ability to design, write, build and locally test their code.
Development Environments will need access to source code repositories, the ability to run IDEs and local test tools. Developers' work is a balance between creative and scientific knowledge work and so development environments need to be frictionless for Developers to be effective.
Since Developers create the software products that create Business Value in software focused businesses any waste caused by Developers having unfit environments causes systemic inefficiency in the holistic software business.
To that end, Development Environments typically need to:
- Be fast, accessible and secure
- Use the relevant Operating System for the Developer's needs (Business Users may use Mac OS or Windows but Developers may need a Linux variant)
- Have considerable local or fast network attached storage
- Have unfiltered internet access
- Be personally configurable
- Allow installing other software
- Have multiple screens (at least two)
- Have good full-size keyboards and other HCI devices
- Have technical tools pre-installed or easily available (e.g. IDEs, static analyzers, reference libraries, configuration management tools etc.)
We strongly recommend that the Development community define the standard Development Environment and that the organization allows variation and personalization wherever possible.
Some developers will prefer entirely local development environments, whereas others will be content with cloud-based services. Enterprise Architecture and Operational concerns must be balanced with developer needs. Remember that any constraint on development adversely affects the Business Value of the entire organization so don’t apply restrictions because it’s easy, only when it’s right.
Process Specialist: Tools are just the things you use to do the process; the value is in the process. Let’s do a process first roll out.
Tools Specialist: Tools are the things people actually use. Process is academic and is constrained by the tool features anyway. Let’s do a tools based roll out.
In Holistic Software Development the real value is not in the tools or the process but in the people. Process and tools are something that you add if the people need them.