دوستان بسیار زیادی از نوشته " 15 دليل براي «ميوه فروش» شدن به جاي «مهندس نرم افزار» شدن! " استقبال و در رد یا قبول آن توضیحاتی ارائه دادند. نمی‏خواهم نظرم را با جزئیات بیان کنم. فقط  دو نکته قابل عرض آن که:
1- الف: همیشه مرغ همسایه، غاز است. ب:هر جا که بروی، آسمان همین رنگ است . ج:خوشبختی در خانه توست، بیهوده آن را در باغچه همسایه جستجو نکن.
2- اکثر دوستان و همکاران با عشق و انتخاب به این رشته وارد شده‏اند. لذا خطاب شعر زیبای استاد فریدون مشیری هستند که:

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

"فریدون مشیری"

گزیده:

Never tell your problems to anyone...20% don't care and the other 80% are glad you have them.  Lou Holtz

سالها پيش آنقدر از فشارهاي پروژه و دشوار بودن توليد نرم افزار در ايران خسته شده بودم که با يکي از دوستان همدانشگاهی تصميم گرفتيم یک شغل شرافتمندانه انتخاب کنیم! این بود که مشاغل مختلف را علمی، بررسی کردیم و آخر از همه تصمیم گرفتیم یک میوه فروشی باز کنیم! چرا؟ به هزار و پانزده دلیل! 15 دلیلش را می نویسم، هزارتای بقیه اش را خودتان خواهید دانست:
1- عدم وجود گارانتی: بعد از فروش نرم افزار باید آن را گارنتی کنی. برخلاف بسیاری از مشاغل که شما بابت گارانتی پول اضافه می گیرد و نزد خود نگه می دارید، در نرم افزار بر عکس عمل می شود و این کارفرمای شماست که از شما تضمین (درصدی از قرارداد، چک تضمین، سفته و یا ضمانت نامه بانکی یا همه مواد) می گیرد. در حالیکه میوه فروشی گارانتی ندارد، جنس فروخته شده پس گرفته نمی شود.
2- بازه کوتاه زمان فروش: یک پروژه نرم افزاری ماهها طول می کشد و باعث فرسایش نیروی کار می شود در حالیکه در میوه فروشی، صبح زود بار میوه و سبزی می آوری، حداکثر تا ظهر سبزی ها تمام می شود، میوه ها هم، بسته به محیط شما، در مدت زمان کوتاهی فروش می روند و شما بازهم بار جدیدی می آورید.
3- تغییر نیاز ندارید: رایج است که نیازهای مشتری تازه زمانی آشکار می شود که شما نرم افزار را فروخته اید و مشتری متوقع است که در چارچوب همان قرارداد تغییرات اعمال شود، حتی اگر ماهیت تغییر کند. اما در میوه فروشی، خریدار که از مغازه خارج شد شما دیگر مسؤولیتی ندارید، اگر تصمیمش عوض شد، شما نگران نیستید، یک کالای جدید به وی می فروشید.
3- عدم محصول ارجاعی: در نرم افزار اگر محصول شما کار نکرد و یا قدیمی شد مشتری یا ارجاع می دهد و یا دیگر سراغش نمی آید، در میوه فروشی شما میوه سالم را به مردم به فیمت گران، میوه نیمه خراب را ارزان تر به مردم کم درآمد تر و احتمالا میوه کاملا خراب را به آبمیوه فروشی ها و نمی دانم لواشک سازی ها می فروشید!
4-واسطه گری به جای تولید: در میوه فروشی شما محلی برای عرضه کالای دیگران هستید، معمولا افزایش قیمت بین میدان میوه و تره بار با مغازه شما چند برابراست . اما در نرم افزار شما تولید می کنید و دردسر های آن را دارید تازه در انتها و پس از کسر انواع مالیات و بیمه هزینه تولید را در بیاورید خیلی هنر کرده اید!
5-مدیریت نیروی انسانی، خیر! : شما در شرکت نرم افزاری با نیروی لوس و نازک نارنجی کارشناس سروکار دارید که کافی است یک کم ناراحت شود، هوس کانادا به سرش می زند، اما در میوه فروشی یکی دو کارگر از برادران افغانی می گیرید، مثل ساعت برای شما کار می کنند و غر که نمی زنند هیچ با همه سختی ها هم می سازند.

