কনটেক্সট সুইচিং-এর আসল খরচ: ৫০ লাখ GitHub PR আমাদের কী বলছে
আমরা ৫০ লাখেরও বেশি PR-এর ডেটা একত্র করে ডেভেলপারদের জন্য কনটেক্সট সুইচিং-এর আসল খরচ মেপেছি – আর সেটা তোমার ধারণার জায়গায় নেই।
By Ellis Keane · 2026-03-29
বেশিরভাগ আর্টিকেলে যে কনটেক্সট সুইচিং খরচ কোট করা হয় – ইন্টারাপশনের পর আবার ফোকাসে ফিরতে ২৩ মিনিট, UC Irvine-এ Gloria Mark-এর গবেষণা থেকে – সেটা বাস্তব স্টাডির বাস্তব ফল। কিন্তু এটা ২০০৮ সালে সাধারণ নলেজ ওয়ার্কারদের মেপেছিল, সফটওয়্যার ইঞ্জিনিয়ারদের নয়। আর যে অসংখ্য ব্লগপোস্ট ২৩ মিনিটকে অনুমানভিত্তিক দৈনিক ইন্টারাপশনের সংখ্যায় গুণ করে বছরে ভয়ের ডলার অঙ্ক বের করে (সাথে অবশ্যই মাথায় হাত দিয়ে বসে থাকা কারও স্টক ফটো), তারা আসলে মূল গবেষণার উদ্দেশ্যের বাইরের কিছু করছে।
এই প্রশ্নে আমার ব্যক্তিগত stake আছে। আগের এক কোম্পানিতে আমি – বাড়িয়ে বলছি না – কিছু দিনে ৮০ থেকে ১০০ শতাংশ সময় শুধু মানব রাউটার হয়ে কাটিয়েছি। কোড লেখা না, রিভিউও না। মানুষ আর টুলের মধ্যে তথ্য রাউট করেছি, কারণ কোনো একক সিস্টেম সবগুলোকে জোড়েনি। সেই অভিজ্ঞতাই আংশিকভাবে কেন আমরা Sugarbug বানিয়েছি, কিন্তু এটাই কারণ যে প্রচলিত কনটেক্সট সুইচিং কস্ট ক্যালকুলেটর নিয়ে আমি সন্দিহান। এগুলো ইন্টারাপশন মাপে। এগুলো সেই দিনগুলো মাপে না, যেদিন তুমি যেটা করতে বসেছিলে সেখানে পৌঁছানোই হয় না।
তাই আমরা জানতে চেয়েছিলাম, ইঞ্জিনিয়ারিং কাজে কনটেক্সট সুইচিং আসলে কত খরচ করায় – বিমূর্ত ডেভেলপার প্রোডাক্টিভিটি ভাষায় নয়, বরং টিম প্রতিদিন যে আর্টিফ্যাক্ট তৈরি করে সেটা দিয়ে: pull request। আমরা হাজার হাজার ওপেন-সোর্স প্রজেক্টে ৫০ লাখেরও বেশি PR কভার করা তিনটি বড় গবেষণার ফলাফল একত্র করেছি, এবং দেখেছি pull request review time আসলে কী চালায়।
মূল ফলাফল: সবচেয়ে ব্যয়বহুল কনটেক্সট সুইচ সেই Slack notification না যেটা তোমার flow ভাঙে। বরং সেটা সেই pull request, যা একদিন review queue-তে পড়ে থাকে, এবং প্রশ্ন এলে লেখককে আবার পুরো mental model নতুন করে গড়তে বাধ্য করে।
আমরা যেসব Dataset ব্যবহার করেছি
আমরা কাস্টম scraper বানিয়ে আলাদা করে ১০,০০০ PR বিশ্লেষণ করিনি। আমরা দুটি peer-reviewed study আর একটি বড় industry dataset থেকে ফলাফল একত্র করেছি, তারপর একটার সিদ্ধান্ত আরেকটার সাথে cross-check করেছি।
stat: "3.35M" headline: "Zhang et al. কর্তৃক বিশ্লেষিত pull request" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
প্রধান তিনটি dataset:
- Zhang et al. (2022), peer-reviewed: ১১,২৩০টি প্রজেক্টে ৩,৩৪৭,৯৩৭টি closed PR। PR review delay কী চালায় তা বের করতে mixed-effects linear regression ব্যবহার করা হয়েছে। Empirical Software Engineering-এ প্রকাশিত।
- Adadot (2023), industry dataset: ~৩০,০০০ ডেভেলপার থেকে ৩,০০,০০০+ merged PR। Peer-reviewed নয়, কিন্তু sample বড় এবং methodology (Kendall tau correlation) স্বচ্ছ। ফোকাস ছিল PR size বনাম lead time।
- Multi-reviewing study (2019), peer-reviewed: ৭৬০টি GitHub প্রজেক্টে ১,৮৩৬,২৮০টি PR। Information and Software Technology-এ প্রকাশিত। Concurrent review আচরণ পরীক্ষা করেছে – যা code review-এ কনটেক্সট সুইচিং-এর সরাসরি proxy।
এগুলোকে আমরা 2024 DORA State of DevOps Report এবং Atlassian-এর 2024 Developer Experience Report-এর সাথে cross-reference করেছি (এখানে ২,১০০+ ডেভেলপারের কনটেক্সট সুইচিং, ডেভেলপার প্রোডাক্টিভিটি, আর মানবিক দিক নিয়ে সার্ভে আছে)।
আসল কিলার হলো Queue
Zhang et al. দেখিয়েছে, একটি PR প্রথম response পেতে যত সময় লাগে – প্রথম comment, প্রথম review, প্রথম যেকোনো প্রতিক্রিয়া – সেটাই PR-এর মোট lifetime variance-এর ৫৮.৭% ব্যাখ্যা করে। Dataset-এ এটাই সবচেয়ে শক্তিশালী predictor – PR size, code complexity, বা file change count-এর থেকেও এগিয়ে! তুলনাই চলে না।
Code review-এ কনটেক্সট সুইচিং-এর সবচেয়ে বড় খরচ সুইচ নিজে নয় – বরং সেই queue, যা তৈরি হয় যখন সবাই অন্য কাজের মাঝে বারবার সুইচ করতে ব্যস্ত।
বাস্তবে এটা কী বোঝায় ভাবো। একজন ইঞ্জিনিয়ার সকাল ১০টায় PR খুলল। নির্ধারিত reviewer তখন নিজের feature branch-এ ডুবে আছে, অথবা মিটিংয়ে, অথবা Slack message triage করছে (সত্যি বলতে, সম্ভবত ধারাবাহিকভাবে তিনটাতেই)। PR পড়ে থাকল। বিকেল ৩টায় কেউ ধরার সময় author পুরো অন্য কিছুর মধ্যে চলে গেছে। এখন reviewer-এর প্রশ্ন আছে, মানে author-কে পাঁচ ঘণ্টা আগে লেখা কোডে আবার কনটেক্সট সুইচ করে mental model rebuild করে উত্তর দিতে হবে। সেই উত্তর বিকেল ৪:৩০-এ এল, কিন্তু reviewer বাড়ি চলে গেছে।
PR আরও একদিন বয়স বাড়াল।
ডেটা বলছে এটা discipline problem-এর চেয়ে queueing problem বেশি – আর এই queue-এর কনটেক্সট সুইচিং খরচ এমনভাবে compound হয়, যা interruption calculator পুরোপুরি মিস করে।
ছোট PR তোমাকে বাঁচাবে না
এটা আগেও শুনেছ: ছোট PR দ্রুত review হয়, তাই PR ছোট রাখো। একদম ভুল না, তবে effect size সত্যিই তোমার প্রত্যাশার চেয়ে ছোট।
Adadot-এর ৩,০০,০০০+ PR বিশ্লেষণে PR size আর lead time-এর মধ্যে Kendall tau correlation ছিল মাত্র 0.06 – দুর্বল সম্পর্ক, যদিও aggregate figure-এর confidence interval তারা রিপোর্ট করেনি। ১০০ লাইনের নিচের PR এক সপ্তাহের মধ্যে শেষ হওয়ার সম্ভাবনা প্রায় ৮০% – শুনতে দারুণ, যতক্ষণ না তুমি বুঝতে পারো কারও review queue-তে ছয় দিন পড়ে থাকা PR-এর completion rate-ও একই!
stat: "0.06" headline: "PR size আর lead time-এর মধ্যে correlation" source: "Adadot-এর ~৩০,০০০ ডেভেলপার থেকে ৩,০০,০০০+ PR বিশ্লেষণ (2023)"
আরও ইন্টারেস্টিং ফলাফল: এই correlation সংস্থা ভেদে ভীষণ ওঠানামা করেছে, 0.1 থেকে প্রায় 0.7 পর্যন্ত। মানে PR size নিজে bottleneck না – PR-কে ঘিরে review culture আর process-ই আসল। যেসব টিমের review cadence শক্তিশালী, তারা বড় PR-ও দক্ষভাবে সামলাতে পারে। যেসব টিমে review পরের কথা, তারা যেকোনো সাইজের PR-তেই হিমশিম খায়।
SmartBear/Cisco code review study-এর ৪০০ লাইনের threshold এখনও ভালো heuristic হিসেবে টেকে – Adadot-এর ডেটাতেও ওই রেঞ্জের পর review engagement কমতে দেখা গেছে। কিন্তু review cadence না ঠিক করে শুধু ছোট PR-এর জন্য optimize করা মানে (আর এটা আমি সত্যিই স্নেহ নিয়ে বলছি, যারা চেষ্টা করেছ সব engineering manager-দের জন্য) ডেকচেয়ার এদিক-ওদিক করা।
সবাই একই সময়ে সবকিছু Review করছে
Multi-reviewing study-তে দেখা গেছে ৬২% pull request-এ এমন ডেভেলপার জড়িত, যারা একই সাথে একাধিক PR review করছে। আরও গুরুত্বপূর্ণ, তারা statistically significant correlation পেয়েছে: reviewer প্রতি concurrent review যত বেশি, PR resolution latency তত বেশি।
৬২% pull request-এ ডেভেলপাররা একই সাথে একাধিক PR review করে – আর multi-reviewing-এর সাথে দীর্ঘতর resolution time-এর সরাসরি সম্পর্ক আছে। attribution: Multi-reviewing pull-requests study, ৭৬০ প্রজেক্টে 1.8M PR
মেকানিজমটা intuitive (স্টাডি observational হওয়ায় causation-এর দিক নিশ্চিত করে না)। একজন reviewer PR #1 ধরল, diff পড়ল, কোড কী করতে চাইছে তার mental model বানাতে শুরু করল। এমন সময় notification এল – PR #2 review লাগবে কারণ deploy আটকে আছে। Reviewer সুইচ করল। PR #1-এ ফিরে এসে আবার অর্ধেক diff পড়তে হলো, কারণ mental model ক্ষয় হয়ে গেছে।
এটা যদি আটজন ইঞ্জিনিয়ারের টিমে scale করো, যেখানে প্রত্যেকের দুই-তিনটা PR খোলা আর প্রত্যেকে দুই-তিন সহকর্মীর জন্য review করছে, তাহলে coordination overhead নিজে থেকেই ব্যাখ্যা হয়ে যায়। আলাদাভাবে, 2024 DORA Report বলছে "high performer" cluster ৩১% থেকে ২২%-এ নেমেছে আর low-performer cluster ১৭% থেকে ২৫%-এ উঠেছে। DORA PR review concurrency-কে আলাদা factor হিসেবে isolate করেনি, কিন্তু coordination overhead বাড়া সেই পরিবর্তনের একটি সম্ভাব্য কারণ।
কনটেক্সট সুইচিং কস্ট অনুমানগুলো কোথায় ভুল করে
কনটেক্সট সুইচিং কস্ট আর্টিকেলে যে "$50K per developer per year" ফিগারটা ঘুরে বেড়ায়, সেটা নিয়ে সরাসরি বলি। বেশিরভাগ estimate-এর পদ্ধতি হলো: ২৩ মিনিট refocus time নাও, অনুমান করা দৈনিক interruption (সাধারণত ৬ থেকে ১৫, লেখক কতটা নাটকীয় হতে চাইছে তার ওপর নির্ভর করে) দিয়ে গুণ করো, ঘণ্টাপ্রতি developer rate দিয়ে গুণ করো, তারপর annualise করো।
সমস্যা অঙ্কে না। সমস্যা হলো এটা সব কনটেক্সট সুইচকে সমান ধরে। Deep coding থেকে Slack message-এ যাওয়া, যেখানে জিজ্ঞেস করা হচ্ছে টিম লাঞ্চ কোথায় হবে – এটা কনটেক্সট সুইচ। একটা PR review থেকে পুরো অন্য codebase-এর আরেকটা PR review-এ যাওয়া – এটাও কনটেক্সট সুইচ। কিন্তু cognitive cost মোটেও তুলনীয় না, আর একটাই hourly rate-এ সব flatten করলে আসল ক্ষতি কোথায় হয় সেটা আড়াল হয়ে যায়।
কংক্রিটভাবে বলি: আমার আগের চাকরিতে একটি সাধারণ দিনে Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster, আর অগণিত Telegram ও Signal channel-এর মধ্যে সুইচ করতে হতো – নিশ্চিতভাবে আরও কয়েকটা বাদ পড়ছে। এখন আমি হাতে গোনা কয়েকটা ব্যবহার করি (Signal, Obsidian, Figma, GitHub, email, calendars)। প্রতি সুইচের খরচ বদলায়নি। যা বদলেছে তা হলো কতগুলো context attention-এর queue-তে দাঁড়িয়ে থাকে – আর তার মধ্যে কোনগুলো আসলে গুরুত্বপূর্ণ।
PR ডেটা বলছে ব্যয়বহুল সুইচ হলো যেগুলো queue তৈরি করে, flow ভাঙে যেগুলো সেগুলো নয়। একজন ডেভেলপার PR review-এর ping পেয়ে সঙ্গে সঙ্গে (মিনিটের মধ্যে) ৫০ লাইনের quick review করে ফেলল – এটা ছোট interruption, return বড়। আরেকজন একই review request-কে আরও চারটার সাথে queue-তে রেখে কাল দেখল – reviewer-এর interruption সময়ে লম্বা হলেও author আর টিমের জন্য খরচ অনেক বড় হয়।
কস্ট ক্যালকুলেটর যা মাপে
- ব্যক্তিগত interruption – কার flow কতবার ভাঙে
- Refocus time – আগের টাস্কে ফিরতে কত সময় লাগে
- Hourly rate multiplication – বছরে বড় ভয়ঙ্কর অঙ্ক
PR ডেটা আসলে যা দেখায়
- Queue formation – প্রথম response-এর জন্য PR অপেক্ষায়
- Review concurrency – reviewer-রা একাধিক PR জাগল করছে
- Cascade delays – reviewer delay থেকে author-এর কনটেক্সট সুইচ compound হওয়া
তোমার টিমের জন্য এর মানে কী
তোমার টিমে ডেভেলপারদের কনটেক্সট সুইচিং খরচ কমাতে চাইলে বাস্তব উত্তরটা নিরস – সম্ভবত তাই এটা নিয়ে বেশি লেখা হয় না। এটা কোনো টুল না। এটা certification-সহ কোনো process framework না। এটা review cadence। (জানি, জানি। review cadence উন্নত করে কেউ কখনও promote হয়নি।)
LinearB-এর 2025 engineering benchmark, ৩,০০০ সংস্থায় ৬.১ মিলিয়ন PR থেকে নেওয়া, দেখিয়েছে elite cycle time (২.৫ দিনের নিচে) অর্জনকারী টিমগুলোর একটাই সাধারণ বৈশিষ্ট্য ছিল: তারা দ্রুত PR review করত। কম PR ছিল বলে না, বা PR ছোট ছিল বলে না (যদিও প্রায়ই ছিল), বরং ঘণ্টার মধ্যে review request-এ সাড়া দেওয়া ছিল টিমের norm, afterthought না।
যদি বলতে হয়, Ben আর আমি – দুজনের টিম – first PR response-এ ঘণ্টা নয়, মিনিট গড় করি। এটা discipline নিয়ে flex না (আমরা তা নই)। এটা টিম agreement: review request-ই একমাত্র notification যেটা queue-তে রাখা যাবে না। CI actions আর automated tests mechanical check সামলায়, ফলে human review – যেটায় আসল context লাগে – ছোট হয় আর সঙ্গে সঙ্গে হয়। Agreement আগে এসেছে। টুলিং শুধু সেটাকে টেকসই করেছে।
ব্যবহারিকভাবে এর মানে:
- শুধু cycle time না, time-to-first-response মাপো। DORA metrics ট্র্যাক করলে এটাও যোগ করো। এটা PR throughput-এর সবচেয়ে শক্তিশালী predictor (lifetime variance-এর ৫৮.৭% ব্যাখ্যা করে, Zhang et al. অনুযায়ী)।
- Review concurrency সীমিত করো। কোনো reviewer-এর তিনটা pending review request থাকলে চতুর্থটাতে ভালো review হবে না। Multi-reviewing ডেটায় concurrency আর latency-র মধ্যে স্পষ্ট সম্পর্ক দেখা গেছে। দুটি concurrent review-এর WIP limit দিয়ে শুরু করো আর প্রভাব পর্যবেক্ষণ করো।
- PR size-কে আলাদাভাবে optimize করা বন্ধ করো। ছোট PR ভালো, কিন্তু আসলে review করে এমন টিমের বিকল্প না। দিনে বিশটা ৫০ লাইনের PR বানিয়ে ৪৮ ঘণ্টার review backlog রাখা টিমের অবস্থা, দিনে পাঁচটা ২০০ লাইনের PR বানিয়ে same-day review করা টিমের চেয়ে খারাপ।
- মেনে নাও, review-ও আসল কাজ। Atlassian-এর ২০২৪ সার্ভেতে দেখা গেছে ৬৯% ডেভেলপার অদক্ষতায় সাপ্তাহিক ৮+ ঘণ্টা হারায়। Review সেই অদক্ষতার একটা হতে হবে না – কিন্তু শুধু তখনই, যদি এটাকে first-class engineering activity হিসেবে দেখা হয়, "আসল" কাজে interruption হিসেবে না।
আর একটা কথা, productivity-tool space-এ কেউই (আমরাও, ন্যায্যভাবে বললে) জোরে বলতে চায় না: ইঞ্জিনিয়ারিং টিমে কনটেক্সট সুইচিং খরচ কমাতে সবচেয়ে কার্যকর হস্তক্ষেপ টুল না। এটা হলো PR কখন review হবে সেটা নিয়ে টিম agreement। তোমার টিমের implicit norm যদি হয় "ফাঁক পেলে review দেখব," তাহলে কোনো টুলই সেই queuing cascade ঠেকাতে পারবে না, যেটা PR ডেটা দেখাচ্ছে।
টুল সাহায্য করে – চারটা browser tab না খুলে PR-এর full context দেখা গেলে প্রতি সুইচে cognitive load কমে, আর কোন review অন্যদের কাজ block করছে সেটা surface হলে prioritise করতে সুবিধা হয়। কিন্তু core lever হলো agreement, আর agreement ফ্রি। ২৩ মিনিটের ক্যালকুলেটর লাগবে না।
সবচেয়ে ব্যয়বহুল কনটেক্সট সুইচ সেই notification না যেটা flow ভাঙে। এটা সেই review request, যা একদিন queue-তে পড়ে থেকে প্রশ্ন এলে author-কে আবার মানসিক context rebuild করতে বাধ্য করে।
তোমার inbox-এ সিগন্যাল ইন্টেলিজেন্স পৌঁছে দাও।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
Q: প্রতি ডেভেলপারের বছরে কনটেক্সট সুইচিং-এর খরচ কত? A: আনুমানিক হিসাব অনেক রকম, কিন্তু বেশিরভাগ আর্টিকেল যা বোঝায়, মূল গবেষণা ততটা গভীর নয়। UC Irvine-এ Gloria Mark-এর স্টাডিতে প্রতি ইন্টারাপশনে আবার ফোকাসে ফিরতে ২৩ মিনিট লাগে দেখা গেছে, আর Atlassian-এর ২০২৪ সালের ২,১০০+ ডেভেলপারের সার্ভেতে ৬৯% বলেছে অদক্ষতায় সাপ্তাহিক ৮+ ঘণ্টা হারায়। টাকার অঙ্কটা অনেকটাই নির্ভর করে স্যালারি অনুমান, ইন্টারাপশনের ফ্রিকোয়েন্সি, আর তুমি "switching" কীভাবে সংজ্ঞায়িত করছ তার ওপর – তাই আমরা PR ডেটায় ফোকাস করেছি।
Q: ইঞ্জিনিয়ারিং টিমের কনটেক্সট সুইচিং কমাতে Sugarbug কি সাহায্য করে? A: হ্যাঁ। Sugarbug, Linear, GitHub, Slack, আর Figma-এর মতো টুলকে একটাই নলেজ গ্রাফে যুক্ত করে, ফলে ইঞ্জিনিয়াররা একটা টাস্কের পুরো কনটেক্সট – প্রাসঙ্গিক PR, Slack আলোচনা, Figma কমেন্ট – চারটা ট্যাব না খুলেই দেখতে পারে। লক্ষ্য কম টুল নয়, কম সুইচ।
Q: রিভিউ দেরি কমাতে আদর্শ pull request সাইজ কত? A: Adadot-এর ৩,০০,০০০+ PR বিশ্লেষণের গবেষণায় দেখা গেছে, ১০০ লাইনের কম কোডের PR এক সপ্তাহের মধ্যে শেষ হওয়ার সম্ভাবনা প্রায় ৮০%। ৪০০ লাইনের ওপরে গেলে রিভিউর গুণমান আর সম্পন্ন হওয়ার গতি – দুটোই কমে। ছোট PR রিভিউয়ারের কনটেক্সট সুইচিং-এর চাপও কমায়।
Q: Sugarbug কি GitHub pull request-এর সাথে ইন্টিগ্রেট করে? A: হ্যাঁ। Sugarbug GitHub activity – PR, কমেন্ট, রিভিউ, আর স্ট্যাটাস পরিবর্তন – সংগ্রহ করে এবং তোমার অন্য টুলের সম্পর্কিত সিগন্যালের সাথে লিংক করে। যদি কোনো Linear issue থেকে PR তৈরি হয়, আর Slack থ্রেডে অ্যাপ্রোচ নিয়ে আলোচনা হয়, Sugarbug স্বয়ংক্রিয়ভাবে তিনটাকেই যুক্ত করে।
Q: "আবার ফোকাসে ফিরতে ২৩ মিনিট" পরিসংখ্যানটা কোথা থেকে এসেছে? A: এটা এসেছে UC Irvine-এ Gloria Mark-এর গবেষণা থেকে, "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008) প্রকাশনায়। স্টাডিতে দেখা গেছে, ইন্টারাপশনের পর কর্মীরা গড়ে ২৩ মিনিট ১৫ সেকেন্ডে তাদের মূল কাজে ফিরে যায়। মনে রাখা জরুরি, স্টাডিটি নির্দিষ্টভাবে সফটওয়্যার ইঞ্জিনিয়ার নয়, সাধারণ নলেজ ওয়ার্কারদের পর্যবেক্ষণ করেছিল।