اگر بپرسيد كه طي چندين ماه اخير، بيشتر وقتتان را صرف چه كاري كرده‌ايد–به غير از انجام امور شغلي-، خواهم گفت: تدوين كتاب. آقاي گلدرات در مقدمه كتاب «هدف» نوشته است كه 13 ماه را به همراه يك نويسنده ماهر صرف نوشتن كتاب كرده است. در آن هنگام برايم غيرقابل باور بود. اما حالا بر اين باورم كه نوشتن كتابي به زيبايي كتاب «هدف»، زماني بيش از اين مدت نياز دارد.

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

از 10 فصل كتاب، 4 فصل آن بازنگري شده و آماده بازنگري خارجي است. يك فصل نيز نياز به كمي تغييرات و تصحيح دارد. مطالب 3 فصل ديگر نيز نوشته شده و در صف بازنگري است. مطالب 2 فصل هنوز كامل نشده است.

اكنون زمان مناسبي است كه مذاكرات با ناشرها را شروع كنيم. اميدوارم كه مثل عارضه‌هاي مدل آبشاري (waterfall)، بي‌اطلاعي از روند چاپ و انتشار كتاب، موجب به هم ريختگي در برنامه‌ريزي و مطالب كتاب نگردد. همزمان صحبت‌هاي اوليه‌اي را براي جذب حمايت‌كننده مالي (اسپانسر) شروع كرده‌ايم ولي هنوز خيلي جدي نشده است.

با تمام دشواري‌هاي نوشتن كتاب، اعضاي تيم حس خوشايندي از اين كار دارند. از هر دوي آنها سپاسگزارم كه كمك كردند با وجود مشغله زيادم، تجربه‌ها و آموخته‌هايم را در چارچوبي مشخص و سازمان‌يافته مدون نمايم.

گزيده:

پيروزي آموزگار شايسته‌اي نيست. رابرت كيوساكي

1: Robert C. Martin
Agile Software Development: Principles, Patterns and Practices

2: Martin Fowler
Refactoring: Improving the Design of Existing Code

3: Mike Cohn
Agile Estimating and Planning

4: Mike Cohn
User Stories Applied: For Agile Software Development

5: Andrew Hunt, David Thomas
The Pragmatic Programmer: From Journeyman to Master

6: Alistair Cockburn
Agile Software Development: The Cooperative Game (2nd Edition)

7: Craig Larman
Agile and Iterative Development: A Manager’s Guide

8: Kent Beck
Extreme Programming Explained: Embrace Change (2nd Edition)

9: Jim Highsmith
Agile Project Management: Creating Innovative Products

10: Paul Duvall, etc.
Continuous Integration: Improving Software Quality and Reducing Risk

11: Mary Poppendieck, Tom Poppendieck
Lean Software Development: An Agile Toolkit

12: Ken Schwaber
Agile Project Management with Scrum

13: Ken Schwaber, Mike Beedle
Agile Software Development with Scrum

14: Alistair Cockburn
Crystal Clear: A Human-Powered Methodology for Small Teams

15: Venkat Subramaniam, Andy Hunt
Practices of an Agile Developer: Working in the Real World

16: Kent Beck
Test Driven Development: By Example

17: Johanna Rothman
Manage It!: Your Guide to Modern, Pragmatic Project Management

18: James Shore, Shane Warden
The Art of Agile Development

19: Ron Jeffries, etc.
Extreme Programming Installed

20: Esther Derby, etc.
Agile Retrospectives: Making Good Teams Great

Reference: www.noop.nl

گزیده:

مهم نيست كه دمو (نسخه نمایشی) تا قبل از ارائه تا چه حد عالي کار می‌کند. موقع ارائه به حضار، احتمال بي‌نقص بودن آن برابر است با عكس نسبت تعداد حضار به توان مبلغ پول هزينه شده. مايك گيبز

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

در راه میگفت آن اوایل که من به ایران آمدم خواستند مثلا من رو تحویل بگیرن، بردند و رییس فلان بخش در فلان جا کردند. اتاقی بود که قرار بر مستقر شدن چندین نفر در آن بود که من میز اول را انتخاب کردم. از طرف بخش اداری آقایی آمد گفت: جناب دکتر اینجا که نمی شود! شما رییس هستید و شان و مقامی دارید و باید بروید آن ته! روی آن میز آخر آنجا بنشینید! مجبور به قبول شدم و رفتم! آن ته، در دیگری بود که آن هم به اتاق راه داشت و البته بسته بود. مدتی گذشت و بنا به تغییر چیدمان آن طبقه مجبور شدند در اول را ببندند و دری که من کنار آن مینشستم را باز کنند، باز من شده بودم نفر اول بعد از درب ورود! همان آقای قبلی آمد گفت جناب دکتر شما باید بروید آن ور، آن ور سالن ( همان جا که من اول ورود انتخاب کرده بودم) بنشینید! برای شما بد است اینجا، شما رییس هستید، شان و مقامی دارید!!! من خنده ام گرفته بود که ریاست من را این “در” تعیین میکرد! فقط این “در”! »