6-فصلی بودن کار، تعطیل: در تولید و فروش نرم افزار شما وابسته به زمان هستید، برای مثال دولتی ها معمولا در ماه های خاصی خرید بیشتری می کنند، یا در فروردین و اردیبهشت شما با افت فروش مواجه می شوید، اما در میوه فروشی هر فصلی میوه خودش را دارد و شما آن را می آورید، هر میوه ای هم طرفدار خاص خودش را دارد و شما تقریبا در همه سال فروش خود را یکنواخت خواهید داشت. شب عید ها هم که جای خودش را دارد و شما پوست خلایق را حسابی خواهید کند.
7- بازار دائمی: نرم افزاری ها مانند یک کارگر ساختمانی هستند، باید ساختمانی ساخته شود تا به آنان نیاز باشد، وقتی بودجه IT کشور صفر شود که نمی توان پروژه ای تعریف کرد که نرم افزاری روی آن کار کند، چون هنوز از دیدگاه اغلب تصمیم گیرندگان ما، نرم افزار یک کار تشریفاتی است. اما میوه فروشی نیاز روز مردم است، همه هر روز خرید خودشان را دارد، وضع مردم بد هم بشود باز هم مهمانی می آید که شما وادار شوید حتما میوه خوب بخرید.
8-درهم است: در نرم افزار شما قاصر هستید از اینکه به یک مشتری بفهمانید نرم افزار با نرم افزار متفاوت است. چون با یک چیز انتزاعی طرف است، بین نرم افزاری حسابداری 5 هزارتومانی با حسابداری 10 میلیون تومانی فرقی قائل نیست. در حالیکه در میوه فروشی ، مشتری تفاوت سیب با سیب را در می یابد و اگر دنبال کیفیت خوب است پولش را هم می پردازد.
9- شما فقط میوه را می فروشید: در نرم افزار وقتی شما نرم افزاری عرضه می کنید، داستان عرضه خدمات پس از فروش شروع می شود، آموزش کاربران -بعضا واقعا تعطیل!- تبدیل اطلاعات و انتقال آنها از سیستم قدیمی به جدید، عرضه سخت افزار، نگرانی از کارکردن نرم افزار روی هر نوع سخت افزار آشغالی که مشتری به شما می دهد و ... اما در میوه فروشی، شما فقط میوه را می فروشید اینکه هندوانه را چطور می خورند، گیلاس را چطور؟ اینکه آیا مشتری ظرف مناسبی برای نگهداری میوه دارد و یا خیر نیز به شما ربطی ندارد.
10- یک بار برای همیشه، هرگز: نرم افزار را که می فروشید مشتری توقع دارد این نرم افزار مادام العمر باشد برایش ، به سادگی حاضر نیست قرارداد پشتیبانی و ارتقاء نرم افزار ببندد، اما همه می دانیم که یک میوه را برای همه سال نمی توان نگه داشت، خورده می شود بالاخره! باید میوه جدیدی خرید!
11- باگ: خرابی میوه نگرانی ندارد، روشهای نگهداری میوه معلوم است و اگر شما یک کم تجربه پیدا کنید می توانید به سادگی آن را نگهداری کنید، اما در نرم افزار آنقدر مشکلات متعدد و متفاوت پیش می آید که شما گیج می شوید که این خطا از کجاست و راه حلش چطور است؟ مناطق بحرانی ، آنقدر خطایابی را سخت می کنند که شما نیاز به فاز مجزایی برای آن پیدا می کنید و هزینه زیادی برای هر خطا می پردازید، تازه تضمینی وجود ندارد که همه خطا ها را پیدا کرده باشید و روز تحویل به مشتری، جلوی چشم وی، آنقدر سیستم خطا می دهد که شما آب می شوید و زمین می روید.
12-آن که خربزه می خورد پای لرزش می نشیند: شما مسؤول نحوه استفاده مشتری از میوه نیستید، مهم نیست برایتان که در عزا بخورند یا در عروسی، مهم نیست که به طرف نمی سازد یا می سازد. اما در نرم افزار، کافی است از نرم افزار شما سوء استفاده شود، نمی دانم چرا یقه شما را می گیرند که چرا از طریق نرم افزار شما به ما آسیب وارد شد، چرا هک شد، چرا ....؟
13-دوره بازپرداخت سریع: در میوه فروشی به محض فروش میوه پولتان را می گیرید، اما در نرم افزار تازه پروژه را که تحویل دادید و صورتجلسه کردید، باید بدوید به دنبال پولتان، آنقدر این پول دادن دیر و تکه تکه می شود که به نوش داروی پس از مرگ سهراب می ماند، به شکلی که بعضی وقت ها بی خیال پولتان می شوید.
14- تنوع مشتری: شما در یک شرکت نرم افزاری با طیف خاصی از مشتری سروکار دارید، یا دولتی یا خصوصی یا آموزشی یا ... اما در میوه فروشی شما قیدی برای مشتری ندارید، زن و مرد، کوچک و بزرگ، دارا و ندار، پیر و جوان، شهری و روستایی ،... همه به نوعی مشتری شما هستند، آنهم مشتری دائمی که از همه چیز می گذرد الا از خوردن!
15- کپی رایت: در میوه فروشی نمی توانید یک میوه را بخرید و تکثیر کنید، در نرم افزار می توانید، خوب هم می توانید. اگر تولید کننده ناراحت هم شد مهم نیست، چون یا قانون کافی نداریم و یا آنقدر این قضیه پیچیده است که شما بی خیال می شوید.
.....
برای تصمیم گرفتن کافی نیست!؟

