(我是一個前端開發者，但我想這個故事對任何開發者都會引起共鳴的)

有人向你反饋了一個bug。 “26樓會議室的燈亮著。它應該是熄滅著的。”

bug的備注里寫道“你應該能在5分鐘內搞定，只要按一下開關就好了。“

你去了26樓的會議室。燈的確亮著，但房間里沒有燈的開關。

你準備自己安裝一個開關。但設計師說，它會破壞房間的美感。另外，墻壁是混凝土。你需要合適的工具才能安裝開關。但是，沒有人會批準購買這些工具。如果沒有合適的工具，安裝開關將需要兩天。他們希望你現在就能把燈關上，因為他們害怕CEO可能心血來潮決定去26樓逛逛，并恰好路過了會議室，問為什么燈是亮著的。

現在你不斷地收到郵件，詢問為什么會議室的燈還是亮著的。?你不得不群發一封郵件說明情況，幾人開始了一個恐慌的電子郵件鏈。

你知道，如果你期待著問題能夠被郵件討論解決（而不實際做點什么），這個問題永遠也不會得到修復。bug系統里，這個bug歸你處理，而且它的最后期限就是今天。如果問題沒有解決，會有麻煩的是你。所以，你設法進到了26樓走廊的天花板里，找到了會議室燈的電線，一刀切斷。問題解決了。

為了平息在電子郵件鏈里的恐慌，你(再次群發郵件)說明了你是如何解決問題的。

郵箱安靜了一陣。當它再次響個不停的時候，每個人都在擔心，現在會議室的燈無法開啟和關閉。如果CEO想在那里開會怎么辦？因此，他們要求你“把燈的電線牽引到地下室去”。當有人需要開關燈時，他們會通知你到地下室去，連接或斷開電線。

你抗議這個荒謬的解決方案。你的上司說，“是的，我知道這不理想。但它是現在唯一的解決方案。“

你面臨著選擇。你可以照著他們說的做，或者辭職以示抗議，另謀高就。但你知道，一旦你開始了新的工作，新的同事很可能也會要求你做這么白癡的事，如果不是更白癡的話。

你把26樓的電線牽引到了地下室。當你進入地下室后，發現已經有幾十條電線掛在墻上。你知道你不是一個人，也知道了這個白癡想法是從哪來的。你調整好了電線，盡人事地貼上標記，默默地向下一個可能處理它的哥們道歉。

終于，你回到了你的辦公桌，你收到了一個新的report。 QA重新開啟了bug。bug描述里說“房間還是亮著。”

你回到26樓的會議室。燈是熄滅著的。你返回辦公桌前，關閉了bug，注明你已經親自檢查過了。

QA再次重新開啟了bug。“房間還亮著”bug描述里堅持。再次親眼確認燈泡的狀況后，你將情況匯報給了上司。他建議你去地下室檢查電線。你抗議說你正直盯盯地看著燈，它就是滅著的。 “我知道，但去檢查一下。這樣一來你就可以告訴QA你確認了所有流程。”

你嘆了口氣，前往地下室。果然，電線沒有連接，切口兩端都好好地被包裹著。它們不可能以任何你能理解的方式導電。

你向QA反饋，你檢查了電線，它們沒有連接著，你正看著燈泡，它是熄滅的。

“我不是指燈泡，”QA說。 “bug里描述的是房間里的光。房間現在仍然不夠暗。你應該拉下百葉窗。“?你回應說百葉窗不歸你管，bug描述的是燈光。

QA不相信你，發出一組電子郵件，詢問bug是否包含百葉窗拉下的問題。

你很是等待了一會，郵箱又一次響起了。

“從理論上說，”他們問，“如果光太亮或太暗的話，在26樓會議室開會的人能自由拉上或拉下百葉窗嗎？”

是的，他們可以，你回復。

“任何一個普通人都能做到嗎？他們就不需要你做了嗎？“

是的，任何普通人。不，他們不會需要你。任何人都可以做到這一點。

“太好了。那么，燈光問題暫時到此為止。我會安排如何處理百葉窗的會議。“

bug被關閉了。現在，CEO，可能從所有關于26樓會議室的討論中感覺到了什么，希望在那里開會。你收到了幾封希望開燈的驚慌失措的郵件。

你去了地下室，連上電線，并返回辦公桌。你的收件箱多了32個新的消息。

“出問題了，燈還是熄滅的!”

“有個問題，沒有燈光!”

“你收到我們發的郵件了嗎？“

等等等等。

第32封郵件說道:“沒事，燈亮了。”

這個(指32封郵件)過程，或多或少地，在開關燈時反復發生。

如果要說有什么好消息的話，那就是在會議結束后，大家甚至都忘記了26樓有個會議室，你也不需要對它做任何新的處理。