Observation Notes @ Clinical Decision Unit

This week, I had an adventure visiting local hospital A&E. With most parts of my body still working well, I was curiously watching the operations there and the following are my notes and thoughts. It might not make sense at all but it might be interesting to share……

At A&E, soon after a few checks, I was sent to Clinical Decision Unit (CDU), where patients need to be watched, checked and wait until a duty doctor can make a decision on their cases. Normally this should take a few hours or more as the decisions are made based on some test result come out. And a decision could be taking more tests based on the results. My case fell into the latter scenario and I was there for totally 36 hours.

During the time, I was regularly checked by nurses on body temperature, blood pressure etc. I was also given pain killers regularly based on my feeling of the pain. There are about 30 to 40 patients in two large rooms with beds and a waiting area with seats. I believe there are about 10 staff at one time, including nurses, managers and doctors. To take care of every patient by different nurses and doctors, the operations in general are quite efficient and smooth, how do they do it?

Every patient is allocated a bed, a folder with a bed number, which has all the medical information, different forms, doctor and nurses’ notes, test reports etc. A doctor or a nurse have to take care of multiple patients and a patient will be taken care by definitely more than one nurse or one doctors. During the time I was there, my case has been reviewed by three doctors and I have been taken care of by seven different nurses. Every time, different nurses come to me, asking my name, my date of birth before he or she conducted any action, such as taking blood for tests or giving medications.

There is a big screen in the room, showing the patient and their medication measures which I cannot fully understand but I believe that screen show an overview of the Unit, the capacity, the progress etc. If some patient needs to be sent home by an ambulance, the Unit manager will arrange the transportation. Every so often, we can see the patient were sent in on a medical bed by a crew of ambulance and the duty manager of the Unit helps to arrange a slot for the bed. Patient sent from the A&E room should sit in the waiting area first to wait until a bed is available. The managers also take care of the staff who are responsible for food and clean the bed.

The interesting moment is the doctor review time and how they make decisions. This could happen case by case or by a routine review in the morning or evening. When all the results come back and check-up completes, a doctor will review the case. In the morning session, the doctor came with trainee doctor and his medical student. They discussed each case based on the information of patients’ folder, talk to nurses and then talk to the patient. I believe this is very much evidence-based decisions as the doctor will discuss the patients’ symptoms, the test results and the decision, which could be more time to watch and monitor, more tests to do or discharge from the unit. They also will ask how the patient feel and see if they can help in any way. All sounds not that hard if the symptoms are not life threatening and most of the time the patients got discharged with assurance as every test results show the body is reasonably function well.

At this point, you might wonder why I am interested in this? What is my point?

Let us compare this operation to a live defect fix scenario in a software development team. Dealing with live defect is like working at A&E. A system with live defect has to be fixed or a work around has to be applied by a developer at a limited time. Sometime the defect can be fixed quickly but sometime the defect takes ages to investigate. The live defect fix process is not as smooth as the Clinical Decision Unit. Most of the time, we will see following scenarios:

  1. Sometime, the systems are too poor to be fixed. This kind of systems are often called Legacy. I don’t know why this beautiful word is used to describe something going to be dumped soon. Often it is quite difficult to fix a live defect of a legacy system as the technology is outdated and nobody really knows what is going on inside.
  2. Sometime, the investigation can be time consuming as the developer need to reproduce the live issue in a development environment and sometime it is quite tricky to do so.
  3. It is quite common that one system can only be fixed by one or two developers as they have all the knowledge and it will take too much time for others to do the same job.
  4. It is also quite common that a live defect fix can trigger another defect as the quick fix applied with time pressure might not be technically sound and often it overpasses a development pipeline because of time constraint.

Compare to the CDU, the systems with live defects are like patient registered in A&E. The developers are the doctors, we have managers to take the defect in but no nurses to do the check-ups or specialists to do all kinds of tests, or analyse the results, such as blood specialist, heart specialist or radiologist to look at the X-rays etc.

There are more differences comparing the live defect fix with A&E operations, see the following:

  1. No nurses
  1. No routine tests
  1. No specialist
  1. The system cannot talk
  1. The systems are all different comparing to a human body
Advertisements
Posted in 信息科技 | Leave a comment

Story of Coding