نمی دانم چرا با وجود همه این استدلال های منطقی، میوه فروش نشدم. آرزو می کنم حداقل یک نفر این مطلب را بخواند و به راه راست هدایت شود! دست از مهندسی نرم شدن بردارد و به قول بچه ها یک کار «شرافتمندانه» پیدا کند. امیدوارم...
همین!

مرجع: http://weblog.radmanitd.com/archives/000307.html

گزیده:

I have not failed. I've just found 10,000 ways that won't work.     - Thomas Alva Edison

۱. گشاده دست باش، جاری باش، كمك كن (مثل رود)

۲. باشفقت و مهربان باش (مثل خورشيد)

۳. اگركسی اشتباه كرد آن رابپوشان (مثل شب)

۴. وقتی عصبانی شدی خاموش باش (مثل مرگ)

۵. متواضع باش و كبر نداشته باش (مثل خاك)

۶. بخشش و عفو داشته باش (مثل دريا )

۷. اگر می خواهی ديگران خوب باشند خودت خوب باش (مثل آينه)


مرجع: http://www.newshairan.blogfa.com

گزیده:

“To improve is to change; to be perfect is to change often.” -- Winston Churchill

بخش پونتیاك شركت خودروسازی جنرال موتورز شكایتی را از یك مشتری با این مضمون دریافت كرد: «این دومین باری است كه برایتان می‌نویسم و برای این كه بار قبل پاسخی نداده‌اید، گلایه‌ای ندارم؛ چراكه موضوع از نظر من نیز احمقانه است! به هر حال، موضوع این است كه طبق یك رسم قدیمی، خانواده ما عادت دارد هر شب پس از شام به عنوان دسر بستنی بخورد. سال‌هاست كه ما پس از شام رای‌گیری می‌كنیم و براساس اكثریت آراء نوع بستنی، انتخاب و خریداری می‌شود. این را هم باید بگویم كه من بتازگی یك خودروی شورولت پونتیاك جدید خریده‌ام و با خرید این خودرو، رفت و آمدم به فروشگاه برای تهیه بستنی دچار مشكل شده است.
لطفا دقت بفرمایید! هر دفعه كه برای خرید بستنی وانیلی به مغازه می‌روم و به خودرو بازمی گردم، ماشین روشن نمی شود؛ اما هر بستنی دیگری كه بخرم، چنین مشكلی نخواهم داشت. خواهش می‌كنم درك كنید كه این مساله برای من بسیار جدی و دردسرآفرین است و من هرگز قصد شوخی با شما را ندارم. می‌خواهم بپرسم چه‌طور می‌شود پونتیاك من وقتی بستنی وانیلی می‌خرم، روشن نمی‌شود؛ اما با هر بستنی دیگری راحت استارت می‌خورد؟
مدیر شركت به نامه‌ی دریافتی از این مشتری عجیب، با شك و تردید برخورد كرد؛ اما از روی وظیفه و تعهد، یك مهندس را مامور بررسی مساله كرد. مهندس خبره‌ی شركت، شب هنگام پس از شام با مشتری قرار گذاشت. آن دو به اتفاق به بستنی‌‌فروشی رفتند. آن شب نوبت بستنی وانیلی بود. پس از خرید بستنی، همان‌طور كه در نامه شرح داده شد، ماشین روشن نشد! مهندس جوان و جویای راه حل، 3 شب پیاپی دیگر نیز با صاحب خودرو وعده كرد. یك شب نوبت بستنی شكلاتی بود، ماشین روشن شد. شب بعد بستنی توت‌فرنگی و خودرو به راحتی استارت خورد. شب سوم دوباره نوبت بستنی وانیلی شد و باز ماشین روشن نشد!
نماینده‌ی شركت به جای این‌كه به فكر یافتن دلیل حساسیت داشتن خودرو به بستنی وانیلی باشد، تلاش كرد با موضوع منطقی و متفكرانه برخورد كند. او مشاهداتی را از لحظه ترك منزل مشتری تا خریدن بستنی و بازگشت به ماشین و استارت زدن برای انواع بستنی ثبت كرد. این مشاهده و ثبت اتفاق‌ها و مدت زمان آن‌ها، نكته جالبی را به او نشان داد: بستنی وانیلی پرطرفدار و پرفروش است و نزدیك در مغازه در قفسه‌ها چیده می‌شود؛ اما دیگر بستنی‌ها داخل مغازه و دورتر از در قرار می‌گیرند. پس مدت زمان خروج از خودرو تا خرید بستنی و برگشتن و استارت زدن برای بستنی وانیلی كم‌تر از دیگر بستنی‌هاست.
این مدت زمان مهندس را به تحلیل علمی موضوع راهنمایی كرد و او دریافت پدیده‌ای به نام قفل بخار (Vapor Lock) باعث بروز این مشكل می‌شود. روشن شدن خیلی زود خودرو پس از خاموش شدن، به دلیل تراكم بخار در موتور و پیستون‌ها مساله‌ی اصلی شركت، پونتیاك و مشتری بود.

