• This is a short 40 page analog, but really classic writing on Open Source Software philosophies. Eric also explores “Management and the Maginot Line” - a few points on why a manager based approach will not outperform a community based approach to developing software.

    Rules of thumb

    • Every good work of software starts by scratching a developers personal itch.
    • Good programmers know what to write. Great ones know what to rewrite (and reuse).
    • Plan to throw one away; you will, anyhow
    • If you have the right attitude, interesting problems will find you.
    • When you lose interest in a program, your last duty of call to it is to hand it off to a competent successor
    • Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging
    • Release early. Release often. And listen to your customers.
    • Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
    • Smart data structures and dumb code works a lot better than the other way round.
    • If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
    • The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
    • Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
    • Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
    • Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
    • When writing gateway software of any kind, take pains to disturb the data stream as little as possible - and never throw away information unless the recipient forces you to!
    • When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
    • A security system is only as secure as its secret. Beware of pseudo-secrets.
    • To solve an interesting problem, start by finding a problem that is interesting to you.
    • Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

    Do Not Speak
    Riding Trooper
    Comments disabled.