小窝装修历程@京都苑 第一集（预计9月28日完工）

年前购买的小窝（不到48平米，实际面积就更可怜了，555）6月底的时候终于到手，怎么装修的事情忙得可谓是焦头烂额，和女朋友也没少为这些事情争吵，还好有朋友介绍的许师傅，接触过后感觉人还是蛮实在的，应该是很负责的那种，虽然离完工还早，不过选择他应该没选错，呵呵~之前经验少，师傅问过我们要不要设计，所以还叫了个南鸿的设计师来看，但按许师傅的话，设计师对现场的情况了解会比较少比较浅，比如某些设计到底好不好用，他们现场施工的人更加清楚。比如说有桑拿室的木板底浴室，他就说那东西不实用，容易坏，而设计师当时是说肯定没问题的。。我们也难辨是非啦，从个人经验来看，我还是信任实际干活的人的说法多一些。

• 7月10日 装修前

房型还可以，整个是长方形，就是顶上的几根粱比较麻烦，厨房和卫生间都比较小。进门是在长方形一条长边的角上，进门直接面对厨房，右手边转过去就是过道，过道的左手边也就是紧靠着厨房的就是卫生间。卫生间由于马桶下水的位置不是很好，设计卫生间很费工夫，面对马桶右手边的那个小格子里是老的水管，估计已经荒废，打算搞掉它的大接头，塞到墙里面去。

客厅也比较小，和次卧之间是一个装饰性的柜子。次卧是原房主自己用板隔出来的，也就能放下一张床，他们还塞了一个柜子，很是佩服。我们决定要把这个板拆掉，房间弄得大气些。仅靠主卧的门边是一个大衣柜，做到顶的。由于阳台是包进的，和卧室整体铺的地板，显得还算宽大，阳台上的窗户相当的大，不错。

窗外还是很爽的，是社区的一个停车场，顶上都是花草，像公园一样，不会有开窗全是高楼大厦的压抑感，而且还是一片绿色，蛮喜欢的。

• 7月11日 地漏+漏保空开

到佳好佳装饰城按许师傅的要求先买来地漏、漏保和空开，逛了大半天，最后在一家什么中策电线什么店里买了梅兰的漏保空开，地漏选的是九牧的。什么牌子好，该多少钱俺们是一点头绪都没，看看东西还不错，价格差不多就出手了。老板说梅兰的价格很透明，他也没有乱报价，比我在淘宝上查到的价格还要低。九牧的地漏可能买得稍微好了点，许师傅让我买杭特的，但在老板那里看到杭特的实在很差，一点分量也没，九牧可沉多了。

 

• 7月12日 拆旧第一天

周末不能动工，师傅们周一开始干活，拆旧前想着那衣柜啥的看着还不错，还估摸着拆下来卖点钱，等人家拆下来的时候一看，都在楼下堆着，一堆薄薄的劣质板，确实不可能。晚上给他把地漏空开的送过去，去了趟房子。

已经拆得一塌糊涂的厨房和过道，立在过道边上的板子可能是客厅的木地板，忘记了。。。

卫生间马桶的下水在挺正中的位置，导致我们的设想中马桶+淋浴间+洗脸台+推拉门的设想很难实现，只能到时候使用移位器。卫生间顶上同样也是和很多网友一样的问题，突出的污水管道，看包工头怎么给我处理了，不过基本设想也是不想再整体包起来吊顶，那样太低，很压抑。

客厅的地面是混凝土上面铺的瓷砖，打算清理下去重新铺瓷砖。客厅和次卧中间的柜子被拆掉，从露出来的断面来看，原房主也有处理过这面墙，有一部分都是空心砖来着。

主卧里拆旧一天后有新状况，地板上门框的位置有一个洞；原本放大衣柜的地方拆掉后，发现地板离地板加起来挺厚的，包工头很想给我们省下一些高度（我们的房间似乎只有2.5米高），大家可以看到扑克牌立在地板前的高度对比。另外，本来我们都以为卧室的地板原房主铺得还不错的，准备保留下来留给自己用。后来因为阳台设计的原因最终取消了保留地板的计划，拆起来才发现根本不是地板，许师傅好像说是原房主自己搞的什么木板弄起来的，地板不是应该一块块拼起来的么，它这里是一揭就整个地板起来的。

顺便提一下，由于完全不懂装修这个事情，之前和女朋友讨论的时候争执很多。渐渐地领悟到，装修这个事情要想一开始就确定下来确实不容易，比如我们开始装修的时候有个想法，网上看图片、看帖子，不断地想法在变。而后师傅实地看过帮我们考虑了一下，交流后又有新想法。拆旧开始后，看到房间里房屋框架的一些限制、特点后想法还会变化。装修这个事情看来只有先做好准备，然后就走一步看一步，放手不得。这也让我有一点疑惑，那么一开始就请装修公司、找设计师设计、项目经理跟进的话，到底和包清工有多少的区别，毕竟我觉得我们自己还是得投入很多精力才行。不管工人是否能放心，设计上的一些细节考虑都是自己最清楚也最在意。

• 7月14日 拆旧完毕

拆旧完的景象，更空旷，颇有点凄凉的感觉，汗。。到处都是砖和墙体，还有堆积的水泥、黄沙，站在房屋里的是LD大人正在视察。。。

• 7月15日 水电定位

水电就要进场了，晚上赶紧碰头交流了

一下彼此的想法，确定下来水电的大致

位置。人物从左到右依次是电工师傅、

LD大人和这次装修的包工头许师傅。

 

 

• 7月17/18日 新时代采购

赶上周末里新时代在三堡的钱江新城店新开张搞活动，赶过去凑热闹、占便宜。连续奋斗两天，收获还是蛮丰盛的。不过俺最后的一个感受就是，之前总想着事先要做好准备，结果还是无备前往，倒也没有什么特别不方便的地方，只是不晓得买的牌子和价钱是否合算。名气很大的牌子都很贵，搞活动也还是很贵，要不就是优惠的东西款式啥的不好看，最终还是到那些东西看起来还不错（外表），内在说实话不清楚，牌子名气貌似还不错的店家里购物。（题外话：这次经历给我挺大的触动，回想自己所处的通信行业或者说软件行业，是否真的就是产品好最重要？也许吧。我目前的想法是，对于那些需求不紧急的商品，人们有足够的时间进行比较而后才会有购买行动，那么市场的口碑就很重要，产品本身的功能当然也很重要。但对于那些一旦产生需求，就会是很紧迫而且很重要的商品，比如装修，平日里还没装修时真的是没多少动力区了解，而且一辈子也不会装修太多次，淘神费力，这样一来，都是要装修的时候临时抱佛脚。还非常地受到商家当时促销活动的影响，比如喜欢的品牌没有活动，而另一些看起来还可以的知名不知名品牌大搞打折促销，你会如何选择？所以呀，做生意，是远比做产品要宽广的一个话题。）