مرجع: http://www.zahra-hb.com/2007/06/10/chinese-malay-girl

گزیده:

“The difference between theory and practice is that in theory, there is no difference between theory and practice, but in practice, there is.”   Jan van de Sneptscheut

Being Your Own Boss—Part I: The Ideal Job 

WATTS S. HUMPHREY

This is the first of a series of columns on our work as developers and how we can have truly satisfying jobs. This first column in the series discusses ideal jobs, what developers like about their work, and what they find annoying and unpleasant. It then describes how the developers’ and managers’ views on project success differ and what this means for both developers and their organizations. In subsequent columns, I will discuss how to turn almost any job into an ideal job, some of the issues you will face in trying to do so, and the level of support you will need from your managers and peers to be successful. While there are a few basic conditions that must be satisfied before you can expect to transform any job into this ideal, it is surprising how many jobs can be rewarding when you approach them in the right way.

Job Satisfaction

In discussing job satisfaction, we must first answer the question: “Satisfaction for whom?” One would expect the characteristics of a satisfying job to be different for the person doing the job and for the person for whom it is done. However, there is one condition that is common: the job must have been a success. This, of course, leads to the next question: “How do managers and developers view project success?”

This question has been researched by Kurt Linberg [Linberg 99]. He studied the views of developers about project success for his PhD dissertation. In this study, he asked groups of developers to identify the most successful and least successful jobs on which they had worked. Then he examined the characteristics of the most successful and least successful projects.

