پدر علم UML و Design Pattern تجربیات اساسی و بنیادین خود را در مورد توسعه (developing) ، استقرار (deploying) و ارائه (delivering) پروژه های بزرگ نرم افزاری ، به اشتراک گذاشته است . در این مقاله این پنج ویژگی مهم شرح داده شده اند .

تعداد انگشت شماری از برنامه نویسان هستند که برای توسعه دهندگان نرم افزار آشنا و قابل شناسایی هستند ، که اغلب از روی پایه نام آنها همانند "Britney" و "Oraph" است که جوامع دیگر بدون هیچ توضیح بیشتری با دیدن این نام ها ، آنها را تشخیص میدهند . این اشخاص راه برنامه نویسان را طراحی میکنند و برنامه ها را با شناسایی ابزار هایی برای بهبود فرآیند ها ، بهبود می‌بخشند . 
یکی از این افراد که هیچ شکی در دانش و توانایی آن نیست، Grady Booch است.او یکی از اعضای اصلی از توسعه دهندگان زبان UML بود و این نخستین تاثیری بودکه او بر برنامه نویسی شی گرا (OOP) گذاشت.او همچنین چندین کتاب در مورد برنامه شی گرا منتشر کرده است. و از سال 1980به عنوان chief scientist در
 Rational (که در حال حاضر قسمتی از IBM است)، فعالیت داشته است . 
در IBM نام تشریفاتی مهندسان نرم‌افزار، chief scientis، می‌باشد. در زیر توصیه های وی در مورد توسعه و پیاده سازی پروژه های بزرگ را مشاهده خواهید کرد :

1. هیچ وقت پایه و اساس از دور خارج نمی‌شود :
پروژه های بزرگ و طولانی میتوانند بسیار بی رحم باشند ، و در بدترین حال آنها همانند یک رژه بسوی مرگ نمایان میشوند . که Booch بیان دارد که هیچ وقت چهار اصل اساسی زیر را فراموش نکنید :
 
- Abstractionهای واضح و انعطاف پذیری را ایجاد کنید . 
- حفظ و رعایت Spration of Concern
- ایجاد یک توزیع متعادل از مسئولیت.
- تمرکز بر روی سادگی.

نکته کلیدی و مهم استفاده از Abstractionها این است که به جای داشتن یک دید نقطه ای و الگوریتم بر پایه viewpoint ، یک برنامه با دید شی گرایی خواهیم داشت . همچنین او بیان دارد که به جای تمرکز بر روی پردازش ، به این چیزها فکر کنید . 

Spration of Concern ، بدین معناست که ، شما مسئول شست و شوی ظروف را در حموم قرار نمیدهید . جزئیات به نیازمندی ها بستگی دارد . اما او این توصیه را دارد که چیزهای مرتبط بهتر است بصورت خوشه ای و بصورت جداگانه از هم نگه داشته شوند ، که به این صورت نمی‌شوند . 

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

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

2. شما به یک ریتم منظم منتشر شده نیاز دارید :

او بیان دارد که ، هر پروژه ای نیاز به یک نبض دارد . ایجاد این ریتم ، قابل پیش بینی بودن و پایداری را فراهم می‌آورد . نظم و قاعده این امکان فراهم میکند که عملکرد و ویژگی هایی که در مرحله بعد رخ می‌دهد ، قابل پیش بینی باشد . 

3. تمرکز بر روی معماری های قابل اجرا :
مدیران IT ، به جای کدهای raw, running, naked ، نیاز به اداره کردن با تصمیم گیری های معماری دارند . 
اون بیان دارد که ، کد حقیقت است ، اما آن همه حقیقت نیست . 

4. ایجاد ساختارهای اجتماعی که هرگونه نوآوری را  تشویق میکند با حفظ قابل بیش بینی بودن آن کار تیمی یکی از جزهای پایه ای و اساسی هر پروژه بزرگی است ، بنابراین کمپانی ها به ایجاد رابطه ها در این مورد باید بیشتر توجه کنند . Business نیاز به قابل پیش بینی بودن دارند ، ایجاد یک ساختار اجتماعی که هر دو ویژگی بالا را پوشش دهد ، کار ضروری نیست اما ، روند موفقیت پروژه را متعادل می‌کند .  
در این ساختار های اجتماعی ، مدیر در پردازش توسعه نرم افزار یک شرکت کننده است .
 او همچنین بیان دارد که ، معماری باید یک مجری باشد ، حتی اگر یک خط بین توسعه و مدیرها ، محو شده باشد . اما در اینجا یک ارتباط پر سر و صدای خطرناک وجود دارد که مدیریت را درگیر خودش میکند . و آن تفاوت بین یک خط و یک دیوار است . 

یکی دیگر از مولفه برای داشتن یک تیم نوآور، جلوگیری از دیدارهای پژمرده و آفت زده است . 

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