由于客厅和厨房包括卫生间最后都确定下来要铺瓷砖，包工头说下一周就要用到，所以首要的任务就是瓷砖。然后就是防盗门，他们要做门套。最后到新中源陶瓷，看到他们的促销活动还不错，有两款特价的瓷砖也还蛮能合我们的心意，一款新的800*800的砖可以用来铺客厅，就在这里下订单了，由于都是特价，就没有办法再参加商场的返现或者商家的累积满5000送电器之类的活动。一位胖乎乎的女士，估摸着是门店经理吧，挺会做生意的，笑嘻嘻的，虽然我们是特价，也还是答应送给我们两个什么便携式小台灯还是啥的，估计值不了多少钱，但心情是不一样的。防盗门买了顾家（好像叫顾家门业，一开始误以为是朋友待过的顾家工艺呢）的，老板娘也很会做生意的，我们还准备买她的一个室内门（我们只有一个室内门），老板娘说“我们做你这个门肯定是亏的，但是你既然防盗门这里买了，那我们肯定要做的，亏本也要送。”云云，而后听我们包工头在报备说门套可能颜色不匹配（卫生间、大门的门套和她家木门的门套），老板娘赶紧说我们这里门套也都可以给你做的，很会把握机会。当时我们没有确定要，结果第二天去又忘记掉，不晓得它原价多好，以后再去买肯定就不那么划算了吧。

之前经过一家卫浴店时，被它的特价499的淋浴器吸引住，包工头都是挺不错，蛮划算的，我们就特意过去逛了一把。结果没想到还消费了挺多的。马桶、水槽都这里买了，水槽也是特价，9件套，三把刀都分开算三件的，不过感觉质量、设计都还不错，下水的盖子都有两层，还有个挤压式洗洁精的小槽，右边水槽前方有个凹陷的长条状格子，可以放一些小物件。马桶么，也不知道到底怎么样，看它的外观、做工，按店员描述的功能，700块的价格应该也还过得去。

最后还逛了韩国大信整体厨房。本来厨房是准备给木工做的，结果看看这家店里整体橱柜做下来也挺便宜的，比木工做可能还要便宜，我们就打定主意定做算了。具体的设计啥的要等设计师上门测量，这里只能网上找个大致差不多的图片。业务员告诉我们，如果选择他们的抽油烟机+灶具的套餐，然后再选一个热水器，就可以享受橱柜价格的折上折，地柜从特价的999减到799，上柜则是减100到399/米。纠结半天，我们选择了一款玻璃台面的灶具，也就只能选择配套的那款抽油烟机了，都是他们大信品牌的，对他们家没啥研究，第一次听见，不晓得油烟机和灶具的质量如何，希望还好吧。热水器他们是代销，万家乐的，我觉得没必要选那个电脑芯片的，搞了款普通的，JSQ16-8L2，888元，网上查查898，没太大区别，它没有现货展示，希望到货时是图上这款，看着还不错。

（装修日记告一段落，静候下回分解。）

红旗之夜+陈麻婆豆腐+壮男

今天继续闲逛，准备去品尝另一家成都名小吃“成麻婆豆腐”，官方网站做得很不错哦，我去的是西玉龙街上的骡马市店（大众点评网上的介绍）。这一次记得拍了下人家的招牌，还是蛮有气势的。一楼的餐厅貌似在装修，接待小姐让我上二楼，二楼大厅的布局如下，远处有个不晓得哪个朝代味道的屏风吧，中间的小厅那里还有两位美女在演奏应该是古筝吧还是什么乐器来着，不过我基本上听不到他们的音乐。。原本以为陈麻婆豆腐应该算是成都话说的苍蝇馆子（也就是环境不咋的，苍蝇多，但食物味道好，吃的人多），没想到还有点档次，消费也不低。

来陈麻婆豆腐自然不能放过人家的招牌菜，麻婆豆腐大份好像是28，一个人我点了小份12元，份量还是挺多的，关键是酱很下饭，味道很不错，如果能够满足于豆腐下饭，绝对足以饱餐一顿。另外一个菜是汤，两个菜还是有点多，主要是之前一同事介绍说可以点份豆腐加份汤。服务员推荐了竹荪菌汤，22元，味道还是不错，不腻，感觉没有很多的盐味精啥的调味料。不过这个碗看起来大，其实比较浅，竹荪和菌份量不少，但汤水算不上多。

成都这里吃饭，餐馆对某些细节的处理估计放在杭州就不大行得通，人太多的时候，这里通常会让单独的几趟客人凑到一张大桌子上入座，当然点菜、买单都还是分开来的。一开始进去没位置，跟人家打组合，后来看到有张空桌子，就想换过去，没想到他们的服务员包括领班模样的人都极其不情愿，因为我只有一个人，却要占用他们的四人餐桌。本来想和他们沟通，希望他们理解，然后安排我做过去，没想到他们支支吾吾想糊弄过去不鸟我，后来俺没了耐心直接冲到那张桌子去坐着，按同桌的食客说的“直接过去坐着好了，他们总不能赶你走吧！”。

另一个小插曲，吃着吃着，居然停电了！扭头左边一看（窗外），边上另一家的茶馆灯火通明，然后就听到大厅里一片喧哗，服务员开始呼喊“没事没事，跳闸了”，然后就一堆人拿出小蜡烛开始点。大概几分钟后我吃好饭，埋单离开，结账的时候柜台边的一个领班和旁边说“叫人去包间里盯着，别走了”，呵呵。出门的时候又回过头拍了张照片，二楼他们餐馆的正门，被横梁挡住的灯笼的后面是他们的匾“贵宾楼”。

其实去吃饭之前，我先回的酒店，中途呢，碰到成都体育中心附近人潮汹涌，纳闷得很，咋个这么多人。。回头一查，“红旗连锁10周年庆答谢晚会”，邀请的明星还是有点多的（都是我个人不怎么哈的星），黄晓明、张靓颖、孙楠、齐秦之类的。和我有限的记忆中杭州的演唱会一样，四处都是黄牛，到处都是赠票，比如华西都市报的100张门票追加赠送。酒店边上就是体育中心，所以挤满了人。

 

旁边的街道也是人满为患，来看演唱会的，来凑热闹的，来卖荧光棒、充气棒、望远镜的小商贩。连酒店边上这几家小吃店也都是排队超级长，要知道平时下班回到酒店这个时候这些店里基本上都空空荡荡，服务员、厨师一干人等全都在聚众聊天啊。演唱会确实还挺能带动点GDP增长的。。

 

