PragPro的哲学(之三)

足够好的软件

     正如Ed Yourdon在《IEEE软件》上的一篇文章描述的那样,你能够训练自己写出足够好的软件,对你的用户足够好,对未来的维护者足够好,让你自己足够安心。
     在我们更加深入之前,我们需要证明我们想说的是正确的。“足够好”没有包含马虎或者差劲的代码的意思。所有的系统必须满足它们用户的需求才能算得上成功。我们仅仅倡议给用户们一个机会参与到决定什么时候你做的东西是足够好的了的过程中来。

使你的用户参与到讨论中

     你开发的系统的范围和质量应该作为系统需求的一部分被指明。

建议7

使质量成为需求的一个议题

     你通常会在涉及到权衡的情况下。出人意料地,很多的用户相对于为多功能的版本等待一年更倾向于在今天使用有一些未完善处的软件。很多资金紧张的IT部门会赞同。现在好的软件常常是在接下来完善更可取。如果你给予你的用户更早使用一些东西,他们的反馈将会带给你更好且可能的解决方案。

不要画蛇添足

     在某种程度上,编程就像是画画。你从一个空白的画布和某些基本的未加工过的材料开始。你将科学、艺术和工艺相结合来决定你要对程序做什么。你草拟了整体形状,画出底层的环境,接着勾勒出细节。你时常带着批评的眼光回去看你都做了什么。所有的现在和以后你都将抛弃画布重新开始。
     但是艺术家会告诉你所有的努力工作都会因为你不知道什么时候停止而毁灭,就像画蛇添足。如果你添加一层又一层,细节加细节,油画会将在绘画中“迷失”。
     过度修饰或者过度精炼会毁掉一个足够好的软件。继续,让你的代码在正确的位置上一段时间。它或许不够好。不要担心,这永远不可能是完美的。

The Pragmatic Philosophy(V)

6. Communicate!

Know What You Want to Say

Plan what you want to say. Write an outline. Then ask yourself, “Does this get across whatever I’m trying to say?” Refine it until it does.

Know Your Audience

You’re communicating only if you’re conveying information. To do that, you need to understand the needs, interests, and capabilities of your audience.

Form a string mental picture of your audience. The acrostic WISDOM, show below, may help.

What do you want them to learn?

What is their interest in what you’ve got to say?

How sophisticated are they?

How much detail do they want?

Whom do you want to own the information?

How can you motivate them to listen to you?

Choose Your Moment

As part of understanding what your audience needs to hear, you need to work out what their priorities are. Make what you’re saying relevant in time, as well as in content. Sometimes all it takes is the simple question “Is this a good time to talk about…?”

Choose a Style

Adjust the style of your delivery to suit your audience. Some people want a formal “just the facts” briefing. Others like a long, wide-ranging chat before getting down to business. When it comes to written documents, some like to receive large bound reports, while others expect a simple memo or e-mail. If in doubt, ask. Remember, that kind of feedback is a form of communication, too.

Make it Look Good

Your ideas are important. They deserve a good-looking vehicle to convey them to your audience.

Involve Your Audience

We often find that the documents we produced end up being less important than the process we go through to produce them. If possible, involve your readers with early drafts of your document. Get their feedback, and pick their brains. You’ll build a good working relationship, and you’ll probably produce a better document in the process.

Be a Listener

There’s one technique that you must use if you want people to listen to you: listen to them.-if you don’t listen to them, they won’t listen to you.

Encourage people to talk by asking questions, or have them summarize what you tell them. Turn the meeting into a dialog, and you’ll make your point more effectively. Who knows, you might even learn something.

Get Back to People

If you ask someone a question, you feel they’re impolite if they don’t respond. But how often do you fail to get back to people when they send you an e-mail or a memo asking for information or requesting some action? Always respond to e-mails and voice mails, even if the response is simply “I’ll get back to you later.” Keeping people informed makes them far more forgiving of the occasional slip, and makes them feel that you haven’t forgotten them.

Tip 10

It’s Both What You Say and the Way You say It

E-Mail Communication Tips

  • Proofread before you hit SEND
  • Check the spelling
  • Keep the format simple.
  • Use rich-text or HTML formatted mail only if you know that all your recipients can read it. Plain text is universal.
  • Try to keep quoting to a minimum. No one likes to receive bakc their own 100-line e-mail with “I agree” tacked on.
  • If you’re quoting other people’s e-mail, be sure to attribute it, and quote it inline(rather than as an attachment).
  • Don’t flame unless you want it to come back and haunt you later.
  • Check your list of recipients before sending.

PragPro的哲学(之二)

2.软件的熵

熵是一个物理学术语,指的是一个系统中“混乱”的数量。不幸的是,热力学的定律保证在宇宙中熵趋向于无穷大。在软件中混乱增多的时候,程序员们管它叫做“软件腐烂”。

在内地的城市,一些建筑都很漂亮和干净,然而其他的都很挫。为什么呢?犯罪和城市领域的研究人员发现非常神奇的让一个干净、完整、有人居住的建筑变成乱七八糟遭人唾弃的鬼地方的触发机制。

