آیا در شرکت نرم افزاری خوبی کار می کنید؟

این مقاله برای این هدف نوشته شده است که به شما برآوردی از شرکتی که در آن کار می کنید یا مدیریتش می کنید ؛ به دست آورید.خواندن آن تنها پنج دقیقه از وقت شما را می گیرد ولی ممکن است بعدها باعث صرفه جویی عمده ای در زمان و هزینه هایی که می کنید بشود.

ویژگی شسته و رفته تست جوئل در این است كه به راحتی میتوان به هر سؤال جواب بله یا نه داد. شما مجبور نیستید كه تعداد خطهای كد در روز یا تعداد متوسط اشكال در هر قسمت را بشمارید. نقطه ضعف تست جوئل در این است كه نباید از آن برای اطمینان از صحت نرم افزار نیروگاه اتمی خود استفاده كنید!

امتیاز 12 عالی، 11 قابل قبول و 10 یا پایینتر نشان دهنده مشكلات جدی است. واقعیت  این است كه بیشتر موسسات نرم افزاری با امتیاز 2 یا 3 در حال فعالیت هستند و به كمك جدی نیاز دارند، چرا كه شركتهایی مانند Microsoft تمام مدت با امتیاز 12 اداره می شوند.

البته، اینها تنها موارد مشخص كننده موفقیت یا شكست نیستند: مثلاً ، اگر شما تیم ماهری دارید كه بر روی محصولی كه هیچ كس آن را نمی خواهد كار میكند، خوب، مردم باز هم آن محصول را نخواهند خواست. از طرفی، تیم غیر عادی را میتوان تصور كرد كه بدون انجام هیچ كدام از این كارها، نرم افزار فوق العاده ای تولید كند و دنیا را تغییر دهد. اما اگر همه شرایط برابر باشند، با رعایت این 12 نكته، تیم منضبطی خواهید داشت كه همیشه موفق به تحویل پروژه هایش میشود آن هم به موقع ! چیزی که در ایران کم دیده می شود.

 آیا از سیستم كنترل سورس استفاده می کنید؟

من هم از پكیجهای تجاری كنترل سورس استفاده كردم، و هم از CVS كه مجانی است ؛ و بگذارید به شما بگویم كه CVS مناسب است. اما اگر سورس كنترل ندارید، فشار زیادی را برای اینكه برنامه نویسانتان بتوانند با هم كار كنند متحمل میشوید: برنامه نویسها راهی برای اینكه بدانند بقیه چه كرده اند، ندارند. و اشتباهات، به راحتی قابل بازگشت نیستند. و در آخر اینكه چون كد برنامه بر روی دستگاه تمام برنامه نویسان check out میشود، تا بحال نشنیده ام كه پروژه های دارای سورس كنترل ، كد زیادی را به اشتباه از دست دهند.سیستم های SVN  هم برای این کار وجود دارند که علاوه بر راه های کنترل سورس ؛ برای ایجاد ورژن برای هر سند الکترونیکی می تواند به کار رود.من خودم از Source Safe  استفاده کرده ام و به نظر من در حد و اندازه های پروژه های معمولی و حتی کمی بزرگ ؛ خیلی پیچیده و گیر است.در حال حاضر از Tortoise SVN استفاده می کنم و ازش راضی هم هستم.البته باید سعی کنید که چند نفری روی یک قسمت کار نکنید و اگر کسی می خواهد که این کار را انجام دهد باید آن سند را قفل کند.

آیا میتوانید در یك مرحله، برنامه تان را build كنید؟

