About defensive programming, well again, it depends

There are always things you can’t say they are absolute. Most time, for most subject, how to deal with a concrete situation, it depends on the context. Is there any principle for any context? Oh yeah, there is one, that is, “it depends”. Well, there is actually another one, “don’t be rigid”.

http://www.thekua.com/atwork/2008/08/defensive-programming-depends-on-context/

About defensive programming, well again, it depends

The “Software Architecture Document” Size

* This post strengthen my thought on software project document that is write necessary documents only and make sure the documents work.
 
The "Software Architecture Document" Size

Print
Written by Arnon Rotem-Gal-Oz   

04/22/08

Simon @ CodingTheArchitcture recently asked "How big is your software architecture document? (and who reads this stuff anyway?)"    He notes that in a user’s group meeting most of the attendees had Software Architect Documents (SADs) that were more than 50 pages long.

It would probably not be too surprising if I said that, in my opinion, the answer is " it depends." Reflecting on some of my past projects, I had SADs that varied in length from a 200+ "write-only"  document*  to a less than 10 page lean document. And the sizes matched the intended usage of the documents. For instance, in the two extremes just mentioned, the first case was a huge mission-critical project with a specific requirement from the customer to have an "official" SAD  and  it was written to satisfy some project milestone (PDR) . The second extreme, on the other hand, was an agile project where the architecture document was a working document, written some 10 iterations into the development to highlight some of the emergent guidelines.

What is common to all the SADs I’ve written (or have been responsible for) is that they all tried to grasp the essence of the design, all used multiple viewpoints to describe the solution, all were focused on quality attributes,  and all explained the rationale behind the decisions.

  • If you drone endlessly with details, you don’t see the forest from the trees.
  • If you don’t use multiple views, you are likely to miss important aspects of the solution
  • If you aren’t focused on quality attributes, then you are most likely documenting design and not architecture
  • And if you don’t explain the rationale,  then the document doesn’t have a lot of added value beyond the code itself

In any event, the important thing here is that when it comes to Software Architecture Documents  "size doesn’t matter" :). What matters is that the SAD satisfies  the reason it was written for.


*While this particular SAD was rather long,  it also had a section that helped potential readers find relevant chapters so that it can actually be usable, and not just for "door stopping".

The “Software Architecture Document” Size

混乱让你更高效

一定的混乱却能让你更高效。我们不妨从混乱的角度来重新审视被世人推崇的时间管理黄金法则。 

你是否常常每天花费一个小时来规划全天日程?每天为努力保持办公环境的整洁而备感压力…… 

从小到大,我们都在与混乱和无序作斗争,大多数人都在尽力追求整洁有序,为混乱的状态感到烦恼和痛苦。似乎只有紧张的日程表、严密的组织、整洁的环境才是成功人士的标签。 

“混乱和无序可能是无害,甚至是有益的。一定的混乱却能让你更高效。” 在埃里克•亚伯拉罕森及戴维•弗里德曼合作的新著《完美的混乱》中,两位作者抛出了这样一个另类观点。的确,做到整洁和有序需要付出很高的代价。我们不妨从混乱的角度来重新审视被世人推崇的时间管理黄金法则。

1.聚焦 ——被坏习惯束缚 

锁定目标并养成坚持不懈的习惯,有计划地实现目标。时间管理方法常提醒我们,要避免因那些令人分心或用处较小的事而耽误进度。但是, 

◆如果在锁定一个目标并为之奋斗数年之后,发现自己所挑选的是一个错误的方向,那该怎么办? 

◆你认为做有些事是浪费时间,但你如果没有做,没有去验证,你又怎么知道做那些事真的是浪费时间呢? 

◆为什么那么多传奇的成功人士有着充满矛盾的经历、失败的开始以及绕了许多弯路的职业生涯? 

毕业于牛津大学的实验心理学家本•弗莱彻通过调查发现,组织中压力的最普遍成因是管理者们近乎虐待的掌控,他们通常过于自大、严厉而且狭隘。弗莱彻发现:人们总是简单地习惯于每天按同样的方式做事,而这就意味着很可能被不好的习惯束缚住。换句话说,确认并坚持成为了解决问题的障碍。于是弗莱彻要求经理们先从日常生活中容易改变的习惯入手,如上班路线、午餐的食物、会议上的座次等任何可以带动行为方式改变的事。结果是惊人的:训练仅仅进行了几个星期,一些改掉了生活中坏习惯的经理们就发现自己对待下属的方式其实也是可以改变的。弗莱彻说,其原因在于人们很容易陷入所谓的“习惯网络 ”中。当人们要做出重要且必需的改变时,会觉得很困难。但如果切断网络中的个别薄弱环节,整个网络也会松动,从而允许重要的改变发生。弗莱彻说,“正是新的行为方式带来了新的体验,并将最终帮助人们改变思维方式”。同时他进一步证明,容易改变的习惯和未加计划的改变不仅仅会使人成为更好的管理者,更能帮助他们缓和与配偶及孩子间的矛盾,修复与家人间的关系。