مرجع: نغمه ی سکوت
با سپاس فراوان از شبنم صبجگاهی

گزیده:
چه كسي جاي او را پر خواهد كرد؟

کارو لوکس یا لوکاس (۱۳۲۸ در اصفهان – ۱۷ تیر ۱۳۸۹ در تهران) یک دانشمند از ارمنیان ایرانی و از پژوهشگران به‌نام سیستم‌های هوشمند در ایران بود.

در سال ۱۳۲۸ خورشیدی در اصفهان زاده شد. وی مدرک کارشناسی ارشد مهندسی برق را از دانشگاه تهران (۱۹۷۳ میلادی) دریافت کرد و در سال ۱۹۷۶ میلادی مدرک دکترای خود را از گروه مهندسی برق و علوم کامپیوتر دانشگاه برکلی با گرایش مهندسی کنترل دریافت کرد.

زمینهٔ پژوهش‌های او پیش‌بینی سری‌های زمانی، مدل‌های عاطفی و منطق فازی است. او در سال ۱۳۸۵ خورشیدی به عنوان چهره ماندگار شناخته شد. وی همچنین به عنوان او پدر علم رباتیک ایران شناخته می‌شود.

کارو لوکس در ۱۷ تیر ۱۳۸۹ درگذشت.

مرجع: ویکی پدیا

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

As any experienced computer programmer knows, there are unwritten laws that govern software development. However there are no penalties for breaking these laws; rather, there is often a reward. Following are 21 Laws of Computer Programming:
1. Any given program, once deployed, is already obsolete.
2. It is easier to change the specification to fit the program than vice versa.
3. If a program is useful, it will have to be changed.
4. If a program is useless, it will have to be documented.
5. Only ten percent of the code in any given program will ever execute.
6. Software expands to consume all available resources.
7. Any non-trivial program contains at least one error.
8. The probability of a flawless demo is inversely proportional to the number of people watching, raised to the power of the amount of money involved.
9. Not until a program has been in production for at least six months will its most harmful error be discovered.
10. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
11. The effort required to correct an error increases exponentially with time.
12. Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.
13. Any code of your own that you haven’t looked at in months might as well have been written by someone else.
14. Inside every small program is a large program struggling to get out.
15. The sooner you start coding a program, the longer it will take.
16. A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
17. Adding programmers to a late project makes it later.
18. A program is never less than 90% complete, and never more than 95% complete.
19. If you automate a mess, you get an automated mess.
20. Build a program that even a fool can use, and only a fool will want to use it.
21. Users truly don’t know what they want in a program until they use it.

Reference: 21 Laws of Computer Programming

Quote:
It’s better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive. Steve McConnell

While everyone knows the theoretical limitations of testing, in practice we devote considerable effort to this task, and would consider it foolish or downright dangerous to skip testing.
Other verification techniques, such as static analysis, model checking and proofs, have great potential, but it is unlikely they will ever fully remove the need for testing. In the meantime we need to understand the scope and limitations of tests, and perform them right.
The seven principles that follow emerged from experience of studying testing and developing automated testing tools (AutoTest, CDD) over the past few years.

Principle 1: Definition of software testing
To test a program is to try to make it fail.

Principle 2: Tests versus specs
Tests are no substitute for specifications. One can derive tests from specifications, not the other way around.

Principle 3: Regression testing
Any failed execution must yield a test case, to remain permanently part of the project’s test suite.

Principle 4: Applying oracles
Determining success or failure of tests must be an automatic process.

Principle 4 (variant): Contracts as oracles
Oracles should be part of the program text, in the form of contracts. Determining success or failure of tests should be an automatic process consisting of monitoring contract satisfaction during execution.

Principle 5: Manual and automatic
An effective testing process must include both manually and automatically produced test cases.

Principle 6: Empirical assessment of testing strategies
Evaluate any testing strategy, however attractive it may appear in principle, through objective assessment based on explicit criteria and a reproducible testing process.

Principle 7: Assessment criteria
The most important property of a testing strategy is the number of faults (or, if faults are not directly measurable, failures) it uncovers as a function of testing time.

Reference: Bertrand Meyer

Quote:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Martin Fowler (Refactoring: Improving the Design of Existing Code)

به پیشنهاد آقای مهندس هادی تصميم گرفته‌ام تدريس دوره‌‌اي را در شركت فراتر از دانش شروع كنم.
اين دوره كه با عنوان “متدهاي چابك” (Agile Methods) برگزار خواهد شد به كاربرد و وجه تمايز اين دسته از متدها اختصاص خواهد داشت.
اهداف كلي و مياني، چارچوب، منابع، مطالب اصلي سيلابس،كليات موردهاي مطالعاتي و ابزارها مشخص شده است.

گزيده:

A common problem in many organizations is that undisciplined “ad-hoc” teams often claim to be agile, because they’ve read an article or two about agile development, and interpret agility to mean any cool, liberated form of undocumented software creativity. These ad-hoc teams often run into trouble, and give actual agile teams a bad name.
Scott Ambler