Successful Projects

From the developers’ perspectives, the most successful projects had three common characteristics:

Some typical developer views about these successful jobs were that

• the product was well designed and implemented
• it was well tested
• the team members enjoyed working with each other
• they didn’t feel pressured by management

In addition, as long as the project manager protected the team, conflicts with other groups or with senior management didn’t seem to bother the team members. They also thought that the work was innovative, that there was a high level of trust among the team members and with the project manager, and that the team was highly motivated.

In general, the developers attributed their high levels of motivation to five things:

1. a sense of making a contribution
2. an orderly and well-managed working environment
3. frequent celebrations of even small successes
4. positive feedback from both management and marketing
5. the autonomy to do the job in the way that they thought best

It didn’t seem to matter how important the project was to the organization or how well the team worked with other groups. In fact, it didn’t even matter whether the job was completed on time and within its budget.

Unsuccessful Projects

Conversely, the team members viewed the least successful projects as unrewarding, as  having poorly defined requirements, and as having inconsistent or even nonexistent marketing support. Typically, these worst performing projects were perceived as

• not achievable from the outset
• under excessive management pressure
• requiring unreasonable levels of overtime
• technically frustrating
• having frequent conflict among team members
• operating in a chaotic environment

In summary, the developers’ views of project success were largely independent of cost or schedule performance. The team members viewed a project as successful if it was a rewarding and enjoyable experience, even if it was late and over budget. In other words, a successful project was a personally satisfying project.

Management’s Views of Project Success

Linberg also found that management’s views of project success or failure almost entirely concerned cost, schedule, and quality performance. Table 1 summarizes his findings on the definition of various levels of success or failure for both completed and cancelled projects [Linberg 99]. This study found that developers view some projects as successful even when management does not and vice versa. Having been a manager for many years and having seen how hard developers worked to meet their schedules, I thought this conclusion contradicted everything I have seen in more than 50 years of development experience. I have worked with hundreds of teams and supervised groups of thousands of developers who worked around the clock to meet their deadlines. Every team I have ever worked with has always made an extraordinary effort to meet cost and schedule commitments, and many of them were consistently successful in doing so.

A little reflection, however, shows that Linberg’s conclusions do not conflict with my experience. I never asked the teams how they viewed their projects. They were paid to meet management’s goals, and when they did, management was happy and everyone got paid. So, in summary, management views a project as highly successful if a team delivers a quality product on schedule and within its committed costs, regardless of how the team feels about the job. Conversely, development teams view projects as highly successful if they are professionally challenging and technically successful and if they provide a rewarding and personally satisfying working environment.

Common Management and Team Goals

While no rational managers would object if developers enjoyed their work, that is not one of the managers’ highest priorities. Similarly, developers universally would like to deliver quality products on schedule, and they even strive to do so, but they do it because they know it is their job. What they really want, however, is to have a rewarding experience.

While these views don’t necessarily conflict, they are not mutually supportive. This situation is what is called cognitive dissonance, where our views of reality differ from what we experience. In the case of a project, the developers know what success feels like. Many of them have experienced it on sports teams where a winning performance is an exhilarating experience, the coach congratulates the players, and the fans cheer. Everybody then helps in the celebration.

But development is different from competitive sports. Developers know that the managers’ kind of success is what the organization wants, and that what developers value most is not a management priority. Sometimes the team wins and nobody seems to care, and other times, it feels as if the team loses but management cheers. Cognitive dissonance is demotivating and debilitating; it is not the stuff that builds winning teams or ideal jobs.

Congruent Management and Team Goals