之前吃完麻婆豆腐就是回酒店，白天看到晚上直播预告说两场比赛都是22:00点，那时还嘲笑人家报纸不专业，这么点事情都要搞错，在酒店打开电视才发现、而后领悟，对哈，小组赛最后一场是要同时开始，以示公平啊。于是就赶紧下楼去锻炼，稍微偿还下吃进去的过量食物。。锻炼这事没啥好说的，不过俺这个体力和游泳的技术实在是有够丢脸，那么短的泳池，游到对面就要休息片刻才能游回来，而且还不见得能一直撑到对面，谁叫俺到现在都不晓得应该怎样正常换气呢。回到桑拿房洗澡，结果被一个壮男给震撼了，我靠，那肌肉，那小腹，估计算不上啥健美先生，但在俺这肌肉水平的人眼中看来，太TM健美了！胸肌是很明显凸起的两块，腹肌倒没看见啥清晰的七块纹路，但是人家就像是一块薄薄的皮附在下面板状的肌肉之上，大腿也粗得和什么似的。有点说不出口，俺真是佩服啊佩服。。。摸摸自己又大又肥的肚皮，心中那个惭愧啊。。。

成都出差杂记

前天早上在酒店用餐时，看到报纸上有一版是“全城成都精品购房信息”，随便扫一眼，成都的房价相比杭州，还真的是，哎，气煞人也啊。。今天和一哥们聊天，哥们为了家人和未来的生活，毅然从杭州返回成都，打算在此安居乐业，他看的楼盘或者说房子不算中心地段，但我觉得也蛮不错的。他准备在三圣乡买，我建议他还不如买里面点，以后楼上住家，楼下就搞农家乐，岂不乐哉。他还提到在郊区靠近龙泉的地方，买别墅，什么都配好，还送一堆的花园什么的，也才6000多块一平米。

这次来住在喜来登，经过天府广场的次数明显比以前多，发现一个不同于杭州的交通方面的特色。至少天府广场附近的人行道，并不是同方向的机动车、非机动车和行人同时行进，或者是稍微错开一点时间前行，而是，例如，先东西方向车辆通行，而后是南北方向，而后车辆全部红灯，各方向的非机动车和行人同时通行。。有时候看着真觉得有点心酸，那叫一个乱啊，又不是啥转盘式的交通埠，每条人行道上都有双向的人流，还有斜着的，还有在人流中飞速穿梭的电动车，颇有点胆战心惊。不过也奇怪，倒还蛮有序的没出啥事故。。

 

接下来，是今天早上用餐的时候，餐厅里人满为患，非常嘈杂，不单是本来就不咋滴的早餐选择余地更小，而且给我安排的位置就在背后煎蛋铺的前面，背后人来人往，搞得我心情挺烦躁的。

离开的时候走到大厅，才发现，是东风Honda的什么会议，但是看那里吃早餐的人不像是那种经常住酒店的，感觉就是比较普通的员工。不知道我猜得对不对。

不管怎样，人非常的多，男的女的一大堆人。联系到最近的一些新闻，我不由得怀疑是不是因为本田工人罢工的事情影响，所以他们要提升一下员工的满意度，所以安排点大家不常享受的星级酒店住宿。。。

如上纯属猜测，猜测有差错，我无心伤害。。

然后就介绍下今天的晚餐吧，之前在酒店周围闲逛时记得有家名小吃的，今天特地去光顾，就是钟水饺羊市街店（大众点评网，爱帮网），它还有自己的官方网站的。冲着它的名头，我就点了份钟水饺，看着它店里那么大的一个瓦罐，我就点了一碗酸萝卜老鸭汤。钟水饺5元一份，里面有10个饺子，忘记观察下里面的饺子馅是什么内容，不过吃起来倒是蛮有嚼头的。钟水饺的调料感觉全是辣椒，但比较奇怪的是这辣椒不辣，甚至还有点甜味。酸萝卜老鸭汤味道不错，没有以前家里自己做的那么咸，酸萝卜可能不是很陈的那种，鸭肉则有些酥烂，说明还是煨了好长一段时间的。瓦罐汤拿出来的时候是用一个很长的勺子还是夹子的东西，从那口大瓦缸里拎出来的，刚拿出来的时候挺烫的。我得说味道真的是不错，而且考虑到这个价格，酸萝卜老鸭汤6块钱一瓦罐，真的很不错。

 

  

再次来到成都：天府丽都喜来登酒店

又一次来成都，公司的协议酒店变动，这次选择的是成都天府丽都喜来登酒店，位于人民中路一段。

算运气好吧，预订的高级大床房没有，给我免费升级成了好像是豪华大床房，感觉不错。

房间给人整体感觉不错，只是有些细节让我觉得它似乎有点历史，插座是香港标准的，很多提示语言都是繁体的。总体来讲，还是很有范的，感觉比成都香格里拉差点，但比成都皇冠假日要好很多。还没有吃过早餐，不晓得这里的早餐如何。

房间挺大的，卫生间空间稍微局促些，浴缸看着还不错，淋浴间有点小，差不多一个人可以比较舒服地转身这么个空间，洗漱台蛮好的，我喜欢它镜子下方的一个小横台，可以放置洗漱用具，不需要和使用的杯子、手巾等放在一起，那样显得很混乱。衣帽间是寻常的布局，我喜欢那两个环保袋，颜色不错，中间的酒店标志S加上去很有点味道，拖鞋的脚感还不错。

洗漱用品和香皂的包装满不错的，色彩和形状都挺好，比较意外的是居然还有小瓶的漱口水，就是那些“Shine”盒子上方的绿色小瓶子。另一张照片是办公桌，网线用集线器收着，桌面正中是报纸，边上是水果盘，有荔枝、小小的应该是香蕉、苹果、柑桔，还有个绿色的水果不认识。。

 

窗外没啥风景，深绿色的窗帘是做摆设的，不能动，遮光要靠白色透明窗帘外面的一层遮光帘。床很大很宽，不晓得睡起来舒服不。床头柜上有个很复杂的电子设备，貌似具备时钟、闹铃、收音机等多种功能，柜子下面是七本杂志，其中三本是英、日、韩文的成都旅游指南，不知道为什么不提供中文的。。

 

再来张水果盘的特写。小吧台里的设备很齐全，可惜我很多都用不到，咖啡包的样子不错，茶包也还可以，电热水壶显得有点历史，算不上老古董，不过也不是新设备。泡茶的壶看着倒是很不错，在第二个中间的那个。

 

“Agile Coaching” Reading Accomplished

Finished reading the book “Agile Coaching” by Rachel Davies and Liz Sedley, it’s just as described :

“This book provides you with deeper knowledge of how agile practices work and how to inspire your team to improve. Discover how to coach your team through the agile lifecycle, from planning to writing software. Learn the secrets of running effective agile meetings and how to get your team following a consistent approach to creating software.”

You could download some chapters for free to read first before purchasing this book, get them from The Pragmatic Bookshelf, and here is the link at Amazon.

The book was written like a story, from the beginning to the end of coaching organization. Since I experienced this procedure several times, even I knew almost all those, it’s still very useful to reflect again, especially it’s “Agile” coaching, instead of “Scrum” coaching or sort of “Scrum + XP” coaching. This book is actually a must read for anyone who is in Agile, only if you want to be focused on business areas (e.g. Telecom system) or technical areas (e.g. programming in Java).