2.做更多的事 ——每件事都没做好 

人们总是想尽办法在一天内完成更多的工作,于是“做更多的事”这一观念不需要证明就成为一件必然为大家认同的好事。 

而一些效率非常低的人也认可了这种观念,在不同任务间反复,最终每件事都没做好,每个人都觉得自己被忽视了。另一方面,一部分人习惯于在每天结束时总结自己当天的工作,常常抱怨为什么自己只处理了那么少的事情。由此得出的结论是:尽管重要的工作已经完成,重要的人也给予了足够的重视,但那只是因为他们应该得到这样的待遇,与想要“做更多的事”这一习惯完全无关。

3.遵照任务表 ——“万能”的未必适合你 

所有的职业组织规划师都将“遵照任务表”作为他们信仰的基本原则,“个人生产力”权威戴维•艾伦(David Allen)的追随者们则尤其狂热。艾伦和他的众多支持者们把任务和职责用纸或电脑记录下来,认为这样可以立即缓解忧虑,并做到使问题更集中。尽管笔者很难理解为什么那些创建任务表,但从不考虑如何开始的人如此兴奋,但也的确很难证明“列任务表”是个坏习惯,因为这种习惯早已随着人们对任务表的忠诚而根深蒂固。 

撇开写清单时可能的遗漏不说,如果仅因担心任务表上的内容,甚至只是担心位于任务表最上面的条目能否完成,尚未完成的任务就会停止、完成次序下滑直至消失。但你又如何保证恰当的事情总是能位于其上,并且处于恰当的位置呢? 

这或许只取决于你更青睐哪个生产力专家的观点。艾伦建议,按照便利性来排列条目,即把能够一次性完成的任务放在一起。而另一方面,斯蒂芬•柯维(Stephen Covey)所著的《高效能人士的七个习惯》(Highly Effective Habits)一书中则强调,最重要的条目应该列在任务表的最上面。因此,你不得不选择是按照柯维的方式,先完成对工作至关重要的报告而暂时不换前车灯,还是按照艾伦的方式,在买灯泡的同时买胶带,而不去看更新汽车注册信息。 

无可否认,艾伦和柯维的书都非常受欢迎,但人们学习他们技巧的目的并不是要获得一种完成更多事的满足感,只是想知道按照这些技巧做事是否会使自己表现得更优秀。而这似乎也是所有成功的个人生产力专家和职业组织规划师们都声称自己拥有的技能。有趣的是,艾伦和科维的新书中都提到了这样的观点:所有任务表、文档和习惯都可以帮助你实现生命的意义,并在自己所处的工作领域占据一席之地。也许你真的需要严格遵循这类“万能”的时间管理方法,因为其中也可能真有适合你的。但是,谁也不能否认这些所谓的“效率专家”也是偶然发现自己在该工作领域的位置的,他们本身所代表的随机与混乱又如何用 “任务表理论”来进行解释呢?

4.遵守时间表 ——松散安排反倒更好 

严谨的时间表也许是个“伟大”的构想,但前提是你能精确预见到所有事都将按其中的顺序发生。同时,你要能够准确推测出自己和相关人士每时每刻的想法和感受。如果你做不到,松散的安排反倒会更好。安排紧密的时间表是不可靠的,因为如果其中一项发生了变动,其他所有的项目都可能因连锁反应而发生混乱。假设要规划这一天或一周内你要做的事,你就需要花时间仔细考虑如何建立起一个时间表,希望参照它使自己不会偏离轨道。 

而事实上,有些人在制表上所花的时间比照它完成任务所花的时间还要多。举一个简单的例子:在旅行时,你花了1.5小时来选择看起来最方便的航班,而这一选择花费的时间比你第一眼所看到的那个航班节省1个小时,也就是说你反倒浪费了半个小时。另外,当你试图在一天的时间表里加入尽可能多的日程时,事情的发展很可能会失控。这对牙医和发型设计师来说影响也许不大。但大多数人可能会因此徘徊不前,甚至不得不重新改变最初的计划,像是那些希望参观到最多迪斯尼乐园景点的游客,他们可能要花费数个小时在游览路线的规划上。

5.长期计划 ——总是自欺欺人 