This summer, I spent almost all my spare time on preparing a talk in DDD (Developer, Developer and Developer) North. It was a 60-minute long talk, which literally took me 10 years, or even 20 years to get to that public stage. (Yes, do you know that our fear of standing up in front of a group and talking is so great that we fear it more than death, in surveys at least. And speaking in your 2nd language in front of your professional peers including your colleagues, your boss is even worse than that).

And the journey of my coding goes far further than 10 years or even 20 years.

In 1980s, when I was in primary school, I was chosen to learn programming in a summer short course funded by Children’s Centre in my home town in North Eastern China. It was the days that China started to learn a bit more about the world. They imported an Apple II computer and I was there with a few other kids learning the language, Basic. We did learn very basic things, wrote a few little programmes using a kind of English, if, else etc. Even it was very basic learning,  I have to say, this first touch of computer and programming planted a seed in my mind.

(To continue ….)

Posted in Uncategorized | Leave a comment

关于代码那些事

这个夏天,我几乎用了全部的业余时间去准备一个程序员大会六十分钟的演讲。台上一分钟,台下十年功,老话不就是这样说的? 今天就写写那过去的十年,二十年,甚至更久的关于代码的事吧。

第一次接触写代码是上小学的时候。那会儿市少年宫进口了一台苹果电脑,组织了一个少儿编程序班。我有幸在那个学习班学习,接触了第一个编程语言,Basic。虽然只学了几个语句,编了几个小程序,和代码第一次的亲密接触多少让我对计算机有了点儿兴趣。

后来等到上大学才真正学习写代码。大学一年级第一门编程课是学习Pascal 语言。教课的钱老师喜欢抽烟,嘴角常带着一丝微笑。他的课很好听,一个学年下来觉得意犹未尽的感觉。后来读研究生的时候,我又毫不犹豫的请他做我的导师。钱老师那会儿做系主任,见我的机会也不多,大概一个星期一次吧,在他的办公室,计算机系楼三楼走廊尽头的一个小屋。钱老师话不多,不过每次见面,跟我说的内容都很深奥。谈过之后,我就乖乖回去在图书馆里啃书本,然后去机房里敲代码。这样孤独的写代码日子让我多少有点儿自卑,怀疑自己写代码的能力,面对导师,一直都是望其项背的感觉。

研究生读过一半,钱老师安排我去一个日本公司做实习。我的工作是用COBOL语言编写程序,支持财务和人事部定制和打印报表。那是我第一份有薪水的工作。几个月下来,赚了点儿钱,不过一点儿也不快乐。现在想起来大概有两个原因,一是COBOL语言本身就很枯燥,虽然语法上更接近自然语言,代码一行行的写出来就是对数据一次次处理,转换,繁冗复杂。另一个原因是我对日本人管理的方式有抵触情绪。他们在工作时间安排上极其苛刻,上午下午各有一次休息,听到铃声才可以站起来出去走走。那段经历给了我很多负能量,对写代码失去了兴趣,对自己未来的职业也一片茫然。

后来 IBM 在学校里办了一个培训中心,大力推广他们的技术。在这个培训中心,我又接触到SmallTalk, 一个真正面向对象的语言,当时的培训老师是计算中心的牛老师,讲课也同样生动有趣。面向对象语言和之前用到的面向过程的语言相比建模更有挑战,代码的编写更接近于现实生活。面向对象的语言开辟了一种新的思维方式。这段短暂的培训让我感受到写代码有魅力的一面。

研究生要毕业的时候,我和钱老师有一次长谈,谈编程的语言,谈编程的挑战,谈未来的工作,谈这个国家,甚至谈到世界。那会儿香港已经回归了,好多外资企业进入中国,几个同学在准备去国外读书。我问他对出国有什么看法。他说他在美国工作生活过半年,去到那里的时候,他大概花了一个星期去适应环境,等半年以后回到国内,他花了几个月也没适应过来。这句话我记忆深刻,因为当时甚至现在我也说不清老师不适应的是什么。在告别的时候他对我说,工作以后再好好学学英语吧,有机会去国外看看。

毕业两年左右的时候,钱老师突然病逝。我们毕业时候的那次长谈竟成为永别。噩耗传来,又想起往事,想起老师临别时的教诲。我也从那个时候开始把学英语和出国放进自己的人生计划。后来来到英国以后,慢慢体验老师当年的感受。