* Part I  Coaching Basics

First you should be clear about your role “Agile Coach”, and be prepared to start, its full checklist as below :

• Practice explaining Agile to others. You can do this with anyone willing to listen. Agile user groups are a good place to refine your Agile pitch.
• Do some groundwork, and work out the best way to be introduced to the team.
• Find ways to show that you apply Agile principles yourself. For example, you can work iteratively and have face-to-face conversations rather than asking questions by email.
• Apply the PrOpER cycle to your coaching interventions. Start with the problem, consider at least three different opinions that you can take, pick one and try that as an experiment, and then review the outcome.
• Pause to reflect and learn from your mistakes. Leave room for the team to learn from mistakes too.
• Look for opportunities to learn from other Agile coaches, both inside and outside your company.
• If you work with one organization for a long time, you can get pickled. When the team is running an effective Agile processes. It’s probably time to move on.

When you start there are many things to be aware, working with people is not just as easy as sitting together and start typing keyboards. You have to practice how to listen carefully in order to understand the problems, ask questions to clarify if you don’t get somebody’s idea. While providing feedbacks back to them, separate the observations which is neutral and your personal interpretations or even judgments.

Trying to introduce change is always hard, people are suspicious about changes normally. Share your passion for Agile, without being too fanatical. Talk with each individuals, care their opinions and concerns, clarify them, tell them what would they benefit from this change. Working on promoting the learning culture, encouraging people to read books by sharing your own, share blogs you  read, point people to podcasts, etc. And it’s 100% that you’ll face resistance, don’t be upset or put it into personal, start with understanding where it comes from, check the reasons from yourself first, this is actually a good attitude for Agile teams — don’t complain others, change yourself first.

The 4th chapter of this part is “Building an Agile team”, Rachel and Liz shared a checklist :

• Create opportunities for the team to get to know each other, which helps the team jell. Regularly spend informal time together, such as lunch or drinks.
• Create a shared workspace to help the team work together well. Try to get the whole team sitting together.
• Make role responsibilities clear. Get the customer the support the need to work within the team.
• Ensure the team has a reachable but challenging goal. make sure the work is neither too easy nor too hard.
• Arrange food or drink to celebrate a release. Ask customers and management to thank them.

* Part II  Planning as a Team

This part mainly talk about how to get the framework in place, covered topics like “how you do the daily standup”, “understand the requirements”, “planning and prioritizing”, “make progress and problems visible”.

Having a successful daily standup meeting is not as easy as defining the time, place and send out invitation. You may face tons of problems, people may arrive late for the meeting, people complain the meeting lasts too long, or the daily meeting is hijacked by someone, even you may have somebody who can not standup… The authors’ tips are :

• Find a space that the team can run their daily standup around their team board. If they don’t have room in their workspace, then use a portable team board.
• Make the time that the daily standup runs a team decision. You can run it more than once a day, if not everyone works the same hours.
• Encourage the team to keep their replies short and sweet. The three-question formula can help the team get started, but don’t let this become a straightjacket for daily standup conversation.
• keep the daily standup flowing; a speaking token puts this in control of the team.
• Ask the customer along to the daily standup to give her progress and updates.
• Gather issues that come up on a whiteboard where everyone can see them. Prioritize it with the team, and follow up afterward.
• Review the effectiveness of the daily standup in the retrospective, and experiment with the format.

According to my own experience, there is always a problem with understanding requirements, more or less. The user story practice from Agile is very good for this, it promotes 3C (Card, Conversation, Confirmation), to help team clarify the real user requirement, and establish common understanding, with the analyzed tests for acceptance. One thing would be important to mention is, the User Story card or any format of written-down is not requirement documentation, tell them the INVEST principle of a good user story.

At the beginning of each iteration, there is the planning meeting, help team preparing for it, and teach them how to estimate and prioritize. During the iteration, encourage them to have a team board, and make it the information radiator, plus big visible charts. Avoid burying information into electronic information fridges, it’s easy to ignore and don’t update them nor use them.

* Part III  Caring About Quality

In this part, authors talked about the Definition of Done, how to drive development with tests, and about writing clean code. “Done” is a practice used as agreement on quality, which “means the customer is happy with what has been developed, and all the story tests pass.” from the book. Check the picture on the right for example. Don’t forget testing, make sure that testing is considered in the iteration planning so testing tasks are understood by the whole team. Share the bugs at the same place as story tasks, otherwise there will be a hidden backlog in those bug tracker systems. At the end of iteration, if the team doesn’t get all the stories done, talk about it in retrospective, figure out ways to improve.

Test first is one of the XP principles, which forces you to think deeply about the reason for your implementation or design. Why I need this piece of code? Why I need this execution step of test scripts? Why I need to verify this functional behavior? Doing this in the best way requires a whole bunch of Agile practices, e.g. Test-Driven Development, Acceptance-TDD, Test Automation, Continuous Integration, Refactoring, etc. However, get people trained, and tried on those practices, reserve time for the transition to those practices. For Continuous Integration, focus on the attitude change than tool setup.

Keeping your house tidy and clean is obviously important; otherwise, over time it becomes impossible to live in. In the same way, if the team doesn’t take time to keep their code clean, it becomes messy and fragile, which slows them down. As their coach, you’re there to support them in learning how to keep code clean, tested, and integrated all the time. The checklist as below :

• Help the team strike a balance between spending time on software design vs.. time implementing code. The team needs to focus on designing for the user stories they know about rather than second guessing the customer.
• Remind the team during the planning process to allow time for incremental design. Get into the habit of using a whiteboard in the team workspace for design discussions.
• Encourage the team to improve software design gradually by refactoring before every check-in rather than building up technical debt. Refactoring tools lower the barrier to making design improvements. Make sure the team knows how to use them.
• Bring the whole team together to agree on a common coding style. If the team doesn’t adopt pair programming, recommend they incorporate peer code reviews into their definition of “done.”
• Help the team formulate a plan to renovate any areas of the code where design has decayed. Fixing broken windows helps the team keep the standard of design up.
• Use pair programming to get two heads on difficult problems and spread knowledge within the team. Set the team workspace up so that pair programming is comfortable, for example, two monitors displaying the same desktop.
• Introduce ping-pong programming to encourage pairs to swap between the roles of driver and navigator. Watch that pairs take enough breaks and swap partners rather than forming pair cliques.

* Part IV  Listening to Feedback

For the team, after started the iteration, it’s time for review the user stories, whether they are Done or not. And the team should take time to retrospect themselves too. In my opinion, retrospective is the most important for the team compare with other ceremonies, because it’s the point for Inspect and Adapt of the team. Normally you could facilitate it like in the sample agenda :

1. Review the goal of meeting, and remind the team of the ground rules.
2. Create a timeline.
3. Mine the timeline for insights.
4. Select the topics to focus on.
5. Review the progress on previous actions.
6. Generate ideas for improvements.
7. Action planning.

