Mythical Man-Month (The Brooks's Law)
* Open Software Projects
* Steve McConnell (Rapid Development)
* Extreme Programming
* Adaptive Software Development
* One Minute Manager
* Parkinson's Law
|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 -|
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 ( 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
Project Survival Guide - Classics - provides
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
- "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:
|shuttle, geeks, and more||home - top of the page -|
- 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
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).
- 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
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
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.
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.
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
Underperformers may view attention as a reward for their unproductive behavior.
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.
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.
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.
Turning Average Programmers into Good Programmers Desirable profile for new hires
|Strong computer science education
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
When assessing productivity, bear in mind what a good programmer has to do every day...
|surf USENET, Slashdot etc.
contribute to news groups
write specs and designs
file bug reports on others' code
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.
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
- 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
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:
|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:
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.
- 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.
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
* www.cvshome.org/ - CVS (good, used by many open source projects)
* www.perforce.com/ - Perforce (this is the one used by Perl community)
* 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 )
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
4. Use rsh to run scripts on other servers
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".
- D.Knuth home page
* http://www-cs-faculty.stanford.edu/~knuth/books.html - D.Knuth's 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)
- 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 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
- 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.