حالت تاریک
پیشگفتار و مقدمه
پیشگفتار
بهعنوان بازبین، فرصت زودهنگامی پیدا کردم کتابی را که در دست دارید بخوانم. عالی بود، حتی در قالب پیشنویس. Dave Thomas و Andy Hunt حرفی برای گفتن دارند و میدانند چطور بگویند. دیدم چه میکنند و میدانستم جواب میدهد. خواستم این پیشگفتار را بنویسم تا توضیح دهم چرا.
بهطور ساده، این کتاب به شما میگوید چطور برنامهنویسی کنید بهگونهای که بتوانید دنبالش کنید. فکر نمیکنید این کار سخت باشد، اما هست. چرا؟ از یک جهت، همهٔ کتابهای برنامهنویسی را برنامهنویسان ننوشتهاند. بسیاری را طراحان زبان، یا روزنامهنگارانی که با آنها برای تبلیغ آفرینشهایشان کار میکنند، گردآوری کردهاند. آن کتابها به شما میگویند چطور به زبان برنامهنویسی حرف بزنید — که البته مهم است، اما فقط بخش کوچکی از کاری است که یک برنامهنویس انجام میدهد.
برنامهنویس علاوه بر حرف زدن به زبان برنامهنویسی چه میکند؟ خب، این مسئله عمیقتری است. بیشتر برنامهنویسان در توضیح کاری که میکنند مشکل دارند. برنامهنویسی شغلی پر از جزئیات است و پیگیری آن جزئیات نیاز به تمرکز دارد. ساعتها میگذرد و کد ظاهر میشود. سر بلند میکنید و همهٔ آن دستورات را میبینید. اگر با دقت فکر نکنید، ممکن است تصور کنید برنامهنویسی فقط تایپ کردن دستورات به زبان برنامهنویسی است. البته اشتباه میکنید، اما با نگاه به بخش برنامهنویسی کتابفروشی نمیتوانید بفهمید.
در The Pragmatic Programmer، Dave و Andy به ما میگویند چطور برنامهنویسی کنیم بهگونهای که بتوانیم دنبالش کنیم. چطور اینقدر باهوش شدند؟ آیا آنها هم مثل دیگر برنامهنویسان روی جزئیات متمرکز نیستند؟ جواب این است که وقتی کاری میکردند به آن توجه میکردند — و بعد سعی میکردند بهتر انجامش دهند.
تصور کنید در جلسهای نشستهاید. شاید فکر میکنید جلسه تا ابد طول میکشد و ترجیح میدهید برنامهنویسی کنید. Dave و Andy دربارهٔ اینکه چرا این جلسه برگزار میشود فکر میکنند، میپرسند آیا کار دیگری هست که جای جلسه را بگیرد، و تصمیم میگیرند آیا آن کار را میتوان خودکار کرد تا کار جلسه در آینده خودبهخود انجام شود. بعد همان را انجام میدهند.
این دقیقاً همانطور است که Dave و Andy فکر میکنند. آن جلسه چیزی نبود که آنها را از برنامهنویسی باز دارد. خودش برنامهنویسی بود. و برنامهنویسیای بود که میشد بهترش کرد. میدانم اینطور فکر میکنند چون نکتهٔ شمارهٔ دو همین است: Think About Your Work.
حالا تصور کنید این افراد چند سال اینطور فکر کنند. بهزودی مجموعهای از راهحلها خواهند داشت. حالا تصور کنید چند سال دیگر آن راهحلها را در کارشان به کار ببرند و آنهایی را که خیلی سختاند یا همیشه نتیجه نمیدهند کنار بگذارند. خب، این رویکرد تقریباً تعریف عملگرایی (pragmatic) است. حالا تصور کنید یک یا دو سال دیگر هم صرف کنند تا راهحلهایشان را بنویسند. شاید فکر کنید آن اطلاعات معدن طلا خواهد بود. و حق با شماست.
نویسندگان به ما میگویند چطور برنامهنویسی میکنند. و بهگونهای میگویند که بتوانیم دنبالش کنیم. اما در این جملهٔ دوم بیش از آنچه فکر میکنید نهفته است. بگذارید توضیح دهم.
نویسندگان با دقت از ارائهٔ نظریهای دربارهٔ توسعهٔ نرمافزار پرهیز کردهاند. خوشبختانه، چون اگر میکردند مجبور بودند هر فصل را برای دفاع از نظریهشان تحریف کنند. چنین تحریفی سنت علوم فیزیکی است، جایی که نظریهها سرانجام به قانون تبدیل میشوند یا بیسروصدا کنار گذاشته میشوند. برنامهنویسی در مقابل، قانون کمی (یا اصلاً) ندارد. پس توصیههای برنامهنویسی که حول قوانین ناقص شکل گرفتهاند ممکن است روی کاغذ خوب به نظر برسند، اما در عمل رضایت نمیدهند. همین جایی است که بسیاری از کتابهای methodology اشتباه میکنند.
این مسئله را دوازده سال مطالعه کردهام و بیشترین امید را در ابزاری به نام pattern language یافتام. بهطور خلاصه، pattern یک راهحل است و pattern language سامانهای از راهحلهاست که یکدیگر را تقویت میکنند. جامعهای کامل دور جستجوی این سامانهها شکل گرفته است.
این کتاب بیش از مجموعهای از نکات است. pattern language است در لباس گوسفند. این را میگویم چون هر نکته از تجربه گرفته شده، بهصورت توصیهٔ مشخص گفته شده و با دیگران مرتبط شده تا سامانهای بسازد. اینها همان ویژگیهاییاند که به ما اجازه میدهند pattern language را یاد بگیریم و دنبال کنیم. اینجا هم همینطور کار میکنند.
میتوانید توصیههای این کتاب را دنبال کنید چون مشخصاند. انتزاعات مبهم پیدا نمیکنید. Dave و Andy مستقیم برای شما مینویسند، گویی هر نکته راهبردی حیاتی برای energizing کردن مسیر شغلی برنامهنویسیتان است. ساده میکنند، داستانی میگویند، با لمس سبک پیش میروند، و بعد پاسخ سؤالهایی را میدهند که وقتی امتحان میکنید پیش میآید.
و بیشتر هم هست. بعد از خواندن ده یا پانزده نکته، بعد اضافیای در کار میبینید. گاهی آن را QWAN مینامیم، مخفف quality without a name — کیفیتی بدون نام. کتاب فلسفهای دارد که به آگاهیتان نفوذ میکند و با فلسفهٔ خودتان درمیآمیزد. موعظه نمیکند. فقط میگوید چه جواب میدهد. اما در گفتن، بیشتر از آنچه گفته میشود عبور میکند. زیبایی کتاب همین است: فلسفهاش را مجسم میکند، و بدون pretension.
پس اینجاست: کتابی آسان برای خواندن — و استفاده — دربارهٔ کل عمل برنامهنویسی. زیاد دربارهٔ اینکه چرا جواب میدهد حرف زدم. شما احتمالاً فقط میخواهید بدانید جواب میدهد. میدهد. خواهید دید.
— Ward Cunningham
مقدمه
این کتاب به شما کمک میکند برنامهنویس بهتری شوید.
فرقی نمیکند lone developer باشید، عضو تیم بزرگ پروژه، یا مشاوری که همزمان با چند مشتری کار میکند. این کتاب به شما، بهعنوان فرد، کمک میکند کار بهتری انجام دهید. این کتاب نظری نیست — روی موضوعات عملی تمرکز میکنیم، روی استفاده از تجربهتان برای تصمیمهای آگاهانهتر. واژهٔ pragmatic از لاتین pragmaticus — «ماهر در کسبوکار» — میآید که خودش از یونانی «انجام دادن» مشتق شده. این کتاب دربارهٔ انجام دادن است.
برنامهنویسی یک craft است. در سادهترین حالت، به این برمیگردد که کامپیوتر را وادار کنید آنچه میخواهید انجام دهد (یا کاربرتان میخواهد). بهعنوان برنامهنویس، بخشی شنونده، بخشی مشاور، بخشی مترجم و بخشی دیکتاتور هستید. سعی میکنید نیازهای لغزان را بگیرید و راهی برای بیانشان پیدا کنید تا ماشینی ساده بتواند عدالت را رعایت کند. سعی میکنید کارتان را مستند کنید تا دیگران بفهمند، و آن را engineer کنید تا دیگران بتوانند روی آن بسازند. علاوه بر این، همهٔ این را در برابر تیکتاک بیرحم ساعت پروژه انجام میدهید. هر روز معجزههای کوچکی خلق میکنید.
شغل سختی است.
افراد زیادی کمک پیشنهاد میدهند. فروشندگان ابزار معجزهٔ محصولاتشان را تبلیغ میکنند. guruهای methodology قول میدهند تکنیکهایشان نتیجه تضمین میکنند. همه ادعا میکنند زبان برنامهنویسیشان بهترین است و هر سیستمعاملی پاسخ همهٔ بیماریهای قابل تصور است.
البته هیچکدام درست نیست. جواب آسان وجود ندارد. چیزی به نام بهترین راهحل — چه ابزار، چه زبان، چه سیستمعامل — وجود ندارد. فقط سامانههایی هستند که در مجموعهٔ خاصی از شرایط مناسبترند.
اینجاست که pragmatism وارد میشود. نباید به فناوری خاصی وابسته باشید، بلکه پسزمینه و پایهٔ تجربهٔ بهاندازهٔ کافی گسترده داشته باشید تا در موقعیتهای خاص راهحلهای خوب انتخاب کنید. پسزمینهتان از درک اصول پایهٔ علوم کامپیوتر میآید و تجربهتان از طیف وسیعی از پروژههای عملی. نظریه و عمل با هم شما را قوی میکنند.
رویکردتان را با شرایط و محیط فعلی تطبیق میدهید. اهمیت نسبی همهٔ عوامل مؤثر بر پروژه را میسنجید و با تجربهتان راهحلهای مناسب تولید میکنید. و این کار را پیوسته، همزمان با پیشرفت کار، انجام میدهید. برنامهنویسان عملگرا کار را انجام میدهند، و خوب انجام میدهند.
چه کسانی باید این کتاب را بخوانند؟
این کتاب برای کسانی است که میخواهند برنامهنویس مؤثرتر و productiveتری شوند. شاید احساس میکنید به پتانسیلتان نمیرسید. شاید به همکارانی نگاه میکنید که با ابزارها productiveتر از شما شدهاند. شاید شغل فعلیتان از فناوریهای قدیمیتر استفاده میکند و میخواهید بدانید ایدههای جدیدتر چطور روی کارتان اعمال میشوند.
ادعا نمیکنیم همهٔ (یا حتی بیشتر) جوابها را داریم، و نه همهٔ ایدههایمان در همهٔ موقعیتها کاربرد دارند. تنها میتوانیم بگوییم اگر رویکرد ما را دنبال کنید، سریع تجربه میگیرید، productivityتان بالا میرود و درک بهتری از کل فرایند توسعه پیدا میکنید. و نرمافزار بهتری مینویسید.
چه چیزی یک برنامهنویس عملگرا میسازد؟
هر developer منحصربهفرد است، با نقاط قوت و ضعف، ترجیحات و بیعلاقگیهای فردی. با گذشت زمان، هر کدام محیط شخصی خود را میسازد. آن محیط بهاندازهٔ سرگرمیها، لباس یا مدل مو، individuality برنامهنویس را منعکس میکند. با این حال، اگر برنامهنویس عملگرا باشید، بسیاری از ویژگیهای زیر را با دیگران به اشتراک میگذارید:
Early adopter / fast adapter. غریزهای برای فناوریها و تکنیکها دارید و عاشق امتحان کردن چیزهای جدید هستید. وقتی چیز جدیدی به شما داده میشود، سریع میگیرید و با بقیهٔ دانشتان یکپارچه میکنید. اعتمادبهنفستان از تجربه میآید.
کنجکاو (Inquisitive). تمایل دارید سؤال بپرسید. «جالب است — چطور این کار را کردی؟» «با آن کتابخانه مشکل داشتی؟» «این BeOS که شنیدهام چیست؟» «لینکهای symbolic چطور پیادهسازی میشوند؟» برای حقایق کوچک جمعآوری میکنید که هر کدام ممکن است سالها بعد روی تصمیمی اثر بگذارد.
متفکر انتقادی (Critical thinker). بهندرت چیزی را بدون گرفتن حقایق قبول میکنید. وقتی همکاران میگویند «چون همیشه اینطور انجام میشود»، یا vendor وعدهٔ راهحل همهٔ مشکلاتتان را میدهد، بوی challenge میآید.
واقعگرا (Realistic). سعی میکنید ماهیت زیربنایی هر مشکلی را بفهمید. این realism حس خوبی از سختی کارها و زمان لازم میدهد. وقتی خودتان بفهمید فرایندی باید سخت باشد یا مدتی طول بکشد، stamina دارید ادامه دهید.
همهفنحریف (Jack of all trades). سخت تلاش میکنید با طیف گستردهای از فناوریها و محیطها آشنا باشید و از تحولات جدید باخبر بمانید. اگرچه شغل فعلیتان ممکن است تخصص بخواهد، همیشه میتوانید به حوزهها و چالشهای جدید بروید.
سادهترین ویژگیها را برای آخر گذاشتیم. همهٔ برنامهنویسان عملگرا آنها را دارند. آنقدر پایهایاند که میتوان بهصورت نکته گفت:
TIP 1
به craft خود اهمیت دهید
Care About Your Craft
احساس میکنیم بدون اهمیت دادن به انجام خوب کار، توسعهٔ نرمافزار بیمعناست.
TIP 2
فکر کنید! دربارهٔ کارتان
Think! About Your Work
برای برنامهنویس عملگرا بودن، از شما میخواهیم دربارهٔ کاری که میکنید، همزمان با انجامش، فکر کنید. این audit یکبارهٔ روشهای فعلی نیست — ارزیابی انتقادی مداوم هر تصمیمی است که هر روز و در هر توسعه میگیرید. هرگز روی auto-pilot نروید. پیوسته فکر کنید، کار خود را در real time نقد کنید. شعار شرکتی قدیمی IBM، THINK!، mantra برنامهنویس عملگراست.
اگر این برایتان کار سخت به نظر میرسد، ویژگی realistic را نشان میدهید. بخشی از وقت ارزشمندتان — که احتمالاً الان تحت فشار شدید است — صرف میشود. پاداش، مشارکت فعالتر در شغلی است که دوست دارید، حس mastery روی دامنهٔ فزایندهای از موضوعات، و لذت از بهبود پیوسته. در بلندمدت، سرمایهگذاری زمانیتان بازمیگردد چون شما و تیمتان efficientتر میشوید، کدی مینویسید که نگهداریاش آسانتر است و کمتر در جلسات وقت میگذارید.
عملگرایان فردی، تیمهای بزرگ
بعضی احساس میکنند در تیمهای بزرگ یا پروژههای پیچیده جایی برای individuality نیست. میگویند: «ساخت نرمافزار رشتهٔ engineering است که اگر اعضای تیم برای خود تصمیم بگیرند، از هم میپاشد.»
ما مخالفیم.
ساخت نرمافزار باید رشتهٔ engineering باشد. اما این مانع craftsmanship فردی نمیشود. به کلیساهای بزرگ اروپا در قرون وسطی فکر کنید. هر کدام هزاران نفر-سال تلاش، در دهههای زیاد، میخواست. درسهای آموختهشده به نسل بعدی سازندگان منتقل شد و آنها engineering سازه را با دستاوردهایشان پیش بردند. اما نجارها، سنگتراشها، حکاکها و شیشهگرها همه craftsperson بودند؛ نیازهای engineering را تفسیر میکردند تا کلّی بسازند که فراتر از جنبهٔ صرفاً مکانیکی ساخت بود. باور به سهم فردی پروژهها را نگه میداشت:
ما که سنگهای ساده میبُریم باید همیشه کلیساها را در ذهن ببینیم.
— عهد کارگر معدن (Quarry worker's creed)
در ساختار کلی پروژه همیشه جایی برای individuality و craftsmanship هست. با وضعیت فعلی software engineering این بهویژه درست است. صد سال دیگر، engineering ما شاید بهاندازهٔ تکنیکهای سازندگان کلیساهای قرون وسطی برای مهندسان عمران امروز کهنه به نظر برسد، اما craftsmanship ما همچنان گرامی داشته خواهد شد.
فرایندی پیوسته
گردشگری که از Eton College انگلستان بازدید میکرد از باغبان پرسید چطور چمنها اینقدر بینقص شدهاند. «آسان است»، جواب داد، «هر صبح شبنم را برس میزنید، یک روز در میان چمنزنی میکنید و هفتهای یکبار غلتک میزنید.»
«فقط همین؟» گردشگر پرسید.
«کاملاً»، باغبان جواب داد. «پانصد سال همین کار را بکنید و شما هم چمن خوبی خواهید داشت.»
چمنهای عالی مراقبت روزانهٔ کوچک میخواهند و برنامهنویسان عالی هم همینطور. مشاوران مدیریت دوست دارند در گفتگوها واژهٔ kaizen را بیندازند. «Kaizen» اصطلاح ژاپنی است که مفهوم بهبود پیوسته با تغییرات کوچک زیاد را میگیرد. یکی از دلایل اصلی پیشرفت چشمگیر productivity و کیفیت در تولید ژاپن دانسته میشد و در سراسر جهان تقلید شد. Kaizen برای افراد هم صدق میکند. هر روز روی مهارتهایی که دارید کار کنید و ابزارهای جدید به arsenalتان اضافه کنید. برخلاف چمنهای Eton، ظرف چند روز نتیجه میبینید. در طول سالها، شگفتزده میشوید از اینکه تجربهتان چطور شکوفا شده و مهارتهایتان رشد کردهاند.
چگونه کتاب سازماندهی شده است
این کتاب مجموعهای از بخشهای کوتاه است. هر بخش مستقل است و موضوع خاصی را برمیگرداند. cross referenceهای زیادی پیدا میکنید که هر موضوع را در context قرار میدهند. آزادانه بخشها را به هر ترتیبی بخوانید — کتابی نیست که حتماً از اول تا آخر خوانده شود.
گاهی به جعبهای با برچسب Tip nn (مثل Tip 1، «Care About Your Craft» در صفحهٔ xix) برمیخورید. علاوه بر تأکید نکات در متن، احساس میکنیم نکات زندگی خودشان را دارند — روزانه با آنها زندگی میکنیم. خلاصهٔ همهٔ نکات را روی کارت جداشوندهٔ داخل جلد پشت کتاب میبینید.
پیوست A مجموعهای از منابع دارد: bibliography کتاب، فهرست URLهای منابع وب، و فهرست نشریات، کتابها و سازمانهای حرفهای پیشنهادی. در سراسر کتاب به bibliography و فهرست URL — مثل [KP99] و [URL 18] — ارجاع میدهیم.
در جاهای مناسب تمرین و challenge گنجاندهایم. تمرینها معمولاً جواب نسبتاً مستقیمی دارند، challengeها بازترند. برای نشان دادن تفکرمان، جواب تمرینها را در پیوست B آوردهایم، اما تعداد کمی راهحل واحد درست دارند. challengeها میتوانند پایهٔ بحث گروهی یا کار مقالهای در دورههای پیشرفتهٔ برنامهنویسی باشند.
نام چه معنایی دارد؟
وقتی از کلمهای استفاده میکنم، Humpty Dumpty با لحن تحقیرآمیزی گفت، دقیقاً همان معنایی را دارد که من انتخاب کردهام — نه بیشتر و نه کمتر.
— Lewis Carroll، Through the Looking-Glass
در سراسر کتاب jargonهای مختلفی پیدا میکنید — یا کلمات انگلیسی سالم که معنای فنی گرفتهاند، یا واژههای ساختهٔ وحشتناک که دانشمندان کامپیوتر با کینه به زبان نسبت دادهاند. اولین بار که از هر jargon استفاده میکنیم، سعی میکنیم تعریفش کنیم یا حداقل سرنخی از معنایش بدهیم. اما مطمئنیم بعضی از قلم افتادهاند و بعضی دیگر، مثل object و relational database، آنقدر رایجاند که افزودن تعریف خستهکننده میشود. اگر به واژهای برخوردید که ندیدهاید، لطفاً از روی آن رد نشوید. وقت بگذارید و جستجو کنید، شاید در وب یا شاید در کتاب درسی علوم کامپیوتر. و اگر فرصت شد، ایمیل بزنید و شکایت کنید تا در چاپ بعدی تعریف اضافه کنیم.
با این همه، تصمیم گرفتیم از دانشمندان کامپیوتر انتقام بگیریم. گاهی برای مفاهیم jargonهای خوب وجود دارد که تصمیم گرفتهایم نادیده بگیریم. چرا؟ چون jargon موجود معمولاً به domain مشکل خاص یا فاز خاصی از توسعه محدود است. اما یکی از فلسفههای پایهٔ این کتاب این است که بیشتر تکنیکهایی که توصیه میکنیم universal هستند: modularity برای کد، design، documentation و سازمان تیم صدق میکند، مثلاً. وقتی میخواستیم jargon متعارف را در context گستردهتر به کار ببریم، گیجکننده میشد — نمیتوانستیم baggageای که اصطلاح اصلی با خود میآورد را کنار بگذاریم. وقتی این اتفاق افتاد، با اختراع واژههای خودمان به افول زبان کمک کردیم.
کد منبع و منابع دیگر
بیشتر کدهای نشاندادهشده در این کتاب از فایلهای source قابل compile استخراج شده و برای دانلود در وبسایت ما در دسترس است:
www.pragmaticprogrammer.com
آنجا لینک منابع مفیدی که پیدا کردهایم، بهروزرسانیهای کتاب و خبر سایر فعالیتهای Pragmatic Programmer را هم میبینید.
بازخورد بفرستید
خوشحال میشویم از شما بشنویم. نظرات، پیشنهادها، خطاهای متن و مشکلات مثالها همه خوشآمدند. به ما ایمیل بزنید:
ppbook@pragmaticprogrammer.com
سپاسگزاری
وقتی شروع به نوشتن این کتاب کردیم، نمیدانستیم چقدر تلاش تیمی میشود.
Addison-Wesley فوقالعاده بود؛ چند hacker تازهکار را گرفت و در کل فرایند تولید کتاب، از ایده تا camera-ready copy، همراهی کرد. سپاس فراوان از John Wait و Meera Ravindiran برای حمایت اولیه، Mike Hendrickson، ویراستار پرشور ما (و طراح جلد ماهر!)، Lorraine Ferrier و John Fuller برای کمک در production، و Julie DeBaggis خستگیناپذیر که همه را کنار هم نگه داشت.
بعد بازبینها بودند: Greg Andress، Mark Cheers، Chris Cleeland، Alistair Cockburn، Ward Cunningham، Martin Fowler، Thanh T. Giang، Robert L. Glass، Scott Henninger، Michael Hunter، Brian Kirby، John Lakos، Pete McBreen، Carey P. Morris، Jared Richardson، Kevin Ruland، Eric Starr، Eric Vought، Chris Van Wyk و Deborra Zukowski. بدون نظرات دقیق و بینشهای ارزشمندشان، این کتاب کمتر خوانا، کمدقیقتر و دو برابر بلندتر بود. از همه برای وقت و خردتان سپاسگزاریم.
چاپ دوم این کتاب بهشدت از چشمان تیز بینندگانمان بهره برد. سپاس فراوان از Brian Blank، Paul Boal، Tom Ekberg، Brent Fulgham، Louis Paul Hebert، Henk-Jan Olde Loohuis، Alan Lund، Gareth McCaughan، Yoshiki Shibata و Volker Wurst، هم برای یافتن اشتباهات و هم برای اشارهٔ ملایم به آنها.
در طول سالها با مشتریان پیشروی زیادی کار کردهایم و تجربهای را که اینجا مینویسیم به دست آورده و پالایش کردهایم. اخیراً خوششانس بودیم چند پروژهٔ بزرگ با Peter Gehrke انجام دهیم. حمایت و اشتیاقش برای تکنیکهایمان بسیار قدردانیشده است.
این کتاب با LATEX، pic، Perl، dvips، ghostview، ispell، GNU make، CVS، Emacs، XEmacs، EGCS، GCC، Java، iContract و SmallEiffel، با shellهای Bash و zsh روی Linux تولید شد. شگفتانگیز است که همهٔ این نرمافزار عظیم آزاد در دسترس است. سپاس عمیق از هزاران برنامهنویس عملگرا در سراسر جهان که این آثار و دیگر کارها را در اختیار همه گذاشتهاند. بهویژه از Reto Kramer برای کمک با iContract سپاسگزاریم.
و در پایان، اما به هیچ وجه کماهمیتتر، بدهی عظیمی به خانوادههایمان داریم. نهتنها تحمل تایپ تا نیمهشب، قبض تلفنهای سنگین و حالت دائمی حواسپرتی ما را، بلکه با grace بارها آنچه نوشتهایم را خواندهاند. ممنون که گذاشتید رویا ببینیم.
Andy Hunt
Dave Thomas