Been aware of those hurdles, they ruins the effectiveness of retrospective : Same action comes up again and again, cut them into smaller ones, or simply use the SMART principle for your action; Some team members are very quiet, and be clear that it’s ok to say “pass”; Team is always moaning, then try to get the team back into learning mode by asking, “if this situation happens again, how should we react to it?”; If you want to share your own impressions too, you need to be careful not to be seen as “taking sides”, “playing favorites”, stay neutral, or find another facilitator to help you, so you can be released to join as part of the team.

The final chapter is actually the most close important for yourself 🙂  “Growing You”, how you can grow as a person and keep your ideas fresh, you also need to take care of yourself in order to cope with the day-to-day demands of being an Agile Coach. Check Rachel and Liz’s checklist first :

• Make time to learn. Create a plan of what you want to learn this month and for how you will do so.
• Make time to reflect. The most powerful lessons don’t come from books but from learning from our own mistakes—small or large.
• Take time out to distress. Work can seem very important, and it is easy to let it swallow you up. Keep things in perspective by making time for yourself every day.
• Meet other people who care about the same things as you. Local interest groups and conferences are great places to meet people who will help you keep your passion for Agile alive.
• Be kind to yourself. Forgive your mistakes. Learn from them, make amends, and move on.
• Be kind to others. Don’t attribute bad intentions to people. Instead, find out why they are acting that way. Differences in opinion and style in a team are good.
• Don’t let your job grow stale. Keep pushing yourself at work; otherwise, it will no longer be fun.

Generally, it’s pretty much the same how you advice the team. First, look at what you’re good at or experienced, start from them, broader your knowledge areas, You could commit to read one technical book per moth, or listen to a podcast on your way to work; enhance your experience, by starting blogging, which requires you to think critically and be systematic and logical with your words. Second, you could create your own personal development plan, like a product backlog, what are the highest priority parts you want to improve, of course, remember the SMART objective. Third, build your network, join conferences and user groups, grow together, and learn from others. Finally, be kind to yourself, we’re human, we make mistakes, we are not perfect, so you are.

* My Conclusion

It’s a good book, read it.

《引爆点》阅读心得体会

最近几天一直在阅读《引爆点》这本书，原书名"Tipping Point"，作者是马尔科姆·格拉德威尔（Malcolm Gladwell），书中对他的简介：

“一个有着牙买加血统的美国人，《纽约客》的怪才，被《快公司》杂志誉为“21世纪的彼得·德鲁克”，被《时代》杂志评为全球最有影响力的100位人物之一。他的作品《引爆点》、《决断2秒间》以及新作《异类》都创造了书市神话。”

《异类》我已经看过，挺不错的。以前译言上有翻译的中文版本，现在貌似已经找不到了，估计和版权有关吧。《引爆点》此书可以在当当上搜索到，也可以在豆瓣上看得到相关的评价。

首先摘录书中的一些要点：

• 无论是暇步士的时尚潮，还是病毒的流行潮，都是流行三法则——个别人物法则、附着力因素法则和环境威力法则作用的结果。
• 个别人物法则：联系员、内行和推销员
  • 一个小马童为什么能够引爆美国历史上最重要的一场战争——美国独立战争？因为他是一个同时具备内行、联系员、推销员天赋的男子。
• 附着力因素法则：《芝麻街》、《蓝狗线索》和教育“病毒”
  • 要想把电视节目的教育意义和广告的价值传染给没有看到节目的人，就必须在观众身上产生过目不忘的附着力。
• 环境威力法
  • 戈茨案和纽约犯罪潮：整治地铁乱涂乱画的现象平息了纽约地铁里的犯罪潮，这是因为犯罪人群对环境透露的细微暗示极度敏感。我们的社会总存在这样一些不起眼的信息点，但这些点是群体效应的引爆点。
  • 150，一个神奇的数字：要发起大规模的流行潮，首先要发起许多小规模的流行潮。无聊是畅销书的朗诵会，还是企业生产的基本单位，发起小规模流行的团队最有效的人数不得超过150人。
• 个案分析：
  • 流言、运动鞋和转变力量：“云中漫步”这个品牌的推广得益于兰姆西斯前卫的广告设计。他们在掀起流行潮中既做革新者又做信息传播的中间人，他们修改、渲染和吸纳年轻人文化中的前卫思想，使之为大多数人接受。
  • 自杀和吸烟流行潮：青少年自杀与吸烟的传染途径惊人的相似，只有知道了引爆这些不良现象的因素，才能找到有效对抗这两者的方法。
• 结论：要发起流行，就得把资源集中在引爆点上，换个角度看待这个似乎雷打不动、无法改变的世界。只要找对了一个点，轻轻一触，这个世界必然能够动起来。

我记得以前看过一部武打片，好像是李连杰演的，他所擅长的功夫是先半握拳，用凸起的指关节击打对手，就像是一个点一样，随后握拳跟进猛击，颇有点撬动引爆点，而后追进的意味。能够选着并击中正确的击打点应该算是需要有内行的眼光吧，而后跟进拳击则要求有一定的附着力，诶，貌似有点瞎扯。。

记得很久以前看军事节目还是军事杂志，有种武器是类似于子母弹的。通过某种专业的定位系统追踪并和目标联系起来，而后由母弹运送，快要接触到目标前，子母弹分离，而后藏匿其内的散弹形成大范围的覆盖，附着于被击打目标周围，造成破坏。

不过我觉得最重要的还是让我联想到当下的敏捷转变。把敏捷转变看做是促进敏捷软件开发方式的流行，那么整个过程我们所需要的也就是这些人“内行、联系员、推销员”，以及敏捷本身的附着力，还有打造出的环境威力。

1. 首先要有敏捷开发相关的内行人士，他们的话语更有权威性和说服力，听到的人也更愿意相信他们的意见；
2. 而后也会有很多感兴趣的人，他们能够去尝鲜，能够搭建吃螃蟹者和观望着、隔岸观火者之间的桥梁，为后期的说服创造了可能；
3. 当然还要有推销员，他们再不断地重复着推广推销敏捷软件开发，真心地喜欢它，而且在实践。
4. 至于敏捷本身的附着力，我想则来源于任何已开展的敏捷转变的效果、口碑，如果一个事物已被证明确实有功效，而且应用广泛，那么得到更多人的青睐也很正常。但如果操之过急，败坏了口碑，被误会了敏捷转变失败的原因在于敏捷自身的话，也就无法实现其附着力。
5. 最后的环境，则需要更多的人、更高层的人来共同创建，从而产生环境的压力、推力，铺平敏捷转变的康庄大道。当周围的人都在言必谈敏捷，行必学敏捷的时候，你不搞搞敏捷还真觉得不好意思，而且连弄虚作假都觉得很过意不去。

