Practical Development Environments http://www.oreilly.com/catalog/practicalde. This covers all manner of tools: version control, build tools, testing environments, bug tracking, documentation and release. Each chapter talks about general ideas, and then looks at specific tools (some open, some closed).
I suggest exposing them to the kind of tools that are used to develop real open source (and closed) projects: version control, build tools, test harnesses, bug tracking, and installation tools. Even if their 5K LOC program could be compiled using a shell script, show them what they would use when it becomes 50K LOC.
There's even a new book from O'Reilly about these kinds of tools - "Practical Development Environments" (http://www.oreilly.com/catalog/practicalde). I wrote it because I couldn't find a similar book for software toolsmiths.
I'm glad to see someone else raise this point. It was part of a discussion I led last week at the Software Development Best Practices conference in Boston, and also appears in my new O'Reilly book "Practical Developments Environments" (http://www.oreilly.com/catalog/practicalde). Enough of the plugging, here's my take on the problem. I've done both #1 and #2 and want to see someone do #3.
1. Most people clone or link multiple bugs together to represent the bug in each release. This seems heavyweight, and may lead to bug numbers changing for each release, which could confuse customers.
2. Other people add more fields (ToBeFixedIn_1, ToBeFixedIn_2,...). As was pointed out, this makes generating reports painful.
3. What really should happen is that some application has to keep track of which build the bug appeared in, which build it was discovered in, and how each build is related to other builds. A picture would look like a tree with branches for each release. The key is to assume that a bug still exists in the all builds and branches after it is discovered, until confirmed not to exist.
With this information, you could ask the key question "which build or releases does this bug exist in?". Fixing the bug in a certain release updates this information. It's doesn't seem too much more work, except that when you create a new branch, you have to associate the new builds with the branch.
There is an upcoming book from O'Reilly named Practical Development Environments about development environments for software - the tools you use and how you use them. It's mainly for Unix and Windows. The draft for review is nearly complete. I'm the author.
I've no idea what animal it will have on the cover. Any suitable suggestions?
Slashdot Mirror
Practical Development Environments http://www.oreilly.com/catalog/practicalde. This covers all manner of tools: version control, build tools, testing environments, bug tracking, documentation and release. Each chapter talks about general ideas, and then looks at specific tools (some open, some closed).
~Matt
(Disclaimer: I wrote it)
I suggest exposing them to the kind of tools that are used to develop real open source (and closed) projects: version control, build tools, test harnesses, bug tracking, and installation tools. Even if their 5K LOC program could be compiled using a shell script, show them what they would use when it becomes 50K LOC.
There's even a new book from O'Reilly about these kinds of tools - "Practical Development Environments" (http://www.oreilly.com/catalog/practicalde). I wrote it because I couldn't find a similar book for software toolsmiths.
I'm glad to see someone else raise this point. It was part of a discussion I led last week at the Software Development Best Practices conference in Boston, and also appears in my new O'Reilly book "Practical Developments Environments" (http://www.oreilly.com/catalog/practicalde). Enough of the plugging, here's my take on the problem. I've done both #1 and #2 and want to see someone do #3.
1. Most people clone or link multiple bugs together to represent the bug in each release. This seems heavyweight, and may lead to bug numbers changing for each release, which could confuse customers.
2. Other people add more fields (ToBeFixedIn_1, ToBeFixedIn_2, ...). As was pointed out, this makes generating reports painful.
3. What really should happen is that some application has to keep track of which build the bug appeared in, which build it was discovered in, and how each build is related to other builds. A picture would look like a tree with branches for each release. The key is to assume that a bug still exists in the all builds and branches after it is discovered, until confirmed not to exist.
With this information, you could ask the key question "which build or releases does this bug exist in?". Fixing the bug in a certain release updates this information. It's doesn't seem too much more work, except that when you create a new branch, you have to associate the new builds with the branch.
There is an upcoming book from O'Reilly named Practical Development Environments about development environments for software - the tools you use and how you use them. It's mainly for Unix and Windows. The draft for review is nearly complete. I'm the author.
I've no idea what animal it will have on the cover. Any suitable suggestions?