This raises the next question: “What would happen if the managers’ and developers’ views of project success reinforced and supported each other?” One team’s experiences illustrate what could happen. On their last project, members of this team had put in more than 70-hour weeks, worked under enormous pressure, and managed to deliver their product to test on time. Testing, however, took longer than anyone had expected, and the product was delivered late. It was delivered, however, and at the time I met with the team, it was being installed by the users. While this job wasn’t a complete failure in Linberg’s terms, it certainly wasn’t a big success from either management’s or the team’s perspective.

On the next project, however, the team members had a realistic plan; they did high quality work; they had capable leadership; they had clear, agreed-upon goals; and they believed that the team owned the project. This was their job and they were going to make it a success both for the team and for the business. They not only delivered their product to test on time, but it was of such high quality that testing was finished early. They only worked 45-hour weeks and were home for dinner with their families every night. They said it was the best project they had ever worked on, and management was full of praise.

How did they do it? The answer is that they and their management made a real effort to make this project a success for both the developers and the managers. More on how to do this in the June column.

مرجع: http://www.sei.cmu.edu/news-at-sei/columns/watts_new/watts-new.htm

گزیده:

"Some people can't believe in themselves until someone else believes in them first."
- Good Will Hunting

دوست خوبم، علی (آدمیات)، میخواهد دیگر ننویسد:

این آخرین یاداشت این وبلاگه

نوشتن اینجا دیگه برام خیلی سخته

 

از همتون تشکر می‌کنم:

هم از دوستانی که اومدن و با نوشتن نظرشون افق‌های جدیدی به روم باز کردن

هم از رفقایی که دورادور حرفشون رو گفتن و راهنماییم کردن

و هم از دوست عزیزی که باعث شد یه مدت با شور بیشتری بنویسم ... 

برایش کامنت گذاشتم تا شاید از تصمیم منصرفش کنم. نمیدانم سودی خواهد داشت یا خیر. از دوستان مشترک من و علی خواهش میکنم که با گذاشتن کامنت ایشان را از این حرکت غیرفرهنگی! منصرف کنند. چرا که مطالب وبلاگشان بسیار خواندنی و نشان از روح لطیف و عمق نگاهش دارد.

دوست عزیزم آقای علی عبداللهی مطلبی در وبلاگشان با عنوان "شرکتی که بالاخره ورشکست شد" قرار داده‏اند که خواندنش واقعاً هر انسانی را آزرده می‏کند. از آنجا که وضعيت روحی دوست علی، کاملاً برایم قابل لمس بود(چرایش بماند!)، نزدیک بود زار زار گریه کنم . به خصوص  با این جمله که:
"این بار که پیش دوستم بودم میگفت : میروم یک دانشگاه و میشوم هیئت علمی و درس می گویم. شاید دانشجویانم روزی لذت کار فنی کردن را بهتر بچشند و به آنچه خود آرزویش را داشتم،برسند."

گزیده:

ببار ای ابر بهار
ببار ای بارون ببار
با دلم گریه کن خون ببار
در شبای تیره چون زلف یار
بهر لیلی چو مجنون ببار ای بارون

آقای داریوش سروری لطف کرده و آدرس کتاب را در کامنتها اعلام نموده بودند که جای بسی تشکر دارد.

از نرگس عزیز هم به خاطر لطف و پیگیریشان، ممنونم.

http://rapidshare.com/files/32829523/020189551X.rar

گزیده:

I know I have a heart because I feel it breaking.

from: Wizard of Oz

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

Planned and Evolutionary Design

For this paper I'm going to describe two styles how design is done in software development. Perhaps the most common is evolutionary design. Essentially evolutionary design means that the design of the system grows as the system is implemented. Design is part of the programming processes and as the program evolves the design changes.

In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on.