敏捷的转变同样不能拔苗助长，书中的很多事例也说明，不管你心中有多么地想赶紧让自己的书、音乐、工作方式等流行起来，人们被感染并真心投入的速度总是有规律的。从一开始的若干人、一群人、一大群人慢慢扩展开来，只要找对了人群，影响扩散到一定程度时，口口相传的力量便会带来不可估量的变化。如果在产品线、业务线开展敏捷转变的过程中操之过急，没有足够的内行给大家建议、反馈、各种意见，那么人们会抱怨敏捷不好用甚至会坏事；要是没有那些关键的联系员，人们不会知道在其他的角落里也有人和他们一样奋斗着同样的事业；如果没有足够的热心人士，那么推行会遇到极大阻力，人们只会迫于上级淫威阿谀奉承，走走形式，不会去分享自己的成功经验。盲目的快速推行会在所有人心中产生一个大大的疑问“这东西到底有没有用”，可想而知其附着力必然有限，由于人们的不信任，套用墨菲法则“任何有可能出错的事必会出错”，对敏捷吃怀疑态度的人去执行敏捷转移必然会眼见敏捷转移的失败，附着力的丧失指日可待。至于环境威力，若无法构建积极向上学习敏捷、实践敏捷的氛围，人们很容易嗅到其中的不言之谜“装装样子即可”而后身体力行。

我想我们的方法有可取之处，首先要进行敏捷知识的普及，带来新的思维，触动思考，并从其中找到那些愿意尝新的人，以及影响面广的人。作为协助敏捷转变的组织，我们自然是作为内行角色出现或者推销员，但更为被协助组织所信赖的内行可能是外部的、中立的敏捷专家，内部的更好。而后发起各种实践社区，广招能人志士，创造足以影响人们思维发生改变的环境。并手把手协助他们一点一点的取得成绩，获得信心，从而坚定要继续走下去的意志。至此，我们便可放手旁观其发展。

但所有的这一切，都需要人与人的切身接触，面对面的沟通，影响力万万不是依靠着幻灯片的演讲、电话会议、上层一纸命令所得来的，其实这何尝不是印证了敏捷的价值观和原则呢？

• Individuals and interactions over processes and tools
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

2010再游黄山

今年公司outing的费用大大减少，往年的一半都不到，这次同学们出行只好节俭再节俭，旅行社也颇有些苦不堪言的味道，赚不到钱啊。我们全程不含餐，导游们没得提成。

这次的大致行程是，第一天中午出发前往黄山，山下住在屯溪的黄山华美达酒店，酒店布置还是不错，就是有点偏远，晚上没人出去晃荡，都在房间里打牌、三国杀之类的，老外们则在大厅里的酒吧喝酒。下午5点不到我们就抵达黄山市，导游直接把我们拖到一家餐馆“新安人家”，想让我们在那里吃饭。由于时间尚早，而且我们又没有包团队餐，有人问一句能否不在这里吃得到肯定的答复，结果就猢狲散，只剩下两桌人。其他人全跑去边上的老街晃荡，加购物，加吃饭。老街和杭州的河坊街差不多，都是那种旅游地的购物街，全是商铺。

# 以往的相册在毅 @黄山。这一次我的最大失误就在于自己忘记带相机，感兴趣的东西都没法拍下来。

去酒店的路上，导游不断地鼓吹黄山的醉温泉，问大家要不要去，标价188，团队价150，超级贵，没兴趣。。房间里环境还不错，可惜我要准备下周的培训材料，倒也无所谓，反正黄山来过，这次也就是打算来放松的。

有点奇怪的是导游约定的第二天出发时间是早上9点，挺晚的，不知道为啥。酒店的早餐不行，绕着餐台走上两圈了，也没给我的盘子里夹多少食物，而我比较失策地做了个决定，不好吃就少吃点，反正最近也要节食减肥。。后来才知道自己失误，紧接着我就选择了爬上山而不是坐索道，结结实实的4个多小时，累啊。。

导游约定了三个汇合点，迎客松–玉屏阁–西海饭店。爬到迎客松的过程很难受，一路上几乎没有欣赏风景，另一方面也是没有啥风景好欣赏，这一段路上没什么风景，当天的雾很大就算有也看不到啥风景。所以差不多都是艰苦的前行，走一段歇一段，不过我还比较满意自己的体力，3年过去了，体能下降很厉害，可我最后还是坚持全程步行到了酒店。

迎客松的人超多，懒得挤，为了利用有限的体力直奔我的目的地，我就不去凑热闹，直接向下一个聚合点玉屏楼出发。途中经过莲花峰，可以走一条直达的捷径，也可以爬上山峰再下来。07年的那次旅游我去了天都峰，莲花峰因为天气原因关闭，所以这次我的目标就是要去体会一下莲花峰，自然是要上山峰再下山峰的。莲花峰和天都峰还确实挺不一样，天都峰是直接一条路，很陡峭，直达巅峰，而后是鲫鱼背。莲花峰是弯来弯去，路还很狭窄，有些艰险，途中我都不怎么敢往下看，生怕会掉下去。。

最后当然是顺利抵达西海饭店，酒店外面都是很多的帐篷，据说都是酒店用来出租的。我们住宿的是通铺，按铺位卖钱，超级小的房间里，满打满算地放入四张高低铺的床，中间也就放得下一张长方桌，入口边上是一个破败的衣柜，里面是几个衣架还算干净，然后是还算干净的塑胶拖鞋。边上一个小方桌，把大门打开，和这个桌子也就隔着一点点缝的距离，真的很狭窄，方桌上有一台CRT电视机，一个电热蚊香器，8副简易的牙刷牙膏梳子香皂四合一洗漱包，呃还有一卷只剩下1/3左右纸张的卷筒纸。卫生间极其简陋，没有任何的毛巾类物品，连厕纸也没有，也没有任何洗浴用品，洗脸台边上满满当当地摆满8个漱口盅，就像是小饭店里喝茶的那种小杯子。

房间很挤，爬山很累，晚上也没啥心情和力气出去晃荡，老老实实待着看了会书也就睡觉了。很多同事都安排在4点多起床去看日出，我懒，还是没动，去了黄山两次，都没去看日出，自己都不晓得该不该算遗憾。。。

自己没有带相机，也就没拍照片，分享一下同事们拍的照片吧。

云雾缭绕的黄山风景：

 

 

  

日出的一些照片：

 

同事给我拍的（爬山累，所以换了短T恤和短裤，但黄山高处冷风很强，怕着凉，所以套着外套。。）：

  

还有些估计是用微距拍下来的植物和流水，很喜欢，有种很清新的感觉：

 

Ideas Triggered During the APM Training

* General

LM is not very relative to product, which leads to the problem of Competence Development: Actually the reason we do competence development should be the needs of product development. But now LMs are in charge of collecting competence development needs, heavily isolated from product development, much more for the sake of making people happy or prevent people being unhappy?

* Estimating

<Padding> If PM is used to their subordinates do padding, then they’ll behave like bargaining for less completion time. The number of the duration time is a number already in their mind, or just a number used to determine subordinates’ floor price. Because they believe if they press enough, they’ll get better price (smaller time estimation).