在商界,时间跨度超过几个月的商业预测往往就像抛硬币的结果一样不可预期。而这一观点对于个人同样适用。美国的离婚率一直徘徊在 50%左右,而被奉为“求职者圣经”的《你的降落伞是什么颜色?》一书也已经雄踞畅销书榜近40年了。变化之所以这么频繁,是因为当人们觉得自己有足够能力做出选择时,总是自欺欺人地认为自己所做的决定至少在今后五年内是正确的。

6.立即完成 ——拖延并不总是坏事 

首先,它避免你花时间做一些会最终被证明是不重要的事。或者像卡尔文•柯立芝(Calvin Coolidge)所说,“如果你认为一路上将会遇到十起事故,那么请相信,到了第九个你就已经掉到沟里去了”。美国海军陆战队也有类似的说法:“过早计划意味着要计划两次。”这些都试图说明,做计划要尽可能晚,因为即使提前完成了计划,也很可能因为情况突变而需要重做。事实上,推迟所有形式的整理、整顿计划都是有好处的,因为一次性处理大量事情比一发生就逐个处理的效率要高得多。例如,若要分类电子邮件,一次整理数百封比一次整理几十封高效得多。 

(本文摘编自《完美的混乱》,该书已由中信出版社出版)

混乱让你更高效

两个我

关心你的朋友总喜欢问,最近工作忙不忙?出于对朋友的尊重,抑或凡事认真的习惯,我总是会仔细考虑一下最近的状况,然后再做回答。大部分时候,我的回答总归是,一般忙。或时忙时不忙。有很多时候,也许加班到凌晨了,我回答一般忙。有时候实在空闲无事可做,我也回答一般忙。而且都是在认真考虑过之后。

这样的回答或者说考虑结果很奇怪。难道我没有忙于不忙的判断标准吗?仔细想来,发现倒不是没有判断标准。而是,其实很少在意忙于不忙的状态。最关注的是当下的心情、压力程度,目标清晰度或者动力感这种东西。至于每天的任务列表,排满排不满倒不是我所介意的。所以,总归是一般忙。其实,如果问我,最近心情如何,生活有无动力,我倒是会有不同的回答吧。

这么多年下来,我明白了一件事。有一种几乎所有人都追求的东西,对于我来说是白费劲。那就是所谓的战胜自我。多么熟悉、光辉的词汇。无数人奋斗的目标。一旦战胜自我,万事可成。然而,我永远无法战胜自我。我需要的是去做无形的本我所最想做的事。当偏离无形的本我所最希望走的路时,失败或不成功总是时时伴随,即便现实的我再怎么抗争,也绝无可能战胜无形的本我。郁闷,无法排解的透不过气,前路迷雾充斥,毫无斗志。反之,一旦执行本我所希望的任务时,几乎总是所向披靡,哪怕一天只睡两个钟头也感觉毫无倦意。

无形的本我。是我始终无法抓住他问个究竟呢?还是,他日日与我恳谈,但现实的本我始终不相信他,不愿承认他?现实的我有他的一套想法,他要走他希望的路。有朋友在看着他,有外界的一切在左右着他。两个我,在战斗。现实的我,失败,失败,再失败。何时握手言和?现实的我开的条件是,如果无形的本我可以实现现实的本我所要的目标,那么就随他的便。无形的本我告诉说,这个目标很有可能实现,但我不能给你任何承诺。信与不信我,自己看着办。

世界上存在真正的信任吗?大家都觉得别人在骗自己。你到底相信还是不相信!?

现实的我很忙碌,但他不想承认。现实的我很郁闷,他也不想承认。因为没有人愿意说他无法战胜自己,或者说战胜自己是世界上每一个人永远的不变信条。可是。。。

一定要战胜“本”我吗?

两个我

NHibernate 2.0

Guys, gals and its. I am overjoyed to tell you that NHibernate 2.0 has been released.

You can get it directly from the download page.

I would like to thank to the NHibernate project lead, Fabio Maulo, for doing such an awesome amount of work, and getting this out.

Thanks, Fabio.

I am not going to list all the features, suffice to say that we are now in a comparable position to Hibernate 3.2.

Have fun!

NHibernate 2.0

昨晚你睡得怎么样?

我睡得不错。我从两点开始睡到今天中午十二点多。我自然醒的。这很好。前天我睡了很少,所以,昨天我很疲倦。尤其是,我加班到凌晨的时候。

我没有做梦。也许是因为越来越老的原因吧。

在全世界都在庆祝有同一个梦想的时候,我突然发现,我没有了任何梦想。世界正在变复杂,在我特别想要简单的时候。

我一直想要简单生活。一种由简单梦想驱动的,不需要复杂操作就可以驾驭的简单生活。

然而,生活总是没有想像的简单。千头万绪,你越是要理,它就越缠绕。你想不要去理,它依然要缠绕。

随便吧。

昨晚你睡得怎么样?