LevSelector.com New York
home > Project Management & Version Control

Management
* The Mythical Man-Month (The Brooks's Law)
* Open Software Projects
* Steve McConnell (Rapid Development)
* Peopleware
* Extreme Programming
* Adaptive Software Development
* One Minute Manager
* Parkinson's Law

* Space shuttle, geeks, and more
* Practical Software Engineering
* Jesse Erlbaum
* ITIL * RUP * Agile
* version control - cvs - svn - efs
* configuration management
* literate programming
* some fun

 
It has been said that democracy is the worst form of government 
except all the others that have been tried. - Winston Churchill (1874-1965)

 
The Mythical Man-Month home - top of the page -

 

Frederick
Brooks		 * The Mythical Man-Month  (by Frederick Brooks)
Classics - based on experience from 1960s at IBM + 4 new chapters. A required reading in most SE (Software Engineering) and CS (Computer Science) courses. this book has become a bible for software developers. Brooks received the Turing Prize in 2000 ( often called "the Nobel Prize of Computing") from the Association for Computing Machinery.
One of the main ideas (also called "The Brooks's Law"): 'Adding manpower to a late software project makes it later.' Artists cannot be rushed, and too many cooks will surely spoil the broth.

 
Managing Open Software projects home - top of the page -

Does the Brooks Law apply to open software projects ?
R. Stallman: "If you don't have a deadline, you won't be likely to try to put more people on the job in that way. You will make use of more helpers only when they can actually help. Thus, I think that Brooks' Law does apply to [free software], but we have no inclination to try to violate it."
Jamie Zawinski: Apache project, Linux Kernel, and other large software projects, the bulk of the work is done by a few dedicated members or a core team -- what Brooks calls a "surgical team."  "In most open source projects," says Zawinski, "there is a small group who do the majority of the work, and the other contributors are definitely at a secondary level, meaning that they don't behave as bottlenecks."  ... "Most of the larger open source projects are also fairly modular, meaning that they are really dozens of different, smaller projects. So when you claim that there are ten zillion people working on the Gnome project, you're lumping together a lot of people who never need to talk to each other, and thus, aren't getting in each others' way." 
Brian Behlendorf (Apache & Collab.net): "We don't consciously think about it, but I think that the philosophy of keeping things simple and pushing out almost anything extraneous or nonessential to external modules has been followed fairly carefully in Apache. We've also been fairly successful (I think) in 'federalizing' the Apache process to sister projects." 
Larry Wall (Perl 6): " ... We have a working group model ...  Some of these were working groups set up to discuss one little issue. ... the core is going to be lean and mean, that implies that a lot of stuff are going to move out of the core."


 
Steve_McConnell home - top of the page -

 

Steve
McConnell		  Steve McConnell ( www.construx.com/stevemcc - also  www.construx.com )
Steve is Chief Software Engineer at Construx Software where he divides his time between leading custom software projects, consulting to companies in the shrink-wrap industry, and writing books and articles.
  * Rapid Development : Taming Wild Software Schedules.  Classics - Best Practices, classic mistakes, statistics, will make you laugh. Book covers rapid development strategy, core issues in rapid development, classic mistakes, risk management, estimation, scheduling, motivation, teamwork, customer-oriented development, productivity tools, and project recovery. The book's explanations are enhanced by the inclusion of 27 case studies, life-like descriptions of how the theory and practice of rapid development play out in real world projects

  * Software Project Survival Guide - Classics - provides a blueprint for a successfully managed project  - 3..25 team members, 3..18 months. Advice on structuring, as well as on dealing with politics, people issues, and other project and career killers. Enjoyable reading.
- "With poorly planned processes, developers spend a lot of their time correcting mistakes."
- "Success in software development depends on making a carefully planned series of small mistakes in order to avoid making unplanned large mistakes."
- "The effective software project manager acts as an orchestra conductor, as the person who coordinates the work of the team."
- "Requirements gathering and specification is an open-ended activity."
- "The only way to break the testing addiction cycle is to bite the bullet and allocate the upstream resources needed for quality assurance on a project."
- "The architecture should contain a high-level discussion of the major design alternatives that were considered, the reasons that the selected approaches were chosen, and the reasons other alternatives were not selected."
- "Once you realize that the goal of architecture is to reduce complexity, it becomes clear that the architect must focus as much on what to leave out of the software as on what to put in."
- "If you're going to get bad news on a software project, it's best to get it early because of the upstream/downstream effect on project costs."
- Follow the advice given to the team that designed the Algol programming language: "The best" is the enemy of "the good."  

- The architecture team creates and updates a Software Architecture document. 
- The architecture emphasizes simplicity over cleverness. 
- The architecture supports the Staged Delivery Plan. 
- The architecture addresses all the project's requirements, and requirements coverage is documented with a completed requirements traceability matrix.
- "It is important to drive the software to a releasable quality level often, in order to prevent the project from accumulating a host of loose ends that can't be tied up when you actually do want to release the software."  ... "Shaky estimates are facts of life in software projects, and staged deliveries help to minimize the damage shaky estimates can cause."

  * After The Gold Rush -  author argues that the methodical abuse of programmers causes bad code, unhappy people, and reduced profitability in the long run. In place of the existing system of crazy deadlines, clueless marketing, and scattershot programming strategies, McConnell proposes making software engineering into a "true profession" - like more mature professions, especially the engineering profession. 

 
Peopleware home - top of the page -

* Peopleware : Productive Projects and Teams, 2nd Ed. - by Tom Demarco, Timothy Lister
Classics - major issues of software development are human, not technical. Joyful reading.
Main ideas: give smart people physical space, intellectual responsibility and strategic direction. DeMarco and Lister advocate private offices and windows.  They advocate creating teams with aligned goals and limited non-team work. They advocate managers finding good staff and putting their fate in the hands of those staff. The manager's function, they write, is not to make people work but to make it possible for people to work.
- "Ever wonder why everybody at Microsoft gets their own office, with walls and a door that shuts? It's in there [ in the book]. Why do managers give so much leeway to their teams to get things done? That's in there too. Why are there so many ... teams at Microsoft that are remarkably productive? Mainly because Bill Gates has built a company full of managers who read Peopleware."
- Peopleware's persuasiveness comes from its numbers - from its simple, cold, numerical demonstration that improving programmers' environments will make them more productive. The numbers in Peopleware come from DeMarco and Lister's Coding War Games, a series of competitions to complete given coding and testing tasks in minimal time and with minimal defects. The Games have consistently confirmed various known facts of the software game. For instance, the best coders outperform the ten-to-one, but their pay seems only weakly linked to their performance. But DeMarco and Lister also found that the best-performing coders had larger, quieter, more private workspaces. It is for this one empirical finding that Peopleware is best known.
- authors offer a theory: that managers should help programmers, designers, writers and other brainworkers to reach a state that psychologists call "flow" - an almost meditative condition where people can achieve important leaps towards solving complex problems. It's the state where you start work, look up, and notice that three hours have passed. But it takes time - perhaps fifteen minutes on average - to get into this state. And DeMarco and Lister that today's typical noisy, cubicled, Dilbertesque office rarely allows people 15 minutes of uninterrupted work. In other words, the world is full of places where a highly-paid and dedicated programmer or creative artist can spend a full day without ever getting any hard-core work. Put another way, the world is full of cheap opportunities for people to make their co-workers more productive, just by building their offices a bit smarter. (from review by David Walker).

 
Extreme Programming home - top of the page -

* Extreme Programming Explained: Embrace Change by Kent Beck ( cnet_article )
XP (eXtreme Programming):
* Distinguishing between the decisions to be made by business interests and those to be made by project stake holders.
* Writing unit tests before programming and keeping all of the tests running at all times. 
* Integrating and testing the whole system - several times a day. 
* Producing all software in pairs, two programmers at one screen. 
* Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity. 
* Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.
Why is XP so controversial? Some sacred cows don't make the cut in XP:
* Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators - every XP programmer participates in all of these critical activities every day. 
* Don't conduct complete up-front analysis and design - an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development. 
* Develop infrastructure and frameworks as you develop your application, not up-front - delivering business value is the heartbeat that drives XP projects. 
* Don't write and maintain implementation documentation - communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.
You may love XP, or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software

 
Adaptive Software Development home - top of the page -

* Adaptive Software Development: A Collaborative Approach to Managing Complex Systems - by James A. Highsmith III, James A. Highsmith
uses mountain climbing to illustrate his points about teamwork, planning and adaptation to rapidly changing conditions. Concepts like "adaptive" and "emergent". ... must be a process of aggressive, rapid adaptation to changing conditions.  "Rules can be barriers to hide behind or guidelines for the wise to consider and break when the circumstances justify it." 

 
One Minute Manager home - top of the page -

* The One Minute Manager - Spencer Johnson & Kenneth H. Blanchard
Classical bestseller ( > 7 mln copies sold).  goal setting, motivating, training, praising and even reprimanding employees. 

* The One Minute Manager Meets the Monkey - William, Jr. Oncken, et al
who owns the monkey? monkey = next move. ... put all monkeys on the backs of your subordinates. 

 
Parkinson's Law home - top of the page -

* Parkinson's Law by C. Northcote Parkinson
Classic - witty, brilliant.

Professor Northcote Parkinson (1909-1993) - British historian, author, and formulator of "Parkinson's Law," the satiric dictum that "Work expands to fill the time available for its completion."

"Administrators make work for each other, he said, so that they can multiply the number of their subordinates and enhance their prestige."

His second law was intended as a jibe at government functionaries, who he thought were inclined to expand their own ranks indefinitely, so long as taxes could be raised.

Written in a deadpan but mercilessly funny style, Parkinson's Economist essays were issued in book form in Parkinson's Law, or The Pursuit of Progress (1958). Apart from the books that made him famous, Parkinson wrote numerous historical works, including the critically acclaimed The Evolution of Political Thought (1958).

Here is the essense of some of Parkinson's main laws:
  • Work expands so as to fill the time available for its completion. This law has many consequences. For example, it shows why the British Colonial Office has grown in number of employees as the actual number of colonies declined - so that it employed more people when the number of colonies had been reduced to zero than when they were at their highest number.
  • Expenditure rises to meet income. ( Unit costs of public services tend to increase to consume the available funding. Data expands to fill the space available for storage. Network traffic expands to fill the available bandwidth, etc. Unfortunately this law is not applicable to our wallet nor to its contents. Pity.)
  • Expansion means complexity, and complexity - decay.
  • Policies designed to increase production increase employment; policies designed to increase employment do everything but.
  • Democracy equals inflation (people vote for higher pay rather than for increased production)
  • Delay is the deadliest form of denial.
  • The matters most debated tend to be the minor ones where everybody understands the issues.
  • Comities become less effective after they grow larger than 8 members.

 
shuttle, geeks, and more home - top of the page -

* www.fastcompany.com/online/06/writestuff.html - how the software for Space Shuttles is made reliable
* www.fastcompany.com/online/25/geeks.html  - how to manage geeks
See also some ideas on "more on simplicity" page.

 
Practical Software Engineering - Peopleware home - top of the page -

Summary by David Maulsby.
 
Human, not technical problems seem to be at the root of software projects failure.
Parkinson?s law: ?Work expands to fill the time allocated for it.?
Management response: set impossibly optimistic delivery dates.
Estimates actually seem counter-productive (people do more without estimates).
The Solutions:
- Build a close-knit team, with shared responsibility
    - Programmers do the estimating
    - Make a cult of quality
    - Provide lots of satisfying closure
    - Build a sense of eliteness
    - Allow and encourage individuality
    - Provide strategic but not tactical direction
- Preserve and protect successful teams

How do we accomplish these objectives?

Only the best people contribute significantly
A good programmer is 10 times more productive than an average one (Brooks 1995).
Average programmers will consume nearly their entire work day just reading and understanding new code generated by good programmers.
Therefore, the successful software engineering manager...
  - Creates a work environment where good programmers will be satisfied enough to stay.
  - Creates a system in which average programmers become good.

Consensus is essential yet nearly impossible:
Software people at all levels perceive themselves to be equally intelligent, hence require consensus.
A leaf-node worker is more expert than any manager, making it difficult to engage in a technical argument.
People with bad ideas and low productivity often think of themselves as supremely capable.
As for programmers who are supremely capable, there is no reason to expect consensus from them.
Therefore, the successful software engineering manager...
Achieves credibility with staff by participating in the work - whether by coding, designing data models, writing system design documents, journal articles.
Delegates decisions to small groups that include someone trusted and competent.
Involves key project stakeholders (customer reps) in decisions, so that developers perceive their accountability.
Makes the tough call when democracy cannot.

Measurement of software productivity is notoriously difficult:
The world is full of products that failed due to overly complex and tasteless designs.
Systems that experts evaluated and found wanting, such Unix (1970), eventually proved to have great utility.
Quality and productivity have no obvious correlation (sometimes you have to break everything in order to make it work better).
Therefore, the successful software engineering manager...
Measures productivity in terms of tests passed, bugs fixed, knowledge acquired and communicated to the team.
Considers peers' assessments of one another.
Provides feedback to programmers daily, and in private.

Parkinson's Law: work expands to fill the time provided.
A deadline just gives someone an excuse to procrastinate and do nothing until the very end.
Software is an experimental science; you can always do more experiments.
Software is infinitely perfectible.
Therefore ...
Instead of setting deadlines, set the pace. Daily builds and demos for the team.

People do what you reward them to do, not what you hope they will do.
In Bringing out the Best in People, Aubrey Daniels notes "If we always did what we were told, we would eat only nutritious foods, never drink too much alcohol, and exercise regularly."
An annual review and bonus is not classically considered a very good way to motivate people. It is too far removed from their daily decisions.
Therefore ...
Provide small, frequent rewards for achievement.

Underperformers get most of the attention; this encourages underperforming.
It's all too easy to neglect your best staff because they don't need direction.
Underperformers may view attention as a reward for their unproductive behavior.
Therefore ...
Give all staff - especially the best ones - positive reinforcement every day.

Ownership engenders productivity.
Non-ownership systems demand very accurate setting of standards.
Ownership-oriented systems include contingent rewards with an almost unlimited upside, and are thus effective at getting as much discretionary effort out of workers as possible.
Therefore ...
Put programmers in contact with customers, so they understand accountability.
Spread ownership of code throughout the team.
Base compensation on success of the project.

Building and Keeping a Good Software Team

What is the best way to attract some good software engineers to your organization?
Hire a few to begin with.
What attracts good programmers?
Traditionally the best programmers seek the most challenging problems.
Spread trivial problems around and make sure they are scheduled for trivial amounts of time - do the hard stuff first!

The prime source of ego-gratification for programmers is to have other programmers admire their work.
Open-source software projects thus have a big recruiting advantage.
Make sure team members get to work with one another's code. Rather than silo the project by assigning one module to each programmer, have them work in small groups and share code across groups.

What kind of working environment is necessary for programmer satisfaction?
Good programmers want to achieve; therefore, removing barriers to achievement is the most important step.
Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped.
Adopt a lightweight process and flatten the project management structure.

A good physical working environment is essential.
Your business success will depend on the extent to which programmers essentially live at your office.
For this to be a common choice, your office had better be nicer than the average programmer's home.
Great programmers get a lot of positive reinforcement from their work itself.
They write some code and immediately can see it in action. That keeps them at work for hours.
Encourage frequent builds, keep the system integrated, and require that all code be tested as soon as it is written.
Do these things and programmers will usually see their code working as it should. Neglect these things and they will have to spend hours figuring out why it doesn't work.

Turning Average Programmers into Good Programmers Desirable profile for new hires
Strong computer science education
High IQ
Good communicator both in speech and writing
Motivated - programs for fun in leisure time, wants to learn more
But most important of all... relevant experience

Principles for building programming skill
Proficiency improves with repetition.
To retain proficiency, you must learn to perform the task rapidly.
Training research shows that if you get speed now you can get quality later.
Technology shifts force a programmer to go through bursts of learning every year or two.
Therefore ...
Whatever the training task, the pace must be ruthlessly brisk.
The learner should be expected to build at the same pace as an experienced developer.
The difference between the learner and the wizard is that you expect the learner to make a lot of mistakes.

When assessing productivity, bear in mind what a good programmer has to do every day...
surf USENET, Slashdot etc.
contribute to news groups
read docs
question colleagues
write specs and designs
write docs
write code
test
fix bugs
file bug reports on others' code
attend meetings
help sales and marketing staff
play with toys to keep the brain in shape

Turning Good Programmers into Good Managers
Software engineers respond best to management by a fellow programmer - one they respect.
But software teams can ill afford to sacrifice good programmers to management roles.
Therefore ...
Minimize the number of managers by adopting small teams, lightweight process and self-management.
Make management a part-time role - manage one project, code on the next, or manage and code if possible.
Biggest risk of having a manager work as a programmer is that s/he will neglect to review the other programmers' work. 
Solution - decouple responsibility for review from responsibility for scheduling review: have administrative assistants do the scheduling.

Building and managing a peak-performing software engineering organization is challenging but extremely profitable. The core Ariba product was written by two programmers, yielding a market capitalization of $30 billion.

 
Jesse Erlbaum home - top of the page -

Here are some ideas summarized from listening to Jesse Erlbaum.  Jesse Erlbaum is the Chief Technology Officer for the Vanguard Media Corporation (www.vm.com), located in New York City, where he has worked since 1994. Vanguard Media develops custom software for a variety of clients, from the WPP Group to Time, Inc.

Most of our work is not rocket science. We are using operating systems, programming languages, databases, which were invented ~ 25 years ago. Most of our applications are pretty standard and simple:  Some back-end SQL database, some browser front-end, and some code in the middle.

Major clients in NY City - Finance, Publishing, Advertising

Difference in dev.time/quality of the result between languages (religious arguments Perl vs Java, etc.) ~ 10-15%
Difference between programmers and processes ~ 1000%

"Don't build it - you will not need it."

Talking to client - agree on 2 phase approach:
0 - pre-sign - agree on 2-phase approach
1st phase - preparing specifications and estimate
2nd phase - actually implementing

Specifications:
  - are prepared involving end-users (and developers)
  - constitute ~25 ..50% of total development costs
  - allows to give a time/money estimate (don't overpromise and don't take unnecessary responsibilities)

For a typical web-based application:
  1. UI Screens (just buttons, form fields and links - may be HTML-templates)
  2. Data model
  3. State Transition Diagrams (1 state per screen - just drawing, or using simple software like www.objectdomain.com)
  4. Textual description
  5. Revised Estimate and schedule

Implementing:
1. Each developer has his/her own environment absolutely equivalent to production.
    No need to make any changes to the code during production release.
    Apache server config file is generated automatically for each user (using HTML::Template, by the way).
2. Use CVS for code, modules, documentation, etc.
    CVS can not guarantee anything - it just helps people to communicate.
3. Put main reusable modules in public domain (CPAN) to avoid legal explanations.
4. Use Unix to build reliable applications => low maintenance.
5. Use Apache & MySQL.
6. Use HTML::Template to separate the work of Programmers and Designers.
7. Use CGI::Application to properly structure pieces of the application.
8. Prepare documentation (so that your mother can understand) and keep it in devdocs directory
9. keep DBLOG - textual description of all changes in the database,
    in which environment they were implemented, and cut/paste code to implement those changes
10. keep working versions of public modules in CVS too.


 
ITIL - IT Infrastructure Library home - top of the page -

ITIL - the IT Infrastructure Library. It is a set of best practices on organizing IT process. Originally created in 1980 at the Office of Government Commerce in UK. You can get certified in it. Current ITIL is a set of 5 main books which you can buy for ~600, or as a PDF for ~$430. They are:

You can learn more here:

You can also buy the ITIL books (and 3rd party books) on amazon - just search for ITIL.

For a good introduction into main concepts you can read this book: "IT Service Management: An Introduction" (ISBN 9080671347)

The good thing about ITIL is that it covers a lot of ground, so it is valuable introduction for a new manager. There is also such thing as ITIL certification.

On the negative side, ITIL was criticized, because its approach is too centered on the IT itself, and less focused on what IT does for a customer or for a business.

There are many vendors providing software (free or commercial) to implement different parts of ITIL recommendations. See for example here:

http://www.wareprise.com/2007/04/14/open-source-itil-software/

RUP = IBM Rational Unified Process home - top of the page -

RUP (Rational Unified Process) - an electronic knowledge base of best practices for software development - originally developed by Rational Software, and now available from IBM as part of their product called "IBM Rational Method Composer".

The people behind RUP - Ivar Jacobson, Grady Booch, James Rumbaug, et al - creators of UML (Unified Modeling Language). In RUP they applied the same object-oriented modeling to software development process. This is a big improvement in comparison to monolitic "waterfall" style methods, which are prone to failure.

Here are some concepts of RUP:


 

Agile Software Development home - top of the page -

Agile Software Development - a set of methodologies for software development where, instead of long-term structured planning, the work is done in small increments (1..4 weeks) followed by a review and re-planning as needed to better align with customer needs. The approach is based on self-organizing teamwork, frequent testing, small-team accountability.

The principles of agile development were proposed in 2001 and posted here: http://agilemanifesto.org/principles.html . Here is a local copy for convenience:
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Here is a good description: http://en.wikipedia.org/wiki/Agile_Software_Development


 

Version Control home - top of the page -

My favorite version control system is subversin (svn):

Subversion was developed as improvement of CVS:

Another good version control is Git - http://git-scm.com/ - distributed (!) and fast version control.

Here is a comparison between SVN and Git: http://git.wiki.kernel.org/index.php/GitSvnComparison

 

google/../Revision_Control_System/ - version control on Google

Here are some of Version Control Systems:

* RCS (Revision Control System) is a version control system. It offers a basic level of functionality.
* www.tru64unix.compaq.com/faqs/... - RCS and SCCS commands
* www.xs4all.nl/~erikgrnh/acorn/rcsinfo/commands.html - RCS commands
* www-rnks.informatik.tu-cottbus.de/~mm/books/docs/rcs/rcs_3.html - basic RCS commands
* www-rnks.informatik.tu-cottbus.de/~mm/books/docs/rcs/rcs_4.html - more RCS commands
* www.nmt.edu/tcc/help/tool/rcs/rcs.html - commands
* www.ComponentSoftware.com/csrcs/CS-RCS - Inexpensive graphical RCS for Windows 95/NT, free for individuals, includes free standalone CSDiff. (ComponentSoftware)
* www.gnu.org/software/rcs/rcs.html - GNU RCS - The GNU Revision Control System, a popular free SCM tool on the UNIX platforms. (Free Software Foundation)
* www.csc.calpoly.edu/~dbutler/tutorials/winter96/rcs/ - RCS Tutorial - the Revision Control System - Frames-based short HTML online tutorial, by David L. Spencer.
* wwwipd.ira.uka.de/~tichy/ - Walter F. Tichy's Home Page - Professor of Computer Science at the University Karlsruhe, Germany, creator of RCS. Some pages in English, some in German, including two talks on software configuration management.
* wwwipd.ira.uka.de/~RCE/ - RCE: the Revision Control Engine - Designated successor to RCS. Offers VRCE, Java based graphic user interface, and Byte Differencing Engine, efficient delta revision storage that supports all data types. API enables integration into any electronic data management system. 
* heavenly.nj.nec.com/tichy91rc.html - RCS - A System for Version Control - Paper describing and introducing RCS, Walter Tichy, Software-Practice & Experience, 15(7):637-654, July 1985. Online in PS and PDF format, with links to many citations. Provided by ResearchIndex. 
* www.trumphurst.com/dosrcs.phtml - DOSRCS - DOS port of GNU Revision Control System. Zip files, executables, documentation, and Microsoft C source. By Trumphurst. 

* SCCS (Source Code Control System) is similar to RCS.
  * www.tru64unix.compaq.com/faqs/... - commands (look for delget command)
  * www.oreilly.com/catalog/rcs/chapter/ch04.html - O'Reilly book
  * webdocs.sequent.com/docs/dptgab01/ch_11.htm - commands
  * www.rzg.mpg.de/rzg/batch/NEC/sx4a_doc/g1ab01e/chap8.html - tutorial

* CVS
  * www.cvshome.org/ - CVS (good, used by many open source projects)

* Perforce
  * www.perforce.com/ - Perforce (this is the one used by Perl community)

* PVCS -
  * www.merant.com/products/pvcs/ -

* Microsoft Visual SourceSafe - part of Visual Studio

==========================================================

There are many free Version Control Packages:
(Aegis, CERN - CMZ, CVS, DVS, Inversion, jCVS, Keep-It, ODE, PRCS, RCS, SCCS (free implementations), TCCS, tkCVS )
and many commercial packages:
(+1 Software Engineering - +1CM, AccuRev.com - AccuRev/CM, Sequel UK - Alchemist, BitMover, Inc - BitKeeper, Aldon - Aldon/CMS, Industrial Strength Software - ChangeMaster, Reliable Software - Code Co-op, Crystaliz, Inc. - Concorde, Agile Software Corp, NCI - Control, ComponentSoftware - CS-RCS, Configuration Data Services - ECMS, Lockheed Martin - EagleSpeed, Quality Software Components, Ltd. - GP-Version, JavaSoft - JavaSafe, Tesseract - Lifecycle Manager, British Aerospace - LifeSpan, Realcase - Multi-Platform Code Management, Perforce Software - Perforce Fast SCM System, Data Design Systems - PrimeCode, Merant - PVCS, Synergex - PVCS, Qumasoft - QVCS, Inroads Technology - Rapid Implementation Technology, Ultracomp - Red Box, DuraSoft - Revision Control Engine, Software Ever After - R-Sea-Yes, Lucent Technologies - Sablime, MKS - SDM-Implementer, UniPress - Source Code Manager, MKS - Source Integrity, SourceGear - SourceOffSite, SiberLogic - SourceTrack, Giant Technologies - Visual SourceMail, Microsoft - Visual SourceSafe for Windows, Mainsoft Corporation - Visual SourceSafe for Unix, Starbase Corporation - StarTeam, Interwoven - TeamSite, SoftLanding Systems - TurnOver, Burton Systems - TLIB, George James Software - VC/m, UNI Software Plus - VOODOO, Sun - WorkShop TeamWare )

Distributed Deployment

http://openefs.org/ - Enterpise File System - allows to deploy / roll back software arond the world with a simple command.
Unix-based. Open source. Based on software originally developed by Phil Moore at Morgan Stanley, and then at Merrill Lynch.


 
Configuration management home - top of the page -

Configuration Management Web Site - good list of links:
* www.cmtoday.com/yp/configuration_management.html - lists of links
*www.cmtoday.com/yp/free.html - free
* www.cmtoday.com/yp/commercial.html - commercial
* www.cmtoday.com/yp/tracking.html - problem tracking
 

Practical solution which I've seen working pretty well:
1. Use CVS for version control to move files between development, QA, Pre-production and production stages.
2. Use Autosys-scheduled shell and Perl scripts
3. Use rsync (which is better than rdist) instead of ftp to distribute files
  - www.linux.gr/cgi-bin/man2html/usr/share/man/man1/rsync.1.gz
  - www.uni-duesseldorf.de/cgi-bin/man2html/software/sw/man/man1/rdist.1
4. Use rsh to run scripts on other servers
  - http://theoryx5.uwinnipeg.ca/gnu/inetutils/rsh.1.html
5. Use Microsoft SMS Installer - a tool to create software installation packages for distribution to clients.
6. Parse cvs logs to make mailing lists of developers contributed chagnes - and automatically notify them (especially in case of problems).
7. Have scripts to deploy the whole system (including shared libraries, core applications, misc. other applications) - or only a small part of the system.

 
Documentation home - top of the page -

There are many way to document your project.
I like to make a local web site where I document everything manually.
User manuals usually are prepared as MS Word documents or PDF files for Adobe Acrobat.

One good way to make documentaion is by using DocBook XML Publishing:
* www.docbook.org/ - home page for the book "DocBook: The Definitive Guide (O'Reilly XML)" by Norman Walsh and Leonard Muellner. This is the official documentation for DocBook.
* www.docbook.org/tdg/html/docbook.html - read book online
Another book - "DocBook XML Publishing (With CD-ROM)" by Joe Brockmeier

 
Literate Programming home - top of the page -

Literate programming is a methodology that combines a programming language with a documentation language, thereby making programs more robust, more portable, more easily maintained, and arguably more fun to write than programs that are written only in a high-level language. The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer. The program is also viewed as a hypertext document, rather like the World Wide Web.

Literate programming was introduced by Donald E. Knuth (), Professor Emeritus of The Art of Computer Programming at Stanford University. D.Knuth is mostly known as an author of famous 3-volume set "The Art of Computer Programming".

* http://www-cs-faculty.stanford.edu/~knuth/index.html - D.Knuth home page
* http://www-cs-faculty.stanford.edu/~knuth/books.html - D.Knuth's books

Books:
* www-cs-faculty.stanford.edu/~knuth/lp.html - Literate Programming - A Book by Donald Knuth, who started the ideas about Literate Programming with WEB. (1992, 368pp, ISBN 0-937073-80-6)

Links:

* www.literateprogramming.com - Literate Programming, Resources for Literate Programming. Consulting services. Download freeware for Windows 95, 98, and NT. Learn about the CWEB programming language.
* http://directory.google.com/Top/Computers/Programming/Literate_Programming/ - literate programming on Google search engine

LEO:
* www.jserv.com/jk_orr/xml/leo.htm - LEO Resource Page by Joe Orr.  Information about LEO, an editor that facilitates Literate Programming. Includes XSLT stylesheets for importing to and exporting from LEO.
    * http://personalpages.tds.net/~edream/front.html - LEO's home page (Edward K. Ream)
    * https://sourceforge.net/projects/leo/ - LEO on SourceForge site

* www.eecs.harvard.edu/~nr/noweb - Noweb, A Simple, extensible tool for Literate Programming.
* www.cs.cmu.edu/~vaschelp/Programming/Literate/literate.html - Literate Programming -- Propaganda and Tools - An overview of the concepts and some ideas for applying Literate Programming.
* www-cs-faculty.stanford.edu/~knuth/cweb.html - The CWEB System of Structured Documentation - By Donald Knuth and Levy, describing a prominent system of Literate Programming.
* shelob.ce.ttu.edu/daves/lpfaq/faq.html - The Literate Programming FAQ - a good place to start looking for information
* www.desy.de/user/projects/LitProg.html - Literate Programming Library - a large collection of links to related resources.
* www.oasis-open.org/cover/xmlLitProg.html - SGML/XML and Literate Programming - information on applying SGML and XML to Literate Programming.
* liinwww.ira.uka.de/bibliography/SE/litprog.html - Bibliography on Literate Programming - a part of the Computer Science Bibliography Collection.
* www.ems.uq.edu.au/Seminars/XML_LitProg - XML and Literate Programming - a seminar by Anthony B. Coates on combining XML and LP.
* dec.bournemouth.ac.uk/staff/pknaggs/papers/literate.html - Literate Programming in Forth, - an article by Peter J.Knaggs, originally presented at euroFORTH'95.
* www.c2.com/cgi/wiki?LiterateProgramming - Literate Programming - The WikiWiki entry point for related information and discussions.

 
Some fun home - top of the page -

Some relief from www.dack.com:
* http://mindprod.com/unmain.html -  Howto write an unmantainable code
* The Web Economy Bullshit Generator - This is fun for the whole family.
* The Excellent Intranet Cost Analyzer  - Quickly calculate the annual cost of a company's poorly designed intranet.