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
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


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


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


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



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


写代码的过程是一个不断做决定的过程。每一行代码,每一个数据结构,每一个控制流等等都是编码者做出的选择。从这个角度来说代码也反映着编码者的思维方式。由于每个人思维方式不同,读代码比写代码更有挑战。一个编码者试图从代码里揣摩另一个代码者的心思是一件有趣而又伤脑筋的事。编程界教父级人物 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