It’s just like bargaining during shopping. Without trust, it’s hard to discover the reasonable price value. And the behavior to force others accept the price lower than cost, will only get your lower quality ones or fake ones. Especially if you are not familiar with the product you’re purchasing, the chance being cheat is much higher.

If the buyer is an expert in this field, and trying to buy at a price below seller’s cost price, it will only leads to violent conflicts, or contact break.

<On Time> People do not care too much if they are on time, because whether a project / program is on time or not, the impact on themselves is too little, and too slow. However I’ll get paid because I worked 8 hours per day, the bonus is not a big amount of money too. Why bother?

If we can let people, (1)  share more benefit of being on time; (2) enjoy the benefit of on time faster and more frequent; (3) decide the time needed. When there is no pressure, drive by trust, the estimation will represent the real situation much more honestly.

* PM & Agile

Project Management has too many things that’s not necessary for software development.

PM should mainly take the guarding tasks around Agile.

Agile Development and Project Management by IIL

# BeforeReading

I just blog the training I participated, and record down what I experienced, observed, it doesn’t mean I support its opinion or suggestions. Because personally I believe software development should be managed in the way of Continuous Product Development, instead of short-term focused Project mode.

Well, a couple more words, Project Management is much more wide, and not specific for Software Project (e.g. a housing project, a build construction project), therefore the thoughts behind that doesn’t fits best. While Agile focus on software development more.

# Before Reading

Joined as observer in a 2 days training “Agile Development and Project Management” , delivered by IIL, the trainer is Wolfgang Wendl from Germany. He mentioned it’s his first time to China, and I think that’s the reason why he faced some problems during the training, since he didn’t know Chinese in training. Normally there will be English problems, especially if you have accent, and they wont tell you they didn’t understand. And so on.

In the opening part, he has a “Housekeeping Item”, which looks like a “Training Agreement”, talking about e.g. we don’t need computers, please mute your mobile phones, etc. There is one entry attracted my interests, it’s the “Emergency Exit”, even it is kind of unnecessary since we’re in our company’s building, but in general it’s very good, since the training may happen somewhere else, and it’s sweet to tell people how to exit in case of emergencies.

Below are the drawings he made regarding “Project”, “Project Management”, and the link of Project Management between “Classical” and “Agile” methods.

Once he explained the definition of several terms, “Practice ∈ Method ∈ Methodology ∈ Approach”, sounds reasonable, don’t know if it’s common accepted or not, I’m not a native English user. Needs further investigation.

 

  I’m suspicious how he explained Scrum and XP.

  He used the word “Done Done” that team should deliver “Done Done” features at the end of sprint,

  while IMHO there is only “DONE” and Definition of Done.

  For XP, check the photo. Curious about second-based Pair Programming, and hourly Code Integration.

  My question is, would PP be too pressing, and Code Integration too less frequent?

 

When “Communication” was mentioned, Wolfgang illustrated by drawing it out as below.

 

  While the sender sending messages to receiver, and receiver provides feedback.

  There are different Culture, Education and Experience, which makes communication hard.

  That is our Model of the World, and  they’re different of course.

  Communication is about increasing the overlapping part of sender and receiver.

 

 

We went to the Knowledge Areas of project management : Scope, Time, Cost, HR, Quality, Risk, Procurement, Communication, Integration. The project phases are Initiating, Planning, then Executing, and Monitoring, final one is closing.

 

Risk Management was not in the original course content, they adjusted based on our request, picked it up from their Project Management Fundamentals course. As written on the flipcharts, risk is an event which has possible impact, either positive or negative. Risk Management contains 4 activities, 1) plan first; 2) then identify them; 3) analyze the risk via a PI (should be Possible Impact) matrix; 4) Define the Response Strategies, which might be “Avoid”, “Accept”, "Mitigation”, "Transfer”.

He introduced several tools for this, e.g. SWOT or Critical Path analysis. For me, it’s funny that when he asked “anybody heard SWOT analysis before?”, nobody raised their hands or answered. For the Critical Path (or other names, my memory is bad…), I just don’t understanding why we complex our simple life by this. Didn’t get the idea of using ET / EF / LS / LF, and Float.

 

These 2 charts should be the drawings while he is explaining WBS (Work Breakdown Structure). And he embraced User Story technique into this WBS thinking, considering Epics as the first level deliverable, and User Stories as the second level work package, and then split them into tasks. When it comes to estimating, due to the famous “Padding”, estimations are not accurate or trustable, therefore you can use “Three Point Estimate”, one Optimistic estimation, one is Pessimistic, and the Most Likely one. Then you could use (O + P + 4 x ML) / 6 as the final estimation. My view is, playing with numbers doesn’t improve your estimates, and finally ensure you’re on time. And also, the uncertainty of estimates are mainly from the work itself, instead of trust issues. Even if there is such an Agile Project Manager, this kind of distrust behaviors will reinforce itself. E.g. PjM doesn’t trust teams’ estimates, and thought he must ask team to give 3 estimates, then the team will feel the PjM doesn’t trust them, then while bother giving trustable estimates?

  

The explanation on “Trust” as below, those characteristics look fine, but can not understand the formula “Trust = ( C + R + I ) / S”.

• C : Creditable
• R : Reliable
• I : Respect + Caring
• S : Self-Orientation

Here is his summary on differences between “Classical PM” and “Agile PM”. No Comments. Sounds reasonable if you read from a more PM angle, sounds nonsense if you read from Agile angle.

Finally, the most interested part “Stakeholder Management”, it’s actually given in the beginning as in the first module. Which is identifying different Stakeholders, clarify or access their interests and power, and then act. It’s exactly what my sales friend told me about sales, you have to figure out who can affect the deal, what’s their impacts, on technique decisions or business purchasing decisions, can they accelerate the sign of contact or you have to ensure they don’t slow you down.

The Design Infected by Organizational Dysfunction

Had a fierce discussion with one engineer, which started from reviewing her automated test case. It’s written in robotframework, one criteria of good quality test case is descriptive naming, for keyword names, test case names, etc.

* Discussion 0 : Background

Well, the case title was not descriptive, and I asked the regular question “what does this test case test?” The functionality it tests is,

• Process Under Test (PUT) send message to another process while restarted and just started up
• The target process should send back acknowledge message to the PUT
• If PUT received acknowledgement message, then it’s fine, nothing happened <—-the functionality to be verified
• Additional :If PUT didn’t receive it, PUT will resend it for totally 5 times, after that, write error log for recording

But those test steps didn’t reflect the purpose, it just reset the unit (the PUT shall restart when the host restarted), then check there is no error log. While my opinion is, those 2 steps can’t prove that the functionality happened, therefore you can’t say “no error log” is the result of “message – acknowledgement”, since if there is no message sent out or other problems happened, there may be no error log too. You must prove the connection between “message – acknowledgement” and “no error log”.