Planned Design is a counter to this, and contains a notion born from other branches of engineering. If you want to build a doghouse, you can just get some wood together and get a rough shape. However if you want to build a skyscraper, you can't work that way - it'll just collapse before you even get half way up. So you begin with engineering drawings, done in an engineering office like the one my wife works at in downtown Boston. As she does the design she figures out all the issues, partly by mathematical analysis, but mostly by using building codes. Building codes are rules about how you design structures based on experience of what works (and some underlying math). Once the design is done, then her engineering company can hand the design off to another company that builds it.

Planned design in software should work the same way. Designers think out the big issues in advance. They don't need to write code because they aren't building the software, they are designing it. So they can use a design technique like the UML that gets away from some of the details of programming and allows the designers to work at a more abstract level. Once the design is done they can hand it off to a separate group (or even a separate company) to build. Since the designers are thinking on a larger scale, they can avoid the series of tactical decisions that lead to software entropy. The programmers can follow the direction of the design and, providing they follow the design, have a well built system

Now the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).

Furthermore there's often a cultural problem. Designers are made designers due to skill and experience, but they are so busy working on designs they don't get much time to code any more. However the tools and materials of software development change at a rapid rate. When you no longer code not just can you miss out on changes that occur with this technological flux, you also lose the respect of those who do code.

This tension between builders and designers happens in building too, but it's more intense in software. It's intense because there is a key difference. In building there is a clearer division in skills between those who design and those who build, but in software that's less the case. Any programmer working in high design environments needs to be very skilled. Skilled enough to question the designer's designs, especially when the designer is less knowledgeable about the day to day realities of the development platform.

Now these issues could be fixed. Maybe we can deal with the human tension. Maybe we can get designers skillful enough to deal with most issues and have a process disciplined enough to change the drawings. There's still another problem: changing requirements. Changing requirements are the number one big issue that causes headaches in software projects that I run into.

One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won't help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard.

Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.

So all this makes planned design sound impossible. Certainly they are big challenges. But I'm not inclined to claim that planned design is worse than evolutionary design as it is most commonly practiced in a "code and fix" manner. Indeed I prefer planned design to "code and fix". However I'm aware of the problems of planned design and am seeking a new direction.

آدرس مقاله:

http://martinfowler.com/articles/designDead.html

گزیده:

She said that she usually cried at least once each day not because she was sad but because the world was so beautiful and life was so short.
Brian Andreas - Reference: Booch Blog

حکایت زير را دوست خوبم، آرش، برايم فرستاده که بسيار آموزنده است. حيفم آمد، در اينجا نياورمش.

روزي روزگاري يه خري افتاد توي يه چاه و شروع کرد به عرعر کردن که منو در بيارين ..يالا. کشاورزي که صاحب اين خر عرعرو بود، خيلي سعي کرد که يه کاري بکنه . ولي نشد که نشد . خره رفته بود ته چاه و در نمي يومد . عرعرش هم قطع نميشد . آقا کشاورزه با خودش فکر کرد که خوب اين چاهه رو خيلي وقته که ميخوام پٌٍرش کنم ، خره هم که پيره  و ارزش اين که بخوام بيارم بيرون و دوا درمونش کنم نداره، پس بيخيال خر. کشاورزه از همه همسايه هاش خواست که بيان و بهش کمک کنن . اونام هر کدوم يه بيل آوردن و شروع کردن خاک ريختن تو چاه. خره که فهميده بود چه بلايي داره به سرش مياد.شروع کردعرعرهاي جانسوز سر دادن. از همون هايي که دل هر خري کباب ميشد از شنيدنش . پس از يه مدت کوتاهي يهو ساکت شد جوري که همه تعجب کردند. ولي بازم چند تا بيل ديگه خاک ريختن و ديدن نخير صدا از ديوار در مياد ولي از آقا(يا خانوم) خره نه. کشاورزه يه نيگاهي تو چاه کرد ببينه چي شده که هيچ خبري از عرعره خره نيست که ديد . عجب خر پر آي _کيويي بوده . اين خره و تا حالا استعدادش کشف نشده بوده. هر بيل خاکي که تو چاه ريخته ميشده . مي ريخته پشت کمر خره . اونم خودشو مي تکونده و ميرفته روش  مي ايستاده مث پله.هر چي کشاورز و همسايه هاش خا ک مي ريختن تو چاه، خره خودشو تکون ميداده و مي رفته روشون مي ايستاده و هي يه پله بالا ميومده تا اين که رسيد به سر چاه و يه جفتکي زد و خندون شروع کرد يورتمه رفتن. به اين ميگن خر.