来英国读博士的时候,我所在的伯明翰大学的研究小组得到了微软的支持,我又开始学一门新的编程语言: C#。微软在2002年推出这个简单的,现代的,面向对象的语言。作者安德斯·海尔斯伯格就是当年Turbo Pascal 编译器的作者。他加入微软后推出这个语言,和跨平台运行的Java 抗衡。从C# 中,可以看到 C, C++,Java 和 Visual Basic 的影子。经历了十四年的发展,微软今年推出 C# 的第七个版本。每一次新版本的发布都给开发者一个惊喜,同时也带来不得不更新技能的压力。软件的更新换代是这个行业最大的挑战。俗话说活到老,学到老,这个行业是做一天,学一天,不可以停歇的节奏。《Pragmatic Programmer 》(程序员修炼之道) 中建议编码者每年学习一种新语言。优秀的编码者都坦诚他们除了每周四十个小时的工作以外,还要花上十到二十个小时学习新的技术。

和其他行业,比如建筑,医学,法律相比,软件行业还是一个很年轻的行业。从1945年艾伦∙图灵开始在第一台计算机上用二进制编码写程序开始,这个行业才发展了七十年的时间。在这七十年里,计算机硬件按照摩尔定律发展,每十八个月,性能就提高一倍,而软件行业并没有革命性的发展。最初的面向过程,面向函数的编程模式仍然影响着今天的软件行业。今年第七版C#推出的新功能就借鉴了一些面向函数语言的特性。

写代码的过程是一个不断做决定的过程。每一行代码,每一个数据结构,每一个控制流等等都是编码者做出的选择。从这个角度来说代码也反映着编码者的思维方式。由于每个人思维方式不同,读代码比写代码更有挑战。一个编码者试图从代码里揣摩另一个代码者的心思是一件有趣而又伤脑筋的事。编程界教父级人物 Uncle Bob 在《Clean Code》(《代码整洁之道》)上说读代码的时间要比写代码多十倍还多。这个比例和我们读小说刚好相反,一个作者花十年写的长篇小说,读者应该不需要用一年的时间来阅读。那是不是写代码比写小说要容易得多?这不见得。写出代码容易,但写出高质量的代码是充满挑战的。编写代码不仅要实现功能,增加其可读性和可维护性也同样重要。现代编码的工具虽然可以帮助编码者分析,纠正,甚至直接生成部分代码,编码仍然是一件有挑战的个人创作过程。衡量和提高编码的质量也一直是这个行业探索的话题。

针对这个话题,我在英国北部地区的年度编码大会上 (DDD North)做了一个演讲,演讲的题目是《控制,控制代码的复杂性》。

Take Control, Control Code Complexity

This talk is about control, control our code, the flow, the tests and   the complexity. It might be difficult to control the border of this country, but as a developer, we can take control of our code, can’t we?

Reading code and maintaining code cost us time and money.  “The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write. (“Clean Code: A Handbook of Agile Software Craftsmanship” – Robert Martin).

We can’t manage code complexity if we can’t measure. It has been forty years since Cyclomatic Complexity was developed and published in the seminal paper “A Complexity Measure” by Thomas J  McCabe.

What have we learned from this measure? Can this measure help us limit the complexity of our code? How to use this measure to guide our coding and testing? How to reduce our code complexity and make it easy to read and maintain? 

This talk will look at a real-world problem and see how we can solve the problem with less complex code. 

控制,控制代码的复杂性

这是一篇关于控制的演讲,控制我们的代码,流程,和测试,控制代码的复杂性。控制这个国家的边界不容易,作为一个编码者,我们还是可以控制我们的代码的,不是吗?