Well, then the discussion or argument or even say a debate started, moved to software testability, software design, system architecture, organization, etc. And finally after 1.5 hours, I’m too agitate to catch-up my breath, then we went for lunch.

* Discussion 1 : Testability

I questioned that she could start a monitoring process on serial port (which connects to the unit), then restart the unit, the corresponding messages can be captured on serial port. This is a minor misunderstanding, she soon explained that the PUT sends out the message after restarted, if we want to monitor messages on this unit, we should do it when the unit is restarting, well, it’s kind of impossible.

Naturally I asked “why not monitoring the target process?”, so we could judge by it received message and send out acknowledgement. The answer is

“the target process resident unit was developed at another site, by another team, from another subcontracting company Aricent.”

“we don’t know how to operate on that unit, there is no documentation, we asked them if we could check their functional test cases, they said they have it in QC, but we can not find them, after asked several times, they finally said they actually haven’t write any test case.”

What a ****!!

I proposed that they could add some debug logs in their code, as workaround to indicate PUT sent and received acknowledgement, but they have to use production compiled build for test. Then I thought they could apply conditional compilation, she thought that would add some additional effort. However, we have some level of agreement that the workaround may work, it’s just a matter of cost.

* Discussion 2 : Design

I was too curious to ask the question “what’s exactly the functionality you’re testing by this case?”. Since she said they had one test case which restarts PUT and verify the similar functionality, but they were reported one bug regarding PUT during unit restart. Seems abnormal PUT restart is different from restarting triggered by unit restart.

By clarifying this question, it leads us towards the proper granularity of testing point. Therefore we will also clarify the preconditions, setups, execution steps, results expectation, cleanups. It is the design of testing.

Well, I didn’t got the idea why they need to implement this functionality, now I got the answer “for bug fix”. Then I’ questioned, why this solution for this fix? Where is your requirement documentation?

They are in a legacy product, it’s fairly mature now, not too many new feature development work, mainly product maintenance work. Due to those technical transfer processes, there is no real experienced developers anymore, nobody is really clear about the design of this part code. And it’s actually the team themselves created the requirement, so they chose this design solution.

I’ was so opinionated, I didn’t like introducing new things while not really necessary, especially if you can do it within current context. The mechanism was used to ensure the target process have received message from PUT, so they add the demand of acknowledgement. In the scenario she described, the target process will send some data to PUT by certain message, each message contains one single entry data.

I insisted in using the certain message with 0 entry data, as well as the acknowledgement message. Their reasons (or excuses) are, the message fields were already frozen, change its definition would requires a lot of changes, since they don’t have a field for “entry amount” before.

* Discussion 3 : System Architecture Choice

I can not convince them, nor they can. But I’m still not satisfied. Then I moved to question them “why you need to ensure the target process received message?”, since their messaging mechanism in existing system is reliable, there is no need to ensure from message sender point of view. The reason is, there is a new unit where the target process locates, which is not in the original system (HW-wise), communicates with other processes in old system via UDP which is unreliable. Because of this, they need to handle it.

The system has a so-called message-bus component (module, process), and a dedicated component for transport layer issues. Of course I doubt this, why can’t those components encapsulate the underlying UDP transportation as usual, and expose the same messaging interface to those application processes (e.g. the PUT).

Another team member joined the discussion, and shared the historical discussion related to this. They had the same opinion as me, and challenged the requirement, but they’re told it’s a decision, just do it. I’m fine with upper level decisions, if they can convince me, or they really understand the consequences and accept it. But if not, I’ll be really challenging and noisy. They can’t tell me if the chief architect provided reasonable explanation, they didn’t remember. They also tried to find if there is any other team facing the same problem, and having any solutions for reference, but seems they’re the 2nd one, and the solutions are pretty much the same.

The answer sounds unacceptable to me, it’s so obvious that, compare to solution 1 solving UDP problem within single component, the solution 2 that each process solve problems by themselves will introduce much much more duplication code and algorithm. Well, I didn’t know programming too well, I can not tell if the solution 1 will be more costly in run time, since it verifies each UDP packets reached the target.

* Discussion 4 : Organizational Dysfunction

I had a huge problem with failure in duty behaviors. I think the problem now is, the system architect didn’t explain the reasons why he/she wants this specific design solution, and obviously those people are not satisfied, and it may complex our code more, further more make maintenance harder. This is the duty of system architect.

I already had a huge problem with Software Design activity in the stage-phased model.  How can they prove that the solution is the right one to fulfill customer requirements? And how can they prove it’s the best solution among those ones? The SDLC didn’t answer this, Waterfall didn’t, nor CMM/CMMI.

Plus the problem of communicating their design solutions to implementation engineers, it re-enforced the dysfunction. They didn’t want to or didn’t know how to explain the reason of the design solution, or they didn’t describe clear enough, they fixed the design solution into stone, then passed it to the implementation team by deliverables. The implementation teams implement it, and confirm it by verifying the expected system behaviors. While at the same time, they may not understanding if it has any side-effects besides the expectation part, nor it’s too much for just meet the expectation (in another word : over-design).

Agile provides the correct answer : “Simplicity” principle. We encourage emergent design, just enough design, as simple design as possible, etc. The system level architecture and design was reflected by division of classes, in terms of component (class, module) responsibilities. From top down, we communicate based on requirements, or say “what we need”, instead of a direct solution to an unknown problem. Let the people who implements the requirement decide the solution.

Together with Test Automation and Continuous Integration, you enhanced the common understanding of design of working code into working tests. And those nonstop quality safeguards continuously provide you the feedback of current software functionality consistence.

* Thoughts : Design Infected Organization, or vise versa

The thought process used in designing software has a huge impact on designing the organization, or say the software design is mainly inherited from the thoughts of organizational structure.

If we designed software in one way, then it is very natural to organize people in the similar way, because the most convenient and cost-efficient approach is put most-in-common-duties people together.

While there is an organizational structure, it re-enforces the software design reversely. Because people want to do their job better, better according to the role responsibilities, and which is exactly formulized during the initial software designing.

---

* Followup

She came to me today, updated me some information regarding the problem afterward.

"We could test in a way that, we check and save the information on unit before restart, then we restart, after the unit started up, we check the information again, it should be recovered to the same as before restart."

I agreed on this idea. Since the feature / functionality is actually a redundancy mechanism, while the master node restarted, it will require the tributary nodes to send previous information, so it could recover back to the original state. There is no 2N redundancy, because in some cases, there is only one unit, no spare ones.

Then we elaborated a bit more.

• From unit test level, they could cover the message exchanging logical, both receiving and sending.
• From the overall feature level (blackbox), they could verify that the information is recovered after restart, before the feature doesn’t necessarily related to the detail design implementation.
• For the unreliable UDP transfer, it’s not such a big deal, from both unit test and feature level, they’ll verify that if the target process can or can not receive messages, if the information of PUT can or can not be recovered. The underlying transferring method is not the feature’s business.