<p>In industry,  the DEV environment is where developers are free to play and break anything (provided they fix it for those who follow). A typical enterprise shop will have a DEV, TEST/QA, and PROD environments,  with developer access to DEV being nearly unlimited,  but PROD being limited to end user support without significant from 5 layers of management and a pope.</p>

<p>DEV will typically mirror prod closely enough for practical purposes,  but be underpowered to reflect its lesser usage. </p>

CC BY-SA 3.0
2017-12-26T06:07:51.627Z
2017-12-26T06:07:51.627Z
pojo-guy
<p>If you write software you necessarily <em>have</em> a development environment. It might help or hinder you as you work. A development environment consists of some set of tools that you use to develop the program. The tools might be integrated into a single framework (an IDE) or not, but you have some sort of environment.</p>
<p>The tools include at least</p>
<blockquote>
<ol>
<li><p>one or more editors to create files of various kinds, text and otherwise.</p>
</li>
<li><p>one or more compilers to translate your program files into machine code for one or more machine architectures</p>
</li>
<li><p>one or more run-time-environments in which you can execute your code, either on the target architecture or in a simulator</p>
</li>
</ol>
</blockquote>
<p>Additional tools that are usually needed are (not a complete list but will do for a start)</p>
<blockquote>
<ol>
<li><p>a test framework so that you can effectively write both unit tests (the code does what I think it does and doesn't break as I change things) and acceptance tests (the code does what the owner/customer really wants done - irrespective of my understanding).</p>
</li>
<li><p>automated error checkers to trace back exceptions and race conditions (among other issues)</p>
</li>
<li><p>a debugger that lets you interact directly with the target code as an aid in finding and repairing errors.</p>
</li>
<li><p>a design framework in which it is easy (or at least possible) to create design documents, which may be textual or graphical. They might be integrated with code generation or not.</p>
</li>
<li><p>a code repository and version control system so that old versions can be maintained and errors can be backed out of</p>
</li>
<li><p>a team-support system that helps a group of developers work on the same project. These tools may include simple communication tools (email...) or provide things like distributed pair programming.</p>
</li>
<li><p>a database system to hold necessary data used by the program. Sometimes a database is also used to store fragments of the program(s) themselves. The database might also contain required test data to assure the correct thing is built. Likewise it might contain information about the success or failure of test runs</p>
</li>
<li><p>a documentation system that can be used for either or both of program documentation of use by the team and user documentation that gives instructions to the end-user on effective use of the system</p>
</li>
<li><p>a way to make interaction with the file system easy and efficient, such as directory listings that let you easily open/save/close files</p>
</li>
<li><p>a way to maintain various &quot;configuration files&quot; so that the system can be tailored for its various uses</p>
</li>
<li><p>a way to keep all of the tools updated easily</p>
</li>
<li><p>automatic error checkers and style checkers beyond those provided by the compiler</p>
</li>
<li><p>For some kinds of software a sophisticated emulation environment to check the interaction of various components. Mobile apps often need servers and some way test the interactions, for example.</p>
</li>
</ol>
</blockquote>
<p>An Integrated Development Environment (say Eclipse or NetBeans) will integrate all of this into a single program that may use one or more multi-pane windows to provide a visual representation of all of the tools. A good one is tailorable by language and by need without cluttering up the workspace. A less integrated system (Emacs, say) provides all of these things through (possibly cryptic) user commands. An IDE requires a learning process itself, but it pays dividends if it is flexible and not restricted to a single language or architecture.</p>
<p>But even a simple text editor, a compiler, and a run-time for testing is a development environment and for many years was all that was available. Way back, the &quot;text-editor&quot; was just a card punch.</p>
<hr />
<p>Note that not all files in a project are necessarily just text. Some projects require, for example, graphical files to show design.</p>
<hr />
<p>I don't claim I have a complete list here. There are many other possibilities. Each person's development environment is personal. It is good if it makes them more productive and less frustrated. Is is subject to update and modification at any time that you learn of a new tool or technique.</p>
<hr />
<p>Also note that not all of these are needed in every project and you don't need to be proficient in many of them to get started. But issues that arise as you work may help you see the need to expand your personal set.</p>

CC BY-SA 3.0
2017-12-21T21:31:53.423Z
Online tutorials. If an IDE does not have decent online tutorials I tend to drop it like a ton of lead.
Guy Coder
CC BY-SA 3.0
2017-12-22T21:49:10.770Z
Thanks so much, this is exactly what I was looking for- Buffy, could you also say that there is an interpreter instead of a compiler if it isn't compiled in to machine code?
WalkerLJ
CC BY-SA 3.0
2017-12-22T21:53:17.487Z
Yes, certainly. There is very little difference between a compiler and an interpreter, actually. Everything but the back end is the same. The compiler outputs a file and the interpreter executes some intermediate code.
Buffy
CC BY-SA 3.0
2017-12-21T20:48:06.933Z
2017-12-21T21:03:35.577Z
2020-06-18T08:36:57.023Z
Buffy
<p>I am trying to create lessons and curriculum designed for school-aged students, teaching about IDEs and development environments. What is a succinct, not too complex definition of a development environment? I want to explain the role of servers, databases, and other things that are required for an application to run, as well as the relationship an IDE has with the development environment, in the simplest way possible.  I saw a definition as a 'set of tools' but what are the tools that are included in an environment, and what purpose do each of these tools serve?</p>

CC BY-SA 3.0
2017-12-21T19:39:15.927Z
I was literally typing in almost exactly this question when your question popped up on the feed. Crazy! My question also referenced virtual environments (such as you have when developing an iPhone app) and the console, because these environmental factors are very hard to explain to a kid who has only ever used applications.
Ben I.
CC BY-SA 3.0
2017-12-21T19:41:10.597Z
Well that makes more sense.  I just realized that I saw your question yesterday on SO. It must have infiltrated my brain to the point where I thought it was my own question.  :P  In any case, welcome to [cseducators.se]!!
Ben I.
CC BY-SA 3.0
2017-12-21T21:23:33.883Z
A development environment, is an environment that you develop [code] in. An integrated development environment (ide), is a development environment where the tools have been integrated, to produce a seem-less environment. You no longer have to save, compile, run. You can just press run. The can also incorporate linting, unit-test, revision-control, etc all from the editor.
ctrl-alt-delor
CC BY-SA 3.0
2017-12-22T22:07:48.747Z
BTW, now that you have the privileges, feel free to come by [the classroom](https://chat.stackexchange.com/rooms/59174/the-classroom) and say hi!
Ben I.
<ide><programming-environment>
What is a (simple definition of) a development environment?
# What is a (simple definition of) a development environment?

(Asked by: username_0 on 2017-12-21)

I am trying to create lessons and curriculum designed for school-aged students, teaching about IDEs and development environments. What is a succinct, not too complex definition of a development environment? I want to explain the role of servers, databases, and other things that are required for an application to run, as well as the relationship an IDE has with the development environment, in the simplest way possible. I saw a definition as a 'set of tools' but what are the tools that are included in an environment, and what purpose do each of these tools serve?

**Tags:** ide, programming-environment

> **Comments:**
> **username_1**: I was literally typing in almost exactly this question when your question popped up on the feed. Crazy! My question also referenced virtual environments (such as you have when developing an iPhone app) and the console, because these environmental factors are very hard to explain to a kid who has only ever used applications.  
> **username_1**: Well that makes more sense.  I just realized that I saw your question yesterday on SO. It must have infiltrated my brain to the point where I thought it was my own question.  :P  In any case, welcome to [cseducators.se]!!  
> **username_2**: A development environment, is an environment that you develop [code] in. An integrated development environment (ide), is a development environment where the tools have been integrated, to produce a seem-less environment. You no longer have to save, compile, run. You can just press run. The can also incorporate linting, unit-test, revision-control, etc all from the editor.  
> **username_1**: BTW, now that you have the privileges, feel free to come by [the classroom](https://chat.stackexchange.com/rooms/59174/the-classroom) and say hi!  

---

## 2 answers

### Answer by username_4 on 2017-12-21. Score: 4 | Accepted answer

If you write software you necessarily *have* a development environment. It might help or hinder you as you work. A development environment consists of some set of tools that you use to develop the program. The tools might be integrated into a single framework (an IDE) or not, but you have some sort of environment.

The tools include at least

> 1. one or more editors to create files of various kinds, text and otherwise.
> 2. one or more compilers to translate your program files into machine code for one or more machine architectures
> 3. one or more run-time-environments in which you can execute your code, either on the target architecture or in a simulator

Additional tools that are usually needed are (not a complete list but will do for a start)

> 1. a test framework so that you can effectively write both unit tests (the code does what I think it does and doesn't break as I change things) and acceptance tests (the code does what the owner/customer really wants done - irrespective of my understanding).
> 2. automated error checkers to trace back exceptions and race conditions (among other issues)
> 3. a debugger that lets you interact directly with the target code as an aid in finding and repairing errors.
> 4. a design framework in which it is easy (or at least possible) to create design documents, which may be textual or graphical. They might be integrated with code generation or not.
> 5. a code repository and version control system so that old versions can be maintained and errors can be backed out of
> 6. a team-support system that helps a group of developers work on the same project. These tools may include simple communication tools (email...) or provide things like distributed pair programming.
> 7. a database system to hold necessary data used by the program. Sometimes a database is also used to store fragments of the program(s) themselves. The database might also contain required test data to assure the correct thing is built. Likewise it might contain information about the success or failure of test runs
> 8. a documentation system that can be used for either or both of program documentation of use by the team and user documentation that gives instructions to the end-user on effective use of the system
> 9. a way to make interaction with the file system easy and efficient, such as directory listings that let you easily open/save/close files
> 10. a way to maintain various "configuration files" so that the system can be tailored for its various uses
> 11. a way to keep all of the tools updated easily
> 12. automatic error checkers and style checkers beyond those provided by the compiler
> 13. For some kinds of software a sophisticated emulation environment to check the interaction of various components. Mobile apps often need servers and some way test the interactions, for example.

An Integrated Development Environment (say Eclipse or NetBeans) will integrate all of this into a single program that may use one or more multi-pane windows to provide a visual representation of all of the tools. A good one is tailorable by language and by need without cluttering up the workspace. A less integrated system (Emacs, say) provides all of these things through (possibly cryptic) user commands. An IDE requires a learning process itself, but it pays dividends if it is flexible and not restricted to a single language or architecture.

But even a simple text editor, a compiler, and a run-time for testing is a development environment and for many years was all that was available. Way back, the "text-editor" was just a card punch.

---

Note that not all files in a project are necessarily just text. Some projects require, for example, graphical files to show design.

---

I don't claim I have a complete list here. There are many other possibilities. Each person's development environment is personal. It is good if it makes them more productive and less frustrated. Is is subject to update and modification at any time that you learn of a new tool or technique.

---

Also note that not all of these are needed in every project and you don't need to be proficient in many of them to get started. But issues that arise as you work may help you see the need to expand your personal set.

> **Comments:**
> **username_5**: Online tutorials. If an IDE does not have decent online tutorials I tend to drop it like a ton of lead.  
> **username_0**: Thanks so much, this is exactly what I was looking for- username_4, could you also say that there is an interpreter instead of a compiler if it isn't compiled in to machine code?  
> **username_4**: Yes, certainly. There is very little difference between a compiler and an interpreter, actually. Everything but the back end is the same. The compiler outputs a file and the interpreter executes some intermediate code.  

---

### Answer by username_3 on 2017-12-26. Score: 1

In industry, the DEV environment is where developers are free to play and break anything (provided they fix it for those who follow). A typical enterprise shop will have a DEV, TEST/QA, and PROD environments, with developer access to DEV being nearly unlimited, but PROD being limited to end user support without significant from 5 layers of management and a pope.

DEV will typically mirror prod closely enough for practical purposes, but be underpowered to reflect its lesser usage.


---