阅读和维护代码正在耗费着我们的时间和金钱,”花在理解代码上的时间和写代码时间相比要远超过十比一的比例……(因此)让代码更容易阅读,才能使代码更容易写。”(《代码整洁之道》Robert Martin, 2009

如果我们不能衡量复杂性,我们也难以控制它。据这个领域的经典学术论文–     “A Complexity Measure  -Thomas J McCabe, 1976(软件复杂度的测量”)的发表整整过去了四十年。

我们从这个测量中学到了什么?这个测量可以帮助我们降低代码的复杂程度吗?怎么样来用这个测量帮助我们写代码,写测试代码?怎么样来降低编码的复杂性,把编码写的容易理解和维护?

在这个演讲中,我会和大家一起看看怎么用尽量不复杂的代码去解决一个实际的问题。

最后,把这份荣誉送给在天堂的导师,想告诉他,在异乡,学生一直在努力。

Posted in Uncategorized | Leave a comment

我们的七月

二十年前的那个七月
我们彼此告别
在西山月亮门前
在通往校门的林荫路上

今天在毕业纪念册里,
又看到你们青春的笑容
还有真切的话语
道出的满满的祝福

记得聚餐会上
我们豪迈的饮酒
用摇滚的歌喉
相约未来的那个冬季

没有你的日子里
我会更加珍惜自己
没有我的岁月里
你要保重你自己

那个七月
我们没有离别的感伤
没有难舍的拥抱

或许内心深处
你我都相信
有一天我们会再相聚

不是大约在冬季
是今年七月
是未来的某个七月
Posted in 诗文歌赋 | Leave a comment

五月的巴黎 (Paris in May)

五月的巴黎
好暖

这个城市
有留住太阳的魅力
阳光在这里停留
照亮的
不只是大地

坐在街边的咖啡店
不在店里在店外
和阳光一起
甜蜜

巴黎的公寓
别致的阳台里
盛开着鲜花
鲜花丛里
蜜蜂飞来飞去
点缀着美丽的巴黎

Paris in May
Enjoyable warm

The Sun
Must love this place more
As it likes to stay

The sun shine
Sings and dances
With everyone it loves

Sitting in the café
At the table outside
To be with the sun
To be happy

The apartments with balconies
The balconies with flowers
The flowers with bees
The beautiful street of Paris

Posted in 诗文歌赋 | 2 Comments

QCon London 2016 – Day 3

What a fantastic day in QCon!

The keynote speech is stunningly good. It is not a speech, it is a stage performance with great collaboration, humour and deep-thoughts from a mind of academic and a mind of practitioner. Kolton Andrus & Peter Alvaro, told us their story about how they met and worked together to solve Netflix Failure Test problem. It was a successful story. And there are loads of reasons why they can succeed, such as

  • The core value of Netflix: “Freedom and Responsibility”. Freedom is more than anything we want at a work place and the responsibility is the way we pay back.
  • Meet in the middle, the great idea has to solve the real world problem. Compromise is the first step towards real collaboration.
  • Adapt the theory to the reality: keep the vision in mind but continuously adjust the model .

Then there are a few good talks in Javascript full stack track. As the track host mentioned, no matter you like Javascript or not, you cannot ignore it.

Posted in 信息科技 | Leave a comment

QCon London 2016 – Day 2

Today is the giant players’ day. The engineers from Google, Microsoft, BBC, Netflix, Intel, Docker…. all had their show.

Senior Technical Architect Stephen Godwin from BBC talked about Cloud-based Microservices Powering BBC iPlayer. It is an excellent story about how BBC transformed their monolith system to micro-services run in AWS in a 9-month time-span. And the lessons they learned are very practical: Design your system linearly, expect things to fail, avoid big bang, design for migrations. And another interesting thing he mentioned in the talk is: “I’m not going to say how big micro-services should be, but at the BBC we have converged on about 600 lines of Java”. And Stephen mentioned the team for a service is just 2 developers and the developers spent about 60% of their time writing tests.

Principle Engineer Micah Lemonik from Google talked about the challenges of building real-time collaborative Google Docs. It is a great example about applying computer science theory to build a data model to support the design. Fundamentally, to solve a problem, we not only need to understand the requirement well but also have the deep grasp of the back-end requirements. And sometime what users expect are not always same as what the developers want to give. He had a great interaction with the audience guessing the result of collaborative rollback, try yourself here, the answer of you can tell what type of engineer you are as Micah said:

  • User A type 6 in a cell
  • User A then update 6 to 7
  • User B then update 7 to 8
  • User A then hit “Undo” (Ctrl + Z)

What is the result to User A? 6, 7 or 8?

My favourite speaker in QCon Dan North gave another charming talk: Making Sandwich Effective Feedback Techniques. This is the kind of talk you can take with you for the rest of your life, thinking how to give others feedback, how to receive feedback, how the feedbacks work in a team settings, in a system, in an organisation.

Posted in 信息科技 | Tagged | Leave a comment