زندگي هر روز ممکنه خيلي مشکلات براي شما به همراه داشته باشه مث همون بيل هاي خاک . مصائب از همه طرف رو سرتون هوار بشه . ولي اين که بتونين پيروز از تو چاه مشکلات در بياين که مشکلات رئ سعي کنين از رو دوشتون بر دارين و يه قدم و پله بياين بالاتر.
ما ميتونيم از عميق ترين چاه هاي زندگي هم به سلامت خارج بشيم به شرطي که از هر مشکلي يه تجربه و نردبون بسازيم براي پيشرفت و شکوفايي. هر کدوم از مسائل زندگي  ميتونه به مثابه يه پله و وسيله اي براي رسيدن به هدف نهايي ما باشه. فقط نا اميد نشو و از تلاش دست بر ندار . خودتو بتکون و يه پله برو بالاش.

گزيده:
آدم مؤفق کسی است که با تکه آجرهايی که به سمتش پرتاب می‏شود، خانه‏ای برای خود می‏سازد.

ماهنامه Rational Edge مقاله نسبتاً جالبی در مورد نحوه تحقق‏بخشی موارد کاربرد در شماره اخير آورده است. مهمترين بخش آن آورده Best Practice هايی در اين مورد است که عبارتند از:

    *  Design use-case realizations in team sessions.
    * Communicate design ideas using interaction diagrams.
    * Apply design and responsibility patterns.
    * Code responsibility abstractions during design sessions.
    * Get clearance before making major design changes.
    * Audit changes that occurred during design implementations.

آدرس مقاله به شرح ذيل است.  http://www.ibm.com/developerworks/rational/library/jun07/cuellar/index.html

گزیده:

Sometimes i wish that i had never met you, so i could go to sleep at night not knowing there was someone like you out there.
- from Good Will Hunting movie

بالاخره ويرايش سوم کتاب "تحليل و طراحی شیءگرا با کاربردها" از پير دنيای مهندسی نرم‏افزار، گريدی بوچ به بازار آمد. واقعاً بيراه نگفته‏ام، که اين کتاب، کتاب مقدس علاقمندان به شیءگرايی در دهه آخر قرن بیستم  و حتی بعد از آن بود. نسخه اول آن سال 1991 و ويرايش دوم آن در سال 1994 به بازار آمد. نسخه اول آن را از آقای مهندس رامين عرفانيان دريافت کردم. فوق‏العاده پرمحتوا، سخت و جذاب.
ويرايش جديد آن با اضافاتی که در پايين آمده، همراه بوده است. خبر نسخه جديد آن را اولين بار در وبلاگ دوست عزيز، آقای مهدی خواجه ديدم و فی‏الفور آن را تهيه و مطالعه کردم. مطالعه آن را از دست ندهيد.

• An introduction to the new UML 2.0, including the notation's most fundamental and advanced elements with an emphasis on key changes
• New domains and contexts
• A greatly enhanced focus on modeling--as eagerly requested by readers--with five chapters that each delve into one phase of the overall development lifecycle.
• Fresh approaches to reasoning about complex systems
  An examination of the conceptual foundation of the widely misunderstood fundamental elements of the object model, such as abstraction, encapsulation, modularity, and hierarchy
• How to allocate the resources of a team of developers and manage the risks associated with developing complex software systems
• An appendix on object-oriented programming languages
• This is the seminal text for anyone who wishes to use object-oriented technology to manage the complexity inherent in many kinds of systems.
  
  

آدرس کتاب: http://www.awprofessional.com/bookstore/product.asp?isbn=020189551X&rl=1

گزیده:

It's all very well in practice, but it will never work in theory.

anonymous management maxim