一个破碎的窗户

一个破碎的窗户放着很久没有去修理,慢慢地,这栋楼的居民心中会产生抛弃感,这种感觉使得他们根本会在乎这栋楼。所以其他的窗户打坏了,人们开始把它丢在一边不管。渐渐地涂鸦出现了,建筑结构上严重的破坏也产生了。在相当短的时间里,这栋楼变得非常破旧搞得居民都不像去修理它,并且人们抛弃它成为了现实。

“破窗原理”给纽约和其他主要城市的警察局带来了灵感,他们用小事情来阻止大事情。这发挥了作用:保持破窗、涂鸦和不足挂齿的违规行为减少了严重的犯罪水平。

建议4

不要和破窗一起生活

不要遗留没有被修理的“破窗”(差劲的设计、错误的决定或者垃圾的代码)。以上任何一个问题被发现的时候就得去修复它。如果没有足够的时间去适当的处理它,那就把这个错误封闭起来。也许你可以把不好的代码注释起来,或者显示一个“未完成”这样的信息,或者用虚拟的数据代替。要采取行动来阻止更进一步的破坏以及表现出你是在最高状态。

你可能会想没有人有时间去把一个项目里所有的玻璃碎片都弄干净。如果你继续这样想的话,你最好还是去弄个大的垃圾桶过来,或者搬到另一个街坊。不要让熵赢了。

A Pragmatic Philosophy(IV)

Your Knowledge Portfolio

An investment in knowledge always pays the best interest ——Benjamin Franklin

Your knowledge and experience are your most important professional assets.

Unfortunately, they’re expiring assets. Your knowledge becomes out of date as new techniques, languages, and environments are developed. Changing market forces may render your experience obsolete or irrelevant. Given the speed at which Web-years fly by, this can happen pretty quickly.

We like to think of all the facts programmers know about computing, the application domains they word in, and all their experience as their Knowledge Portfolios.

Building Your Portfolio

  • Invest regularly. You must invest in your knowledge portfolio regularly. Even if it’s just a small amount, the habit itself is as important as the sums.
  • Diversify. The more different things you know, the more valuable you are. …. The more technologies you are comfortable with, the better you will be able to adjust to change.
  • Manage risk.  Don’t put all your technical eggs in one basket.
  • Buy low, sell high.
  • Review and reblance. This is a very dynamic industry. That hot technology you started investigating last month might be stone cold by now.

Tip 8

Invest Regularly in Your Knowledge Portfolio

Goals

Here are a few suggestions.

  • Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut.
  • Read a technical book each quarter. Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project.
  • Read nontechnical books, too. 
  • Take classes. 
  • Participate in local user groups. Don’t just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.
  • Experiment with different environment.
  • Stay current. Subscribe to trade magazines and other journals. Choose some that cover technology different from that your current project.
  • Get wired.

It done’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.

Opportunities for Learning

….and somebody asks you a question. You don’t have the faintest idea what the answer is, and freely admit as much.

Don’t let it stop there. Take it as a personal challenge to find the answer. Ask a  guru. Search the Web. Go to the library.

If you can’t find the answer yourself, find out who can. Don’t let it rest.

Critical Thinking

The last important point is to think critically about what you read and hear. You need to ensure that the knowledge in your portfolio is accurate and unswayed by either vendor or media hype.

Tip 9

Critically Analyze What You Read and Hear

Care and Cultivation of Gurus

  • Know exactly what you want to ask, and be as specific as you can be.
  • Fram your question carefully and politely.
  • Once you’ve framed your question, stop and look again for the answer. Pick out some keywords and search the Web. Look for appropriate FAQs.
  • Decide if you want to ask publicly or privately.
  • Sit back and be patient.

Finally, please be sure to thank anyone who responds to you. And if you see people asking questions you can answer, play your part and participate.

A Pragmatic Philosophy(III)

Good-Enough Software

        As Ed Yourdon described in an article in IEEE Software, you can discipline yourself to write software that’s good enough-good enough for your users, for future maintainers, for your own peace of mind.

        Before we go any further, we need to qualify what we’re about to say. The phrase “good enough” does not imply sloppy or poorly produced code. All systems must meet their user’s requirements to be successful. We’re simply advocating that users be given an opportunity to participate in the process of deciding when what you’ve produced is good enough.

Involve Your Users in the Trade-Off
The scope and quality of the system you produce should be specified as part of that system’s requirements.

Tip 7
Make Quality a Requirements Issue

        Often you’ll be in situations where trade-offs are involved. Surprisingly, many users would rather use software with some rough edges today than wait a year for the multimedia version. Many IT departments withe tight budgets would agree. Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.

Know When to Stop
        In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them. You sketch out an overall shape, paint the underlying environment, then fill in the details. You constantly step back with a critical eye to view what you’ve done. Every now and then you’ll throw a canvas away and start again.

        But artists will tell you that all the hard work is ruined if you don’t know when to stop. If you add layer upon layer, detail over detail, the painting becomes lost in the paint.

Don’t spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don’t worry: it could never be perfect.