منظورم این است: برای ایجاد نسخه قابل تحویل به مشتری از آخرین سورس، چند مرحله وجود دارد؟ در تیمهای خوب، یك اسكریپت وجود دارد كه با اجرای آن، یك check out كامل صورت میگیرد، تمام كد كامپایل میشود، EXE ها ساخته میشوند (در تمامی نسخه ها، زبانها و #ifdef ها) ، پكیج قابل نصب تولید میشود و بالاخره در فرم رسانه نهایی (CD یا وبسایت یا ...) ایجاد میشود.

اگر این رویه بیشتر از یك مرحله داشته باشد، مستعد اشتباه است. و هر چقدر به زمان تحویل نزدیكتر میشوید، احتیاج به چرخه سریعتری برای تصحیح "آخرین" bug، و ساختن EXE نهایی دارید. اگر كامپایل كردن كد، اجرای سازنده installer و بقیه كارها بیست مرحله به طول انجامد، دست به اشتباهات احمقانه خواهید زد.

فقط به همین علت، آخرین شركتی كه در آن كار میكردم، از WISE به InstallShield تغییر كرد: لازم بود كه رویه ایجاد installer از روی یك script به صورت خودكار نیمه شبها توسط NT Scheduler اجرا شود و WISE چنین قابلیتی نداشت. (دوستان خوب ما در WISE به من اطمینان داده اند كه آخرین نسخه شان توانایی build های شبانه را دارد.)

آیا دارای build روزانه هستید؟

وقتی كه از كنترل سورس استفاده میكنید، گاهی پیش میآید كه یك برنامه نویس چیزی را check in میكند كه باعث شكستن build میشود. به عنوان مثال، یك برنامه نویس یك فایل سورس جدید اضافه كرده است و همه چیز روی دستگاه خودش درست كامپایل میشود، ولی یادشان میرود كه فایل را به مخزن كد (repository) اضافه كند. دستگاه خودش را هم قفل كرده و بی توجه و خوشحال به خانه میرود. حالا كسان دیگری نیز نمی تواند كار كنند. آنها هم به خانه میروند، البته غمگین.

شكستن بیلد آنقدر بد (و رایج) است كه درست كردن بیلد روزانه كمك میكند كه چنین موضوعی ناشناخته نماند. در تیمهای بزرگ، یك راه این كه مطمئن شوید كه چنین مشكلاتی در اولین فرصت برطرف شوند، این است كه بیلد روزانه را هر روز، هنگام ناهار انجام دهید. همه تمامی check in هایی را كه میتوانند قبل از رفتن به ناهار انجام میدهند. بیلد، زمانی كه همه برگشتند تمام شده است. اگر كه همه چیز درست است، كه خیلی خوب است! آخرین نسخه سورس توسط همه check out شده و كار ادامه پیدا میكند. اما اگر كه عمل بیلد با موفقیت روبرو نشده باشد، افراد با نسخه سالم قبلی به كار خود ادامه میدهند.

در تیم Excel، با قانونی داشتیم: هر كسی كه build را میشكست، به عنوان تنبیه، مسئولیت نگهداری از بیلدها را عهده دار میشد. این انگیزه خوبی بود هم برای جلوگیری از شكستن بیلد، و هم راه خوبی بود برای این كه همه (به صورت چرخشی) یاد بگیرند كه رویه چطور است.

 

آیا بانك اطلاعاتی از اشكالات (bugs) دارید؟

برایم مهم نیست كه در این مورد چه فكر میكنید. اما اگر حتی در یك تیم یك نفره مشغول تولید كد هستید و از بانك منظمی كه تمامی ایرادات برنامه را لیست كند استفاده نمیكنید، حتماً كد با كیفیت پایین تحویل خواهید داد. برنامه نویسان زیادی فكر میكنند كه میتوانند لیست اشكالات و باگها را در حافظه خود نگهدارند. چه مزخرفاتی! من در آن واحد بیشتر از دو یا سه باگ را نمیتوانم بخاطر بسپارم، و صبح روز بعد، یا با عجله ای كه زمان تحویل دارید، همه به فراموشی سپرده میشوند. قطعاً باید به صورت رسمی و مكتوب لیست اشكالات را نگهداری كنید.

بانك باگ میتواند پیچیده و یا ساده باشد. یك بانك باگ سودمند باید حداقل اطلاعات زیر را در مورد هر باگ نگه دارد :

• مراحل كامل برای باز تولید اشكال
• رفتاری كه انتظار آن میرود
• رفتار (ایراد داری) كه واقعاً رخ میدهد
• فردی كه رفع اشكال به او واگذار شده است
• آیا اشكال رفع شده است یا خیر

اگر پیچیدگی نرم افزار پیگیری باگها مانع از آن میشود كه چنین كاری را انجام دهید، یك جدول پنج ستونه (با فیلدهای ضروری فوق) بسازید و شروع به انجام این كار كنید.

آیا قبل از نوشتن كد جدید، به رفع اشكالات كنونی میپردازید؟

اولین نسخه Word تحت ویندوز، پروژه " نوحه مرگ " محسوب میشد كه نوشتن آن به درازا كشید، فرجه ها دایماً به سر میرسیدند؛ افراد تیم، ساعتهای مسخره آمیزی كار میكردند، و پروژه باز ... و باز ... و باز به تاخیر میافتاد. استرس باور نكردنی بود. وقتی بعد از چندین سال، بالاخره محصول لعنتی اش بیرون آمد، مایكروسافت كل تیم Word را برای استراحت به جنوب مكزیك فرستاد ؛ و خودش به كنكاش روحانی جدی دست زد.

مایكروسافت متوجه شد كه مدیران پروژه آنقدر بر حفظ " زمان بندی " (schedule) اصرار داشتند كه برنامه نویسان مجبور به كد نویسی با عجله شده بودند، و بسیار بد كد می نوشتند - به این علت كه فاز bug fix جز زمانبندی رسمی نبود. تلاشی برای پایین نگهداشتن تعداد خطاها وجود نداشت. حتی برعكس، روایت شده كه یكی از برنامه نویسان كه مسؤول نوشتن كد محاسبه ارتفاع خطوط متن بود، فقط نوشت: return 12; و بعد هم منتظر نشست تا در گزارش باگها بیاید كه تابعش ، همیشه درست كار نمیكند. زمانبندی پروژه صرفاً تبدیل شده بود به لیستی از باگهایی كه باید تولید میشد! بعدها، از این اتفاق با عنوان " متدولوژی عیوب نامحدود " (infinite defects methodology) یاد شد.

برای حل این معضل، مایكروسافت " متودولوژی كمترین عیوب" (zero defects methodology) را به صورت فراگیری اتخاذ كرد. بسیاری از برنامه نویسان داخل شركت خندیدند - چون به نظر میرسید مدیریت به این نتیجه رسیده بود كه با یك حكم سازمانی تعداد باگها را كم كند. اما در واقع، معنی " كمترین عیوب" در این است كه در هر لحظه، بالاترین اولویت در رفع باگهاست، نه نوشتن كد جدید. اما چرا؟

به صورت كلی، هر چه برای تصحیح یك اشكال بیشتر معطل كنید، هزینه تصحیح آن (از لحاظ وقت و پول) بیشتر خواهد بود.

به عنوان مثال، وقتی كه اشتباه تایپی انجام میدهید و كامپایلر آن را catch میكند، تصحیح آن كار اساساً ساده ایست. به همین ترتیب، بار اولی كه كدتان را اجرا میكنید و در آن اشكالی میبینید، میتوانید بلافاصله آن را تصحیح كنید، چون همه كد در ذهنتان وجود دارد.

اما اگر در كدی كه چند روز پیشتر آن را نوشته اید، ایرادی بیابید، یافتن محل دقیق آن مدتی طول خواهد كشید، البته وقتی كه كدتان را باز خوانی كنید همه چیز بالاخره یادتان میآید و در یك زمان قابل قبول مشكل رفع میشود.

اما بالاخره اگر در كدی كه چند ماه پیش آن را نوشته اید باگی پیدا شود، به احتمال زیاد چیزهای زیادی را در مورد آن كد به فراموشی سپرده اید و تصحیح آن بسیار سختتر است. ممكن است مشغول تصحیح باگ كد كسی شده باشید كه در آن لحظه برای مرخصی به جزایر دریای كارایب رفته باشد. در این صورت، تصحیح باگ به صورت یك علم در میآید : باید با درایت، وسواس، نظم و بدون هیچ تصوری از مدت زمانی كه یافتن راه حل طول میكشد، عمل كنید.

اگر در كدی كه تحویل دادهاید ایرادی بیابید، متحمل هزینه باز هم زیادتر برای اصلاح آن خواهید شد.

پس اولین دلیلی كه باید باگها را بلافاصله رفع كرد، كم كردن زمان لازم برای این كار است. دلیل دیگری هم وجود دارد: پیشبینی مدت زمان لازم برای نوشتن كد جدید، راحتتر از پیشبینی زمان لازم برای رفع یك باگ است. مثلاً اگر از شما بپرسم كه چقدر زمان برای نوشتن كدی برای مرتب سازی یك فهرست لازم دارید، جواب نسبتاً دقیق میتوانید به من بدهید. اما اگر از شما بپرسم در جایی كه IE 5.5 نصب شده باشد و كدتان دیگر كار نمیكند چقدر زمان لازم دارید تا باگ مربوطه را رفع كنید، بعید میدانم كه حتی بتوانید حدسی بزنید! چرا كه (بنابر تعریف صورت مساله) نمیدانید كه منشأ مشكل كجاست. ممكن است سه روز وقتتان را بگیرد، ممكن هم هست كه فقط دو دقیقه.

به بیان دیگر، اگر در برنامه زمانبندیتان تعداد زیادی باگی كه باید رفع شوند، وجود داشته باشد، زمانبندیتان غیر قابل اعتماد است. اما اگر تمامی ایرادهای شناخته شده را تصحیح كرده اید و فقط كد جدید مانده، زمانبندیتان به طرز حیرت آوری دقیقتر خواهد بود.

نكته خوب دیگری هم كه صفر نگهداشتن تعداد باگها در هر زمان دارد، عكس العمل سریعتر در برابر رقباست. بعضی برنامه نویسان این قضیه را به " آماده تحویل بودن" محصول در تمام لحظات، تعبیر میكنند. اگر رقیب شما قابلیت خفنی!! عرضه كرد، شما هم میتوانید آن امكان را فوراً به برنامه تان اضافه كنید و آن را تحویل دهید، بدون این كه مجبور به تصحیح تعداد زیادی ایراد انباشته شده باشید.

آیا برنامه زمانبندیتان به روز است؟

میرسیم به بحث شیرین زمانبندی. اگر كدتان برای شركتتان اهمیتی داشته باشد، پس حتماً به دلایل زیادی برای شركتتان زمان اتمامش هم مهم هست. برنامه نویسان به صورت خیلی مفتضحی در زمینه زمانبندی، ترشرو هستند : سر قسمت مدیریت و بازاریابی فریاد میكشند " كار وقتی تمام میشود كه تمام شده باشد ! "

متاسفانه، این اصلاً به درد نمیخورد. برنامه ریزی های زیادی باید قبل از تحویل نهایی كد انجام گیرد : جلسات دمو ؛ تولید کاتالوگ ؛ ایجاد صفحه در وب سایت ؛ نمایشگاهها، تبلیغات و غیره. و تنها راه انجام این كارها، داشتن برنامه زمان بندی و به روز نگهداشتن آن است.

فایده حیاتی دیگر داشتن برنامه زمانبندی در این است كه مجبورتان میكند تصمیم بگیرید چه قابلیتهایی را میخواهید در برنامه بگنجانید و این كه امكانات با اولیت پایینتر را حذف كنید، و گرفتار بیماری featuritis نشوید. (featuritis / scope creep / creeping featurism، و یا گرایش به ویژگیهای نو، بیماری طراحان و برنامه نویسان است ؛ طراحان  یا برنامه نویسان مبتلا به این بیماری دوست دارند كه به سیستم پیچیدهای بدون برنامه ریزی كافی امكانات و ویژگیهای نو اضافه كنند؛ و در واقع آن را - به صورت غیر اصولی - فقط پیچیده تر كنند!)

من خودم در شرکتی کار می کردم که یک پروژه که قرار بود 4 ماهه نوشته شود ؛ 3 سال کشید و در انتها نیز Out Source  شد و شرکت دیگری برنامه نویسی آن را به عهده گرفت.این پروژه پروژه حیاتی شرکت و دلیل به وجود آمدن شرکت بود ولی به دلیل نداشتن برنامه ریزی و مدیریت اشتباه در روند اجرا ؛ عملا شکست خورد.

نگهداشتن schedule (برنامه زمانبندی)، الزاماً سخت نیست.

آیا دارای لیست مشخصات هستید؟

نوشتن لیست مشخصات (specifications) درست مثل استفاده از نخ دندان است: همه قبول دارند كه كار خوبی است ولی هیچ كس حوصله اش را ندارد.

دقیقاً مطمئن نیستم كه چرا ؛ احتمالاً به این علت است كه برنامه نویسان از نوشتن مستندات متنفرند. در نتیجه، تیمهایی كه همه اعضایش برنامه نویس هستند وقتی سراغ مسأله ای میروند، ترجیح میدهند كه راه حلشان به زبان كد باشد تا به صورت سند. ترجیح میدهند كه از اول شیرجه بزنند و كد بنویسند تا این كه ابتدا یك لیست مشخصات درست كنند.

در مرحله طراحی، اگر به معضلی بر بخورید، به سادگی با تغییر چند خط میتوانید آن را حل كنید. اما زمانی كه كد نوشته شده است، هزینه درست كردن معضلات بسیار گزاف است : هم از لحاظ عاطفی (چون مردم از دور انداختن كد خود متنفرند)، و هم از لحاظ زمانی، و به همین علت نوعی مقاومت در مقابل درست كردن معضل بوجود میآید. نرم افزاری كه از روی لیست مشخصات (specifications) تولید نشود معمولاً نتیجه اش طراحی بد و زمانبندی خارج از كنترل است. به نظر میرسد كه مشكل Netscape نیز همین بوده - چهار نسخه اول آن قدر شلم شوربا شد كه مدیریت به طرز احمقانه ای تصمیم گرفت همه كد آن را دور بیاندازد و از صفر شروع كند. سر Mozilla هم دوباره همین اشتباه را مرتكب شدند، كه محصول آن هیولایی خارج از كنترل است كه چند سال طول كشیده تا فقط به مرحله آلفا برسد.

تئوری مورد علاقه من این است كه اگر برنامه نویسان را به یك دوره متمركز نویسندگی بفرستید، یاد خواهند گرفت كه نویسندگان با ذوقی شوند. راه حل دیگر، استخدام مدیر برنامه (program manager) زبردستی است كه خود نوشته ها را تهیه كند. در هر دو حالت، باید قانون " هیچ كدی بدون مشخصات پذیرفته نیست " را به اجرا بگذارید.

چند سال پیش در شرکتی کار می کردم که قرار بود برنامه ای با تکنولوژی Tapi  برای آنها بنویسم.ابتدا قرار شد برای آزمایش قابلیتها و یادگرفتن نحوه کار با Tapi یک برنامه کوچک بنویسم و بعد در صورت به نتیجه رسیدن و مطمئن شدن از اینکه این کار قابل انجام است ؛ نرم افزاری برای این موضوع طراحی و پیاده سازی شود.به دلیل نبود هیچ گونه مستندی در این زمینه و عدم ثبت قابلیتهای مورد نیاز ؛ 3 ماه بعد مدیر عامل شرکت فکر می کرد که این همان برنامه نهایی است که به نتیجه رسیده و اکنون باید به بازار عرضه شود!

در نوشته چهار قسمتی من، هر چه كه در مورد نوشتن مشخصات لازم دارید را میتوانید بخوانید.

آیا برنامه نویسان شما محیط آرامی برای كار كردن دارند؟

این موضوع - كه با دادن فضای مناسب، ایجاد آرامش و محیط دنج (privacy) به كارمندان IT (یا اصطلاحاً knowledge workers) - بهروری افزایش می یابد ، به صورت گسترده ای مستند شده است. كتاب كلاسیك مدیریت نرم افزار، PeopleWare ، این موارد را بر میشمرد.

مشكل اینجاست: همه ما میدانیم كه نیروی كار فنی با قرار گرفتن در جریانی كه از آن به " در بحر موضوع رفتن " تعبیر میشود - بهتر كار میكنند ؛ این زمانی است كه تمركزشان كاملاً بر روی كارشان است و حواسشان كاملاً از محیط اطرافشان پرت شده است. احساس زمان را از دست میدهند و از طریق تمركز مطلق، چیزهای عالی ای خلق میكنند. نویسندگان، برنامه نویسان، دانشمندان، و حتی بازیكنان بسكتبال در مورد حالت " در بحر موضوع فرو رفتن " میتوانند برای شما توضیح دهند.

وارد شدن به این حالت كار ساده ای نیست. اگر اندازه گیری كنید، میبینید كه حدوداً 15 دقیقه طول میكشد تا به حداكثر كارایی خود برسید. بعضی مواقع، زمانهایی كه خسته هستید و یا به اندازه كافی برای آن روزتان خلاقیت به خرج دادهاید، دیگر نمیتوانید در بحر موضوع بروید و بقیه روز را به كارهای بیهوده، خواندن وب و چت كردن میگذرانید.

مشكل دیگر در اینجاست كه از دست دادن تمركز كار ساده ایست :سر و صدا، تماسهای تلفنی، ناهار را بیرون خوردن، آن پنج دقیقه ای كه برای نوشیدن قهوه تا كافی شاپ صرف رانندگی میكنید، و مخصوصا مزاحمت ها و سؤالهای همكاران، همگی تمركز را از بین می برند. اگر همكار شما از شما سؤالی بپرسد كه یك دقیقه كارتان را متوقف كند، ولی آنقدر حواستان را پرت كند كه نیم ساعتی طول بكشد تا به حالت سابق برگردید، بهره وری كلی تیمتان در خطر جدی قرار دارد. اگر در محیط شلوغی كار میكنید که اعضای بخش بازاریابی یا پشتیبانی در آنها  زیر گوش برنامه نویسان مشغول داد و بیداد هستند - بهروری شما سقوط بدی خواهد كرد.

در مورد برنامه نویسان (به نسبت بقیه knowledge workers و طیفهای دیگری كه نیازمند تمركز زیاد هستند)، قضیه سختتر است. بهره وری، به توانایی شعبده بازی با جزئیات زیادی در حافظه موقت بستگی دارد. هر نوع وقفه ای باعث بهم ریختن این جزئیات میشود. وقتی كارتان را از سر می گیرید، هیچ كدام از جزئیات (نظیر نام متغیرهای محلی یا این كه تا كجای پیاده سازی الگوریتم جستجویتان را انجام داده بودید) یادتان نخواهد آمد و مجبور به مراجعه به كار قبلتان هستید كه سرعتتان را میگیرد.

ریاضیات این مساله زیاد سخت نیست: فرض كنید (كه شواهد هم این فرض را تایید میكنند) كه اگر برای یك دقیقه هم یك برنامه نویس را متوقف كنید، پانزده دقیقه از بهره وریش كم می كنید. برای مثال، غضنفر و افشین(كه هر دو برنامه نویس هستند) را در دو پارتیشن كنار هم قرار میدهیم (در یك فضای كاملاً Dilbert ای). افشین ؛ نام تابع كپی رشته در یونیكد را به خاطر نمیآورد. میتواند جواب آن را جستجو كند - كه 30 ثانیه طول میكشد، و یا این كه از غضنفر بپرسد - كه 30 ثانیه طول خواهد كشید. خوب، چون غضنفر در كنارش نشسته است ترجیح میدهد كه از او بپرسد. حواس غضنفر پرت میشود و 15 دقیقه را از دست میدهد (برای این كه  افشین 15 ثانیه صرفه جویی كرده باشد.)

حالا اجازه دهید كه غضنفر و افشین را در دو اتاق (با در و دیوار) جدا بگذاریم. اكنون وقتی كه افشین اسم تابع را به خاطر نمی آورد، میتواند جواب آن را جستجو كند (كه همان 30 ثانیه طول میكشد) و یا این كه از غضنفر بپرسد كه 30 ثانیه طول میكشد و شامل از جای خود بلند شدن هم میشود (كه با توجه به وضعیت جسمی معمول برنامه نویسان و مسایل دیگر ، كار ساده ای نیست!). بنابر این ترجیح میدهد كه جوابش را جستجو كند. 30 ثانیه وقتش تلف میشود اما 15 دقیقه به نفع غضنفر است! وای!

آیا بهترین ابزارهایی را كه وجود دارد میخرید؟

نوشتن كد در یك زبان كامپایل شده از كارهایی است كه هنوز بر روی كامپیوترهای خروس نشان، نمیتوان با سرعت انجام داد. اگر فرآیند كامپایل، بیشتر از چند ثانیه طول میكشد، خرید جدیدترین و بهترین كامپیوتر در وقتتان صرفه جویی خواهد كرد. اگر كامپایل كردن حتی 15 ثانیه طول بكشد، برنامه نویسها حوصله شان سر میرود و میروند به سراغ خواندن سایت ......... ، كه آن هم تمام هوش و حواسشان را به خود خواهد برد و ساعتها بهره وری از بین می رود.

debug كردن كد GUI با یك مانیتور اگر غیر ممكن نباشد، بسیار سخت و دردناك است. اگر در حال نوشتن كد GUI هستید، داشتن دو مانیتور همه چیز را بسیار ساده خواهد كرد.
بیشتر برنامه نویسان باید یك زمانی فایلهای bitmap را (برای iconها و toolbarها) دستكاری كنند و اكثراً ویرایشگر مناسب برای این كار ندارند. استفاده از MS Paint برای این كار بیشتر شبیه یك شوخی است، كه البته غالب برنامه نویسها از همین روش استفاده میكنند.

در محل كار قبلی ام، admin شبكه دایماً برای من spam میفرستاد و غر میزد كه من بیشتر از 220 مگابایت فضای مجازم، روی سرور جا اشغال كرده ام. من روزی جواب دادم كه با توجه به قیمت هارد دیسك، هزینه فضای مورد استفاده كمتر از هزینه دستمال كاغذی من است و صرف كردن حتی ده دقیقه از وقتم برای كوچك كردن دایركتوری ام یك هدر دادن بهره وری است.

تیمهای تولید نرم افزار درجه یك، برنامه نویسان خود را شكنجه نمیكنند. حتی موضوعات جزیی اعصاب خرد كن ناشی از داشتن ابزار نامناسب، جمع میشود و برنامه نویسها را بد اخلاق و ناراحت میكند. یك برنامه نویس بد خلق، یك برنامه نویس با كارایی پایین است.

یك نكته دیگر هم اضافه كنم... برنامه نویسها را به راحتی میتوان با رشوه دادن - بوسیله جدیدترین و با حال ترین وسایل - تطمیع كرد. این برایتان خیلی ارزانتر از دادن حقوق مكفی تمام می شود!

به یاد دارم که چند سال پیش در شرکتی کار می کردم که همیشه حقوق ها را دیرتر از حد معمول می داد. من همیشه آخر ماه به دفتر مدیر عامل می رفتم و یک ساعت از وقت هردوی ما به این موضوع اختصاص می یافت که چرا حقوق من دیر شده است.هنوز هم جمله آن مدیر در گوشم هست که به من می گفت " کار کردن خاک خوردن دارد " و من هم می گفتم : "اگر می خواستم خاک بخورم ؛ برای خودم و به صورت پروژه ای کار می کردم.علت کار کردن من در شرکت شما این است که می خواهم سر زمان مقرر ؛ درآمد خود را داشته باشم".همیشه هم صحبتها با این جملات خاتمه می یافت که "ما که فقط همین ماه  حقوق را کمی دیر دادیم و شما همیشه حقوق خود را سر وقت دریافت می کنید!" و من هم می گفتم "من این جمله را چند ماه است که می شنوم"

حالا که به آن روزها فکر می کنم می بینم که من و تمامی کارکنان شرکت از چند روز مانده به آخر ماه مدام به زمان دادن حقوق فکر می کردیم و چون سر وقت داده نمی شد این فکر کردن 10 الی 15 روز طول می کشید که به صورت توانی ؛ تمام انرژی ما صرف این موضوع می شد.حتی کارکنان سر این موضوع با هم بحث می کردند و طنز می ساختند.در صورتی که مدیر عامل می توانست با پرداخت به موقع حقوق ؛ بهره وری را در آن شرکت بالا ببرد.البته من هنوز هم از اوضاع شرکت خبر دارم و می دانم که به جز این قضیه ؛ چند قضیه کوچک بهبود یافته اند.

آیا بخش تست شما جداست؟

اگر در تیم شما افرادی كه وقتشان اختصاصاً برای تست كردن باشد - حداقل یك نفر برای هر دو یا سه برنامه نویس - وجود نداشته باشد، شما یا محصولات باگ دار تحویل خواهید داد؛ و یا این كه با پرداخت حقوق قسمت تست نرم افزار به خود برنامه نویسان، پولتان را هدر میدهید.  چون برنامه نویسان بیشتر از پشتیبانان ؛ حقوق می گیرند.خساست در زمینه افراد جهت بخش تست، آن قدر صرفه جویی احمقانه ایست كه من واقعاً تعجب میكنم چرا اكثر مردم نمیفهمند. ضمنا برنامه نویس ها معمولا حالتهای بحرانی را در نظر نمی گیرند و با کاربر در تعامل نیستند و مشکلات کاربر را نمی دانند.نکته دیگری هم که در این وسط وجود دارد این است که برنامه نویسان معمولا  همه چیز را از یک روش و آن هم روشی که خودشان انجام می دهند ؛ آزمایش می کنند.بنابراین اگر می خواهید نرم افزاری را آزمایش کنید ؛ هیچ وقت این کار را به برنامه نویس آن واگذار نکنید.

آیا داوطلبان جدید در موقع مصاحبه، كد هم مینویسند؟

آیا شما حاضرید یك شعبده بازی را بدون این كه چند حقه برایتان اجرا كند، استخدام كنید؟ معلوم است كه نه. آیا برای عروسیتان، آشپزی كه غذایش را نچشیده باشید، استخدام میكنید؟ بعید میدانم. (مگر این كه خاله بزرگتان باشد و بترسید كه تا آخر عمر از شما به دل بگیرد و برنجد.)

با این وجود، هر روز، برنامه نویسهایی بخاطر داشتن resume جالب یا به این خاطر كه مصاحبه گر از گپ زدن با او لذت برده، و یا ...... استخدام می شوند. یا باید به سوالات ساده ای مانند " فرق متد و خصوصیت چیه؟ " یا "فرق کرم و ویروس کامپیوتری چیه؟" یا "برنامه نویسی چند لایه به چه صورت انجام می شه؟" كه با خواندن مستندات قابل پاسخگویی است، جواب دهند. واقعاً نباید برایتان اهمیتی داشته باشد كه داوطلب، هزاران نكته پیش پا افتاده را حفظ كرده است یا نه، بلكه باید توانایی او در تولید كد برایتان مهم باشد. از همه چیز بدتر، سؤالات " معما گونه " است : آن دسته از سؤالاتی كه پاسخ دادن به آنها غیر ممكن است ولی وقتی جواب را میدانید بدیهی به نظر میرسند. مثلا "فرق Padding  و Margin چیست؟".بعضی از مصاحبه کنندگان برای نشان دادن توانایی خود و ضایع کردن مصاحبه شونده لیست بلند بالایی از سوالات و معماهای برنامه نویسی تهیه می کنند تا مصاحبه شونده حساب کار دستش بیاید! اگر شما هم این خصوصیات را دارید لطفا از این به بعد مصاحبه نکنید.

لطفاً از این كارها نكنید! و هر كاری كه میكنید، حتماً از مصاحبه شونده بخواهید كه برایتان كد بنویسد.

آیا از روش " خفت کردن " استفاده می کنید؟

در تست hallway usability، شما یقه اولین فردی را كه از راهرو رد می شود،را می گیرید؛ و مجبورش می كنید كه بنشینند پای برنامه ای كه همین الان نوشته اید. اگر با پنج نفر این كار را تكرار كنید، 95% مشكلات كار با برنامه تان (usability problems) را كشف خواهید كرد.

طراحی " واسط كاربر " خوب آنقدرها هم كه فكر میكنید سخت نیست، حتی برای این كه مشتریها عاشق برنامه تان بشوند و آن را بخرند، واجب هم هست.

اما مهمترین نكته در مورد واسطهای كاربر (user interfaces) این است كه اگر برنامه تان را به پنج یا شش نفر نشان دهید، به سرعت بزرگترین مشكلات كاربران را خواهید دانست. Jakob Nielsen مقالهای دارد كه در آن توضیح میدهد چرا این چنین است. خلاصه این كه حتی اگر در زمینه UI واقعاً ضعیف باشید، با آزمایشهای قابلیت استفاده راهرویی كه شرح آن رفت و خرجی هم ندارد، UI تان واقعاً بهبود پیدا میكند. 

چهار استفاده برای این تست :

1. موسسه نرم افزاری خود را بسنجید تا بدانید که در آنجا باید چگونه کار کنید!
2. اگر مدیر یك تیم نرم افزاری هستید، با استفاده از این تست چك كنید كه آیا تیمتان با تمام توانش كار میكند یا نه؟ اگر امتیازتان 12 است، بهتر است كه برنامه نویسانتان را به حال خودشان رها كنید و انرژیتان را روی عدم مداخله بخش مالی و فروش شركت در كار برنامه نویسها متمركز كنید.
3. اگر میخواهید جایی استخدام شوید، از كارفرمای جدیدتان بپرسید كه چه امتیازی در این تست به دست میآورند. اگر خیلی پایین بود، مطمئن شوید كه اختیارات درست كردن اوضاع را دارید و الا وجودتان بی حاصل خواهد بود.
4. اگر سرمایه گذاری هستید كه در حال برنامه ریزی و سنجش تیمتان میباشید و یا شركتی نرم افزاری هستید كه قصد تركیب با مجموعه نرم افزاری دیگری را دارید، این تست وضعیت را به صورت سر انگشتی به شما خواهد گفت.