×

Loading...
Ad by
  • 予人玫瑰,手有余香:加拿大新天地工作移民诚聘求职顾问&行业导师!
Ad by
  • 予人玫瑰,手有余香:加拿大新天地工作移民诚聘求职顾问&行业导师!

好文共享-Software Engineering Proverbs(软件工程师箴言)

本文发表在 rolia.net 枫下论坛Software Engineering Proverbs
(collected by Tom Van Vleck)

A clever person solves a problem.
A wise person avoids it.

-- Einstein

André Bensoussan once explained to me the difference between a programmer and a designer:

"If you make a general statement, a programmer says, 'Yes, but...'
while a designer says, 'Yes, and...'"

No matter what the problem is,
it's always a people problem.

Jerry Weinberg

Wexelblat's Scheduling Algorithm:

Choose two:

* Good
* Fast
* Cheap

Craziness is doing the same thing and expecting a different result.

Tom DeMarco, rephrasing Einstein, who said

Insanity: doing the same thing over and over again and expecting different results.

"There's no time to stop for gas, we're already late"

-- Karin Donker
Deming's 14 points

1. Create constancy of purpose.
2. Adopt the new philosophy.
3. Cease dependence on mass inspection to achieve quality.
4. Minimize total cost, not initial price of supplies.
5. Improve constantly the system of production and service.
6. Institute training on the job.
7. Institute leadership.
8. Drive out fear.
9. Break down barriers between departments.
10. Eliminate slogans, exhortations, and numerical targets.
11. Eliminate work standards (quotas) and management by objective.
12. Remove barriers that rob workers, engineers, and managers of their right to pride of workmanship.
13. Institute a vigorous program of education and self-improvement.
14. Put everyone in the company to work to accomplish the transformation.

We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer -- and keep pouring our sewage into our water supply.

-- Tom Van Vleck
The Troops Know

* The schedule doesn't have enough time for maintenance in it.
* A lot of bugs get past the tests.
* Most old code can't be maintained.

To go faster, slow down. Everybody who knows about orbital mechanics understands that.

-- Scott Cherf
Everybody Knows:

* Discipline is the best tool.
* Design first, then code.
* Don't patch bugs out, rewrite them out.
* Don't test bugs out, design them out.

Everybody Knows:

* If you don't understand it, you can't program it.
* If you didn't measure it, you didn't do it.

Everybody Knows:

If something is worth doing once, it's worth building a tool to do it.

Your problem is another's solution;
Your solution will be his problem.
Everybody Knows:

* If you've found 3 bugs in a program, best estimate is that there are 3 more.
* 60% of product cost comes after initial shipment.

The significant problems we face cannot be solved by the same level of thinking that created them.

-- Albert Einstein

On the radio the other night, Jimmy Connors said the best advice he ever got was from Bobby Riggs:

* do it
* do it right
* do it right now

It is not enough to do your best: you must know what to do, and THEN do your best.

-- W. Edwards Deming

A leader is best when people barely know that he exists.
Less good when they obey and acclaim him.
Worse when they fear and despise him.
Fail to honor people, and they fail to honor you.
But of a good leader, when his work is done, his aim fulfilled,
they will say, "We did this ourselves."

-- Lao-Tzu

You must be the change
You wish to see in the world

-- Gandhi

Experiment escorts us last,
His pungent company
Will not allow an axiom
An opportunity.

-- Emily Dickinson

when the cart stops
do you whip the cart
or whip the ox?

Q: How many QA testers does it take to change a lightbulb?
A: QA testers don't change anything. They just report that it's dark.

Kerry Zallar

Q: How many software engineers does it take to change a lightbulb?
A: Just one. But the house falls down.

Andrew Siwko

One test is worth a thousand opinions.

"If you didn't write it down, it didn't happen."

This saying is popular among scientists (doing experiments), but I believe it applies to software testing, particularly for real-time systems.

--Larry Zana

We reject kings, presidents, and voting.
We believe in rough consensus and running code.

--Dave Clark (1992)

I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don't, and the spirit of the passionate intellect that has tied them together, or tried. That's why programming---or buying software---on the basis of "lists of features" is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess.

-- Ted Nelson

Software is Too Important to be Left to Programmers, by Meilir Page-Jones.

"If you think good architecture is expensive, try bad architecture."

-- Brian Foote and Joseph Yoder

Abraham Lincoln reportedly said that, given eight hours to chop down a tree, he'd spend six sharpening his axe.

-- TidBITS 654, quoted by Derek K. Miller, via Art Evans

... while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy.

-- E. W. Dijkstra, Communications of the ACM, Mar 2001, Vol. 44, No. 3

You can only find truth with logic if you have already found truth without it.

-- Gilbert Keith Chesterton (1874-1936) " The Man who was Orthodox", via Paul Black

16 Jan 2007更多精彩文章及讨论,请光临枫下论坛 rolia.net
Report

Replies, comments and Discussions:

  • 工作学习 / 专业知识杂谈 / 好文共享 - What make A Programmer From Good To Great ?
    本文发表在 rolia.net 枫下论坛What Makes a Good Programmer?

    I just read two salon articles about Scott Rosenberg's new book Dreaming in Code. His thesis is that "programing is hard" and uses the experiences of the development of the Chandler project to frame the discussion. Scott identifies a common problem in large software development - inconsistent terminology use across the software development team. At the same time he complements the members of the development team as being talented programmers. These two ideas struck me as incongruous. How can a bunch of "ace programmers" end up with such a basic problem? Should programmers encountering this problem really be deserving of the accolade "ace"? And what skills would I expect from an "ace" programmer anyhow?

    Before I go any further, I want to make it clear that I don't want to talk down Scottt or the Chandler team. Scott makes a number of great points that reflect my own experiences. Virtually every large software project I've seen has had problems akin to those Scott describes. Especially every large project I've worked on. I'm certainly as guilty of these difficulties as any programmer. But the examples that Scott describes are good grist for discussion about software development.

    When people talk about talented programmers they are usually refering to their ability to write correct code, whch solves problems quickly and elegantly. I suspect that that is what Scott was implying by describing the Chandler team as ace programmers. Raw coding skills vary widely across individuals. When it comes down to it some programmers are just more talented than others at writing code. Large team projects - projects with more than 3 programers with schedules of more than a few months - require a whole set of skills beyond raw coding. On large teams, excellent coding skills are a prerequisite. Alone, they qualify you as a beginner, not an ace.

    From Beginner to Good

    For me, the mark of a good team programmer is someone who does not suggest rewriting everything from scratch. Scott makes the very valid point that programmers like to program - and that they don't like to understand code written by others. Truer words were never spoken. Time and time again I've seen smart novice programmers suggest rewriting code produced by other programmers. I've noticed an inverse relationship betwen the esteem I hold for a programmer and the number of times I've heard them suggest a rewrite of a large software project.

    Good team programers are capable and willing to work with a codebase that is too large for a single person to rewrite within the project's schedule. They recognize that the existing codebase has shortcomings and they have the maturity and discipline to know that attempting to 'fix' everyone of those shortcomings will almost certainly kill the project. Instead they identify those areas which must be improved on to deliver the project, and they have the skills to make significant changes to a large and ugly (because every large piece of software is ugly - but that's another story) codebase without causing the whole thing to destabilize.

    And From Good To Great

    If the mark of a good team programmer is the ability to work (usually grudgingly) with the code of others, then the mark of a great team programer is the ability to produce code that other programmers on the team will gladly use. Programmers are the most fickle sort, and if you can produce code that other, less skilled, coders will use without suggesting a rewrite - then you've elevated yourself to the top of the programing heap. Great programmers produce code that is so good that it will prevent the cross programer problems that plague most large software projects.

    Published Sunday, February 04, 2007 4:24 PM by peterhal更多精彩文章及讨论,请光临枫下论坛 rolia.net
    • If you want a great programmer work within an established software framework, he will feel suffer.
      • 大事干不了,小事不愿干
    • 好文共享-Software Engineering Proverbs(软件工程师箴言)
      本文发表在 rolia.net 枫下论坛Software Engineering Proverbs
      (collected by Tom Van Vleck)

      A clever person solves a problem.
      A wise person avoids it.

      -- Einstein

      André Bensoussan once explained to me the difference between a programmer and a designer:

      "If you make a general statement, a programmer says, 'Yes, but...'
      while a designer says, 'Yes, and...'"

      No matter what the problem is,
      it's always a people problem.

      Jerry Weinberg

      Wexelblat's Scheduling Algorithm:

      Choose two:

      * Good
      * Fast
      * Cheap

      Craziness is doing the same thing and expecting a different result.

      Tom DeMarco, rephrasing Einstein, who said

      Insanity: doing the same thing over and over again and expecting different results.

      "There's no time to stop for gas, we're already late"

      -- Karin Donker
      Deming's 14 points

      1. Create constancy of purpose.
      2. Adopt the new philosophy.
      3. Cease dependence on mass inspection to achieve quality.
      4. Minimize total cost, not initial price of supplies.
      5. Improve constantly the system of production and service.
      6. Institute training on the job.
      7. Institute leadership.
      8. Drive out fear.
      9. Break down barriers between departments.
      10. Eliminate slogans, exhortations, and numerical targets.
      11. Eliminate work standards (quotas) and management by objective.
      12. Remove barriers that rob workers, engineers, and managers of their right to pride of workmanship.
      13. Institute a vigorous program of education and self-improvement.
      14. Put everyone in the company to work to accomplish the transformation.

      We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer -- and keep pouring our sewage into our water supply.

      -- Tom Van Vleck
      The Troops Know

      * The schedule doesn't have enough time for maintenance in it.
      * A lot of bugs get past the tests.
      * Most old code can't be maintained.

      To go faster, slow down. Everybody who knows about orbital mechanics understands that.

      -- Scott Cherf
      Everybody Knows:

      * Discipline is the best tool.
      * Design first, then code.
      * Don't patch bugs out, rewrite them out.
      * Don't test bugs out, design them out.

      Everybody Knows:

      * If you don't understand it, you can't program it.
      * If you didn't measure it, you didn't do it.

      Everybody Knows:

      If something is worth doing once, it's worth building a tool to do it.

      Your problem is another's solution;
      Your solution will be his problem.
      Everybody Knows:

      * If you've found 3 bugs in a program, best estimate is that there are 3 more.
      * 60% of product cost comes after initial shipment.

      The significant problems we face cannot be solved by the same level of thinking that created them.

      -- Albert Einstein

      On the radio the other night, Jimmy Connors said the best advice he ever got was from Bobby Riggs:

      * do it
      * do it right
      * do it right now

      It is not enough to do your best: you must know what to do, and THEN do your best.

      -- W. Edwards Deming

      A leader is best when people barely know that he exists.
      Less good when they obey and acclaim him.
      Worse when they fear and despise him.
      Fail to honor people, and they fail to honor you.
      But of a good leader, when his work is done, his aim fulfilled,
      they will say, "We did this ourselves."

      -- Lao-Tzu

      You must be the change
      You wish to see in the world

      -- Gandhi

      Experiment escorts us last,
      His pungent company
      Will not allow an axiom
      An opportunity.

      -- Emily Dickinson

      when the cart stops
      do you whip the cart
      or whip the ox?

      Q: How many QA testers does it take to change a lightbulb?
      A: QA testers don't change anything. They just report that it's dark.

      Kerry Zallar

      Q: How many software engineers does it take to change a lightbulb?
      A: Just one. But the house falls down.

      Andrew Siwko

      One test is worth a thousand opinions.

      "If you didn't write it down, it didn't happen."

      This saying is popular among scientists (doing experiments), but I believe it applies to software testing, particularly for real-time systems.

      --Larry Zana

      We reject kings, presidents, and voting.
      We believe in rough consensus and running code.

      --Dave Clark (1992)

      I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don't, and the spirit of the passionate intellect that has tied them together, or tried. That's why programming---or buying software---on the basis of "lists of features" is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess.

      -- Ted Nelson

      Software is Too Important to be Left to Programmers, by Meilir Page-Jones.

      "If you think good architecture is expensive, try bad architecture."

      -- Brian Foote and Joseph Yoder

      Abraham Lincoln reportedly said that, given eight hours to chop down a tree, he'd spend six sharpening his axe.

      -- TidBITS 654, quoted by Derek K. Miller, via Art Evans

      ... while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy.

      -- E. W. Dijkstra, Communications of the ACM, Mar 2001, Vol. 44, No. 3

      You can only find truth with logic if you have already found truth without it.

      -- Gilbert Keith Chesterton (1874-1936) " The Man who was Orthodox", via Paul Black

      16 Jan 2007更多精彩文章及讨论,请光临枫下论坛 rolia.net
      • 早年在国内大学混迹于个大高校的BBS上,就认识一个叫"一天到晚游泳的鱼",印象特深是在于梁咏琪的同名歌曲.请问兄台,98年左右,可用该网名否?
        • 是张雨生的吧?
        • 兄台估计是认错人了:)
        • 遥想96年刚玩MUD和 BBS的时候, 一声叹息