دیروز وبلاگ سماموس یک ساله شد.
صبح روز جمعه سیزدهم مردادماه سال 1385 ساعت 9 صیح، چیزی که مدتها طرحش را در ذهنم مرور کرده بودم، انجامش دادم.  ایجاد وبلاگ و نوشتن در آن.
فکر نمی‏کردم بتوانم یک سال این کار را به صورت مستمر ادامه بدهم. ولی الان حس خوبی دارم و حتی تجربه بسیار زیادی. هر چند ماحصل کار آن چه که دلم می‏خواست نشده است، ولی از هیچ، جلوترم. تجربه خوبی است، شما هم امتحان کنید.

سماموس، تولدت مبارک.

گزیده:

I don't regret the things I've done, but those I did not do.
- From Empire Records

لینک مطالب زیر را از وبلاگ رادمان که هر چند وقت یک بار آن را مطالعه می‏کنم، پیدا کرده‏ام.

1-  نزول به رتبه 69 جهان در حوزه IT
"دكتر منصور كبگانيان، معاون پژوهشي و فن‌آوري وزارت علوم، تحقيقات و فن‌آوري در گفت‌وگو با خبرنگار «فن‌آوري» خبرگزاري دانشجويان ايران (ايسنا) اظهار كرد: متاسفانه خبري مبني بر رتبه IT ايران دريافت كرديم كه براساس گزارش نشريه اكونوميست در ميان 69 كشور جهان رتبه آخر را كسب كرده‌ايم و اين مساله را از ديد شوراي عالي عتف كه به توسعه علم و فن‌آوري و حركت در حوزه‌هاي دانش توجه دارد، نگران كننده است."

2- نقدي بر دستمزد كارشناسان نرم افزار
"چند سالي است كه شركت ثناراي به سفارش سازمان‌هاي دولتي مربوط نرم افزاري مانند شوراي عالي داده ورزي يا قرينه آن در وزرت ارتباطات اقدام به آمار گيري از چند شركتي مي‌نمايد كه حاضر به همكاري و اطلاع رساني مي‌شوند. ساير شركت‌هايي كه در اين همه پرسي شركت نمي‌كنند دلايلي براي خود دارند كه خارج از بحث ما است. آخرين گزارش تهيه شده مربوط به سال 1384 است و هنوز خبري از گزارش سال 1385 و آمار گيري آن نشده است.
از قيمت‌هاي ارايه شده و ظاهر موارد ارايه شده برمي‌آيد كه اين قيمت‌ها هم به سرنوشت قيمت‌هاي بعضي از نظام‌هاي صنفي مانند پزشكي دچار شده و براي كنترل قيمت‌ها چيز ديگري هم با واقعيت مخلوط شده است. به عنوان نمونه به چند مورد زير كه ميانگين قيمت‌ها قبل از كسورات مختلف مانند ماليات و بيمه است دقت فرماييد:

ارقام بالا كليه درآمد كارشناس از شركت قبل از كسورات است و كليه كسورات قانوني نيز از آن كسر خواهد كرديد. معلوم نيست مدير پروژه‌اي كه ساعتي 10 هزار تومان مي‌گيرد يا مشاوري كه ساعتي 12 هزار تومان مي‌گيرد داراي چه مدرك و تجربه‌اي هستند. طراحي كه ماهانه 783 هزار توام حقوق بگيرد يا داراي مدرك نامربوط است يا كمتر از 5 سال تجربه دارد كه در اين صورت طراح نمي‌شود يا طراح ميشود ولي نتيجه كار براي كارفرما فاجعه آميز خواهد بود. وضعيت كارشناس شبكه درجه 1 بدتر از بقيه است. اگر به هزينه‌هاي ارايه شده از طرف نظام صنفي رايانه براي خدمات شبكه توجه نماييم چند برابر بيش از ارقام شركت ثناراي است.
متاسفانه اين ارقام ممكن است براي پروژه‌هاي دولتي استفاده شوند و هزينه پيمانكاران حرفه‌اي با آن سنجيده شود. اگر چنين شود، انتظار نداشته باشيم كارها با كيفيت انجام شوند. مثال ما ايراني‌ها است كه هر چه پول بدهي آش مي‌خوري. مشكل فرار نيروي‌هاي تخصصي از كشور نيز مزيد بر علت مي‌شود. آقايان بنشينند و منصفانه و عميق به قيمت‌ها توجه كنند. ديگر زمان اول انقلاب گذشته است كه انتظار داشته باشيم همه براي رضاي خدايي كه ما تعريف مي‌كنيم جان بدهند و براي آزادي قدس همه چيز خود را فدا كنند. اكثر قريب به اتفاق نيروي‌هاي كارشناسي ما حتي كساني كه سوابق مذهبي هم دارند ديگر از اين فكرها نمي‌كنند و اگر بتوانند براي مهاجرت اقدام مي‌كنند.
اگر اين ارقام را بخواهيم رعايت كنيم، هيچ كارشناس نرم‌افزار را نمي‌توانيم بيش از چند سال در جايگاه خود حفظ نماييم و بايد از بي‌تجربه‌ها يا كم تجربه‌ها يا ساير رشته‌هاي نامربوط استفاده نماييم كه نتيجه كار براي كارفرماي بدبخت از ابتدا معلوم است. و اگر شخصي به سواد و تجربه كافي يا زياد دست پيدا كرد ديگر قابل تحمل نيست و بايد بجاي او يك كارنشناس قرار داد.
اگر مي‌خواهيم واقيت را بدانيم بايد نهادي واقعا بي‌طرف براي هر رشته از اين صنعت قيمت‌هاي جداگانه استخراج كند و به تاييد تك تك اعضاي آمار گرفته شده برساند. آمارهاي فرمايشي و رتوش شده خيانت به مردم اين كشور است. اگر نظام صنفي رايانه بتواند بدون تاثير پذيري از دولت و هر سازمان ديگري اين كار را انجام دهد، شايد بهترين گزينه باشد. با توجه به هزينه اندك اين آمار گيري خوب است كه خود راسا عمل نمايد و كاري كه در زمينه شبكه انجام داده است در ساير موارد نيز به انجام رساند. بالاخره هزينه عضويت اعضا در اين زمينه هم مي‌تواند خرج شود و چه چيزي بهتر از اين كار؟ "

عریضه: هی بازم بگین می‏خوایم بریم عروسک‏ فروش، گاودار، گل فروش و میوه فروش بشیم !

گزیده:

Forever is a long time and time has a way of changing things.
- "The Fox and The Hound

To rewrite or not to rewrite, that is the question
People seem to have given up completely on the notion of rewriting software. This is a shame since so much software needs rewritten, but it’s understandable since so many software rewrites fail. The decision on whether or not to rewrite is a complex one, and most companies will usually take the easy short-term path of attempting to fix the software in a piecemeal fashion. Unfortunately, this also fails most of the time, but at least companies don’t feel so bad about it since they usually end up only slightly worse off than when they started. Although I discussed this a bit in my “Fear of code” article, I decided go ahead and put together a more elaborate set of decision points on whether or not to rewrite a major piece of software.

Can it be rewritten in less than 2 months? If the answer is yes, you’re not within my definition of a “major piece of software”. Read on to help give you some perspective, but go ahead and rewrite if you think it will make your life a lot easier and treat the other rules with a grain of salt.
Do you honestly believe that if you rewrote it without adding any features the resulting code would be 33% smaller than the current code? If the answer is no, it’s not a candidate for a rewrite. Things are not so hopelessly wrong that they can’t be improved in-place. Things must be horribly bad before a complete rewrite is in order. Look for pieces of the code that can be rewritten (again looking for that magical 33% smaller boundary). Sometimes a piece of code makes every additional piece of code that much harder to write, but if the new code is dramatically harder to write then it’s probably getting badly bloated as a result. While there are kinds of complexity that do not create code bloat, these are the exception and not the rule and most of them can be dealt with via wrapping (hiding) the complex code in a layer.
The types of situations that require a full rewrite are the ones where a critical tool was used that was completely wrong for the job, or where key assumptions were made (possibly many of them) that later turned out wrong, or where complex business logic has become so hopelessly spread out through the edges of the application that every new feature requires massive cut and paste. If it feels like a project is hopelessly broken but you don’t see your rewritten version being 33% smaller then think harder about the WAY you would rewrite it and try to find a way to make it cleaner. Once you’ve found a way to drastically reduce the fat in the application you have understood the root cause of your problems well enough to justify a rewrite.
If you can envision doing away with half the code or more then you have an excellent candidate for a rewrite. Work hard to get the rest of the factors in line.
Can the code be done in less than 10 months? If the answer is no then you can’t do it. Almost no organization will keep a project alive for longer than about 10 months without seeing very strong evidence that it will succeed. If you believe it can be done in 10 months then it might take 16, but after 10 you’ll be close enough to get people believing. Notice I didn’t specify a team size, just a duration. You might be able to have a team of 20 working on a project for 10 months but you’ll never get a team of 2 for 100 months. One solution to this dilemma is to build a framework for the rewrite on a skunkworks basis in spare time or off hours. People only count the time from when they start investing in a project. You can also quietly bake some of this work in to the existing product so that some of the code will be in place and tested before the core reworking even gets discussed. Another solution is to think harder and find a way to get the value you need with less work.
Do you have a very senior sponsor who understands and believes in the project? If the answer is no then you can’t rewrite. There is no getting around this. I’ve tried. It can’t be done. You need a sponsor!
Can you get enough resources (even on a temporary basis) to support development on the old code base while the new code is written? If the answer is no you can’t rewrite. If the code is important enough to rewrite it’s important enough to need ongoing support. You can’t do both with the same people or the project will stretch to unacceptable lengths.
Is the project critically important to the company’s future? If the answer is no you can’t rewrite. Other projects will interject if this project is not vital. Large, nasty, but relatively unimportant software almost never gets rewritten. Of course larger companies consider MANY things critical to their future and are able to invest in rewriting them, but at some level people must believe the software is critical. It can’t just be an annoyance to developers.
Can the company go without a major release of the product for half the planned coding duration? If the answer is no you will probably (my first probably) fail. Even with parallel teams there will need to be a stoppage of major releases for a while as the new version gets shaken out.
Do you have anyone on the team who has successfully rewritten a major piece of software before? If the answer is no, get one or you can’t rewrite. Rewriting is not the same as other projects. It’s a specialized skill that balances design, code and testing with economics and politics. You need someone who has done it successfully before (even if they weren’t in charge).
This list is laughably oversimplified, but hopefully it gives you a few things to take in to account when considering a rewrite. How to rewrite is a topic I’ll leave for another day.

Reference: To rewrite or not to rewrite, that is the question

گزیده:

"When a defining moment comes along, you can do one of two things. Define the moment, or let the moment define you."
- From Tin Cup

همه چیزی رو در مورد علی‏آقا که حکم بزرگتر، معلم و استاد را برایم دارند، فکر می‏کردیم الا دیدن علی‏آقا در برنامه قویترین مردان ایران سال ۸۶.

علی آقا قلباً خوشحالم که ورزش را شروع کردی.

گزیده:

ز ورزش بود مرد را راستی              زسستی، کژی آید و کاستی

 

Watts Humphrey از چهره‏های بسیار معروف در دنیای مهندسی نرم‏افزار به خصوص در حوزه فرآیندهای تولید نرم‏افزار است. وی رهبر TSP:Team Software Process , PSP:Personal Software Processدر انستیتو مهندسی نرم‏افزار دانشگاه کارنگی ملون است. وی نوشتن در وبلاگی را شروع کرده بود که متأسفانه از ادامه نوشتن در آن منصرف شده است. علت آن را در زیر بخوانید که به نکات ظریفی در مورد نوشتن وبلاگ آن هم در حوزه تخصصی اشاره دارد. نوشته زیر مرا به یاد صحبتهای علیرضا انداخت.

This is my final weblog entry.
After several months of writing this weblog, I have concluded that it would take a great deal of effort to make the material interesting enough to attrack a reasonable number of readers. Unfortunately, I do not have the time to do that and so must regretfully sign off. My thanks to those of you who have contributed comments or read my rather limited efforts to produce a useful weblog.
Life is a learning process and I have learned that making the kind of contribution that would really attrack a broad readership is not a minor task. It would require a level of commitment that I simply cannot muster at this time.

Goodby and my thanks to you, my readers.
Watts Humphrey
July 30, 2007

گزیده:

We walk away from our dreams afraid we may fail, or worse yet, afraid we may succeed.
- Sean Connery in Finding Forrester

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

I was having a conversation with a friend of mine (we’ll call him Eric) about my article on rewriting software and he made an astonishing claim. “I think you low-balled the amount that the rewrite should reduce the code size. I’d be willing to bet that I could rewrite almost any piece of software in half the lines of the original. In fact, I’d take a fixed priced bid on a rewrite for anything up to a quarter million lines of code, get it done in a year, meet their coding standards, have 80% test coverage to boot, and do all the work by myself.” That was a bit hard to swallow. A quarter million lines rewritten in a year by one person? IBM once did a research report that indicates that the average developer writes about 10 lines of functional tested code in a day. Here was Eric telling me that he could reliably write tested code at a rate of closer to 1000 lines per day, nearly 100 times that average.
I took it as a bit of a boast, but Eric is really a pretty hard-core guy. He’s built at least six systems in the 100,000 to 250,000 lines of code range and he knows what it takes. He’s in my top 5 developers list and since I’ve worked with him quite a bit I know that he can crank out solid code consistently and at a speed that is fairly unbelievable. While I doubt his claim that he could rewrite most quarter-million line programs in a year (turning them into 125,000 line programs), I don’t doubt that he could do it in two. And I don’t doubt that the code would be a lot better off when he was done.
This brings me to the point of this article, that there is at least an order of magnitude of skill difference between the average programmer and the best programmer, and maybe even two orders of magnitude. I’ve made this observation to quite a few programmers and managers and in listening to people’s answers I’ve noticed the following:
   1. Everyone agrees that good developers are many times better than average ones, but people give widely different numbers from 4x to 100x.
   2. Everyone agrees that the worst programmers are a net negative (they actually slow a project down).
   3. The more complex the type of work the estimator does the higher the multiplier they choose. People who spend all their time writing small scale CRUD apps tend to pick numbers between 4x and 10x, but people working in extremely complex or performance critical domains pick numbers between 10x and 100x.
   4. Everyone agrees that larger teams are less effective (on a per person basis), but that you can have up to about five or six people working on a team before it starts to fall off in productivity
   5. Most people agree that there are some problems (especially some performance ones) that will NEVER be solved unless you have one really great engineer.
   6. Most people agree that the best coders are better at all aspects of the development life-cycle: analysis, design, coding, debugging (however you want to break it down).
   7. Most people agree that the code written by the best coders is smaller and contains fewer bugs per line than that written by average coders.
While a few people whose opinions I respect may quibble with some of these points, most people seem to accept them at some level, which begs a question: why aren’t the best coders paid more? A LOT more.
Let’s go back to Eric’s point. Let’s say a company has decided to rewrite some 250,000 line piece of code for some reason (usually because it’s broken), on the one hand they can choose to let their team of 10 average developers work on it for the next two years and end up getting it done and pay about $2.5M in fully loaded costs. Since they are average coders there will be a lot of bugs and while they may improve it somewhat, the improvement will be less than expected. What if they took Eric up on his offer, and let’s say (for the sake of argument) that Eric needs to bring in 2 equally stellar friends (Eric-2 and Eric-3). Anything a team of 10 average coders can do in two years the three Erics can do in one year. If you offered them $1.5M fixed for the whole contract they could walk away at then end of that year with $500k each (which is probably a tad bit more than their current salaries). The odds are that the final product would be better, smaller, faster, and more reliable as well. That’s just the kind of code that people like Eric tend to write. In fact, they HAVE to write better code or they couldn’t become an Eric. People who write bad code spend their lives fixing it. That’s one big reason they’re so slow.
This same kind of logic applies even more for moderately large projects (say 1-2 Million lines of code). A five or six person team of 99.7th percentile developers can write a project like this in less time than any team of 40 average coders. Who wouldn’t gladly pay them each $300,000/year each to get it done?
In practice, this turns out to be pretty hard to do. First, most companies can’t tell a 66th percentile developer from a 99th percentile one (some can’t even seem to tell the difference between a 50th percentile one and a 99th percentile one), so that makes this strategy pretty darn near impossible for them to carry out. Second, many of these companies haven’t the slightest idea how to use a top developer. They find ways to dump them in meetings, bother them with continual interruptions, and drown them in useless unproductive tasks. This is part of the reason they can’t tell them apart: they have an almost insidious ability to bring everyone back down into the big pile that is “average”. In these environments other engineers generally know the great developer is better than everyone else, but they have almost no idea just how much better they really are.
Actually, it’s nearly impossible for anyone to interview for the top one percent. There is too much distinction between programming skill and interviewing skill to have such a refined process. With work you can weed out bad and average engineers, but getting great ones is extremely hard. This means that the only reliable way to find the truly exceptional engineers is to know them. To have worked with them and seen them in action. Since you can’t interview for greatness there are two options left: The first approach is the Paul Graham approach, get them to do a startup for next to nothing and if they turn out to be great you’ll know it (even if the startup fails). The second approach is the buddy system: after being around the block for a while, call up the five best engineers you know and convince them to join you. Then, if you still need a few more, get them to call the five best developers they know. In short order you have a very strong team.
The buddy system has its limits. At most you probably can’t get more than fifteen or so people this way before the diffusion effect has moved you out of the top one percent and into the top ten percent. This assumes you have actually been around enough good companies to START in the top one percent. The bigger problem with the buddy system, though, is how to get those five people to join and what to do with them when you do. One possibility is to create a startup company. Unfortunately, startup companies have no guarantee of success, regardless of how good their engineers are. Lots of companies with mediocre engineers succeed while others with great engineers fail. Coding is only one small piece of the puzzle and many of your top coders know this. Another option would be to form a consulting firm, but consulting is a sales driven activity and just because you actually have a great team of six amazing coders doesn’t mean you can convince some large company to pay you $3M to write them a big piece of software. EVERY consulting company claims to have the world’s best coders. A company that can’t hire the top coders internally won’t be any better at selecting the top coders externally. Unless you have the contract in hand, getting the five best coders you know to join your team will be a bit of a struggle.
So maybe it’s a challenge to bring together a small group of top coders and guarantee that they get paid close to what they’re worth, but why can’t a really top coder just demand more from the company they are at? Wouldn’t the company pay a really large sum just to keep them? The answer is almost assuredly no. Let’s say the company is a big company with mostly mediocre coders. In that case they probably have fairly fixed salary structures with limited ability for a particular manager to pay much above or below the standard. Even if the manager would agree to pay $300,000 a year it would be virtually impossible for them to get approval. Also, it’s likely that the manager has only a fairly limited capacity to recognize the skill of the engineer. They may know the programmer is better, but they really can’t quantify how much better so they aren’t going to be able to recognize that skill with a commensurate compensation package.
Small companies can’t do it either. Even if the manager recognizes that the developer is really great, there is a good chance that all the developers in the company are pretty good anyway. So while they may be 10x or 15x better than the average coder overall, they may only by 2x or 3x better than the average coder at the company. Also, if they agree to pay more there is the very real chance that everyone in the company will soon be asking for more, and that’s not something they can afford. It’s better to lose the one great coder than to have to pay the other twenty 25% or 50% more. The last reason the great developer can’t get 3x more than the people around him is that he probably doesn’t know just how great he is. Really great developers know they are good, but very few have the slightest idea how much better they are than their peers.
In the end, this means that really great coders will keep getting paid less than they are worth and average ones will keep getting paid more, so the economic benefits of great skill will go primarily to the companies with the best employees and not to the employees themselves. Is it fair? No, but it is how the market works. Who ever said that fair can or should be factored into the equation. Sure I’d love to get that phone call asking me to get the five best coders I can find to write a million line application for $3M dollars, but I’m certainly not going to waste any time sitting by the phone waiting for it to ring!

برخی از نظرات جالب در مورد این نوشته:

Peter Says:
I’m a Ph.D student at MIT. What I’m finding is that the top people here do one of three things. One group will start businesses (or consulting work) where they can be paid on par with productivity. Another, but shrinking, group will go into acadamia. This group is shrinking because the odds of tenure are pretty low. Others quit programming, and work in the finance/management (venture capital, management consulting, investment banking, etc.). Very few of the top people end up in industry. This is moving back further and further — this used to happen mostly to people in graduate school or even industry, but now, increasingly, technical undergrads no longer want to go into engineering. For high levels of intelligence, the payoff just isn’t there, in the way that it is in financial and management sectors.
Industry acts as an insurance company. It compresses the pay range. If you’re unproductive and generally suck, your salary goes up to some minimum. If you’re highly productive, it drops, often by a factor of 10x. This absorbs risk — you don’t know which of the things you’ll do will have a payoff (often, good engineers will work on unprofitable projects), which is nice. It does, however, strongly discourage great people for working in industry.
Also, the industry keeps complaining about a labor shortage, while employees about a job shortage. I finally got to the bottom of this. Industry is finding a shortage of good people, whereas crappy people can’t get jobs. Universities, with dropping enrollment in engineering programs, are lowering standards so that more people can train to be engineers. Poor engineers enter the job market, can’t get jobs, and when they do, they lower the overall pay range. As a result, good people see low wages and a job shortage, and go into other fields, increasing the problem.

Hildo Says:
The problem with this is that the code written by excellent programmers like Eric will not always be understandable by coders in the lowr 50% of the bell curve. The code will be concise and well-designed, but as a result not like like the typical “write it all out” code that typical programmers churn out.
This matters because the code will have to maintained and enhanced by such programmers for the remainder of its life, which is likely to be far longer and far more costly than the development time.
I see this all the time at work ($VERYBIGCOMPANY). Programs that need to survive for a long time (5-10 years) are on purpose given to large groups of mediocre programmers, so the code will be at their level and can be maintained by them. Short-term high-priority projects are given to really great programmers, but if theu survive longer than expected, they often have to be rewritten from scratch 2-3 years down the road when requirements have changed fundamentally and the original developer is working on another important project.

Chuck Says:
Laws of the universe like “diminishing returns” and Heisenberg-ian observation prevention paradoxes prevent the optimal team from working on a system that is optimized to their skillset. I worked on a project that went through several iterations on several teams, ensuring that the talented developers stayed on and the bottom-feeders were weeded out. I call it Darwinistic Developing. Of course, this only works with highly flexible time constraints (ie. research).
Obviously, this philosophy has its perks and plugs, but one of the more fantastic advantages is that the top 97 percentile are quite easy to spot. Right out of the unit testing stage, it is pretty clear who is holding the project back. After a few iterations, the project was error-free to a very high degree and the team was a highly-cohesive and productive unit.
Enter the next project, and suddenly the team is no longer optimal as there are no two projects exactly alike (even if just the client changes but the general project scope does not). The result of this research was that the process of evolving and optimal development team results in a team that is optimized to a single case. When the case changes, the optimization fails and productivity de-evolves.
Small team development, even single-person team development will always be hindered by one or more team members who detract from the efficiency of the development process. It is certain the one or more members of the team deserve to be paid the lion’s share of the wages and the rest earn a proportion of that amount, but it is nearly impossible to always determine the 97 percentile developer(s).
That is where another law comes into play: the law of averages, providing everyone on a team with an average wage based on overall productivity. Even with a team of one, where the average should be 1:1, problems in development like requirement and scope drift, challenges in implementation on a foreign platform or other unknowns will prevent even a 97 percentile developer being paired with a project that is perfectly suited to their skills.

Lee Says:
You missed the main reason in this article, although you already explained it (in part) in a previous article when you said:
“Mommy, mommy, Bobby has two more gigs of RAM than I do and he won’t share.” Pretty soon managers start liking conformity more and more. Same salary, same environment, same blue suit.
The rest of the reason is that if they paid the coder more, then the manager (considering him/herself MORE important than a mere “coder”) would want to make slightly more, etc. on “up” the proverbial ladder.

Ben Says:
I agree fully with you, especially with the problem (ability & motivation) has to recognize difference in ability. You overlook another important factor though — the ability to translate programming ability into money. For many companies this may not come that often, or the difference between good and stellar results isn’t that high. For them, it’s not worth paying any coder ‘what they’re worth’ at least in the long term, because they can’t profit from it. I think this blends in with the start-up problem. You might be a great coder, but can you code something great that is worth a large chunk of change to someone?

مرجع: http://codecraft.info/index.php/archives/78

گزیده:

Love cannot be found where it doesn't exist, nor can it be hidden where it truly does.
- David Schwimmer, in the movie "kissing a fool"

 

The study of software architecture involves the understanding of the large-scale structures of software systems. Since the mid 1980s, when the field began, software architecture has largely been concerned with engineering and understanding the interaction of well-defined components over well-defined communication paths via well-defined interfaces. However, a much different world is emerging. Systems are built from components designed and produced by organizations independently of each other. The components may or may not have well-defined interfaces. The functionality and quality attributes of the total system may be derived from (rather than engineered into) the federation of components. The components and their interrelationships may change dynamically, arriving and departing either bidden or unbidden, and connecting to the part of the system where they will do the most good. “Time to market” will be replaced by “time to useful functionality” and will be measured in seconds rather than months.
What will be the role of architecture in that new world? And what will the role of the architect be? Members of the International Federation for Information Processing (IFIP) Working Group 2.10 on Software Architecture recently held a working session on this topic to lay out the space of the practice of software architecture. Results of this session are summarized in this column and in the session’s Wiki at

http://wwwp.dnsalias.org/w/index.php/Session:Software_Architecture:_The_Next_Generation--Discussion

Reference:www.sei.cmu.edu

گزیده:

Mama always said life was like a box a chocolates, never know what you're gonna get.
- Forrest Gump from Forrest Gump

مطلب زیر را از وبلاگ زهرا نقل قول کرده‏ام. جالب و خواندنی است.
"خیلی دلم میخواد نظرتون رو راجع به این داستان بدونم. هر نتیجه گیری ای اعم از طنز جدی اجتماعی و غیر از اون دارین لطفا برام بنویسید:
* مرد بيكاري براي سِمَتِ آبدارچي در مايكروسافت تقاضا داد. رئيس هيئت مديره با او مصاحبه كرد و تميز كردن زمين‌ توسط او رو -به عنوان نمونه كار- ديد و گفت: «شما استخدام شدين، آدرس ايميل‌تون رو بدين تا فرم‌ هاي مربوطه رو واسه ‌تون بفرستم تا پر كنين و همين ‌طور تاريخي كه بايد كار رو شروع كنين..» مرد جواب داد: «اما من كامپيوتر ندارم، ايميل هم ندارم!» رئيس هيئت مديره گفت: «متأسفم. اگه ايميل ندارين، يعني شما وجود خارجي ندارين. و كسي كه وجود خارجي نداره، شغل هم نمي‌ تونه داشته باشه.»
مرد در كمال نوميدي اونجا رو ترك كرد. نمي‌دونست با تنها 10 دلاري كه در جيب‌ش داشت چه كار كنه. تصميم گرفت به سوپر ماركتي بره و يك صندوق 10 كيلويي گوجه ‌فرنگي بخره. يعد خونه به خونه گشت و گوجه ‌فرنگي‌ها رو فروخت. در كمتر از دو ساعت، تونست سرمايه‌ش رو دو برابر كنه. اين عمل رو سه بار تكرار كرد و با 60 دلار به خونه برگشت. مرد فهميد مي‌تونه به اين طريق زندگي‌ش رو بگذرونه، و شروع كرد به اين كه هر روز زودتر بره و ديرتر برگرده خونه. در نتيجه پول‌ش هر روز دو يا سه برابر مي‌شد. به زودي يه گاري خريد، بعد يه كاميون، و به زودي ناوگان خودش رو در خط ترانزيت پخش محصولات راه اندازی کرد…
پنج سال بعد، مرد ديگه يكي از بزرگترين خرده‌ فروشان آمريكا شده بود. شروع كرد تا براي آينده‌ي خانواده‌ش برنامه ‌ربزي دراز مدت بكنه، و تصميم گرفت بيمه‌ي عمر بگيره. به يه نمايندگي بيمه زنگ زد و پس از گرفتن یکسری اطلاعات سرويسي رو انتخاب كرد. وقتي صحبتها ‌شون به نتيجه رسيد، نماينده‌ي بيمه از آدرس ايميل مرد پرسيد. مرد باز هم جواب داد: «اما من ايميل ندارم.»  نماينده‌ي بيمه با كنجكاوي پرسيد: «شما ايميل ندارين، ولي با اين حال تونستين يك امپراتوري در شغل خودتون به وجود بيارين. مي‌تونين فكر كنين به كجاها مي‌رسيدين اگه يه ايميل هم داشتين؟» مرد براي مدتي فكر كرد و گفت: آره! احتمالاً مي‌شدم يه آبدارچي در شركت مايكروسافت."

گزیده:

"It takes a great deal of bravery to stand up to your enemies, but a great deal more to stand up to your friends."
- –Dumbledore, Harry Potter

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

وقتی برگشتم و وبلاگ را دیدم، نوشته‏های محبت‏آمیز دوستان را دیدم که از همه آنها تشکر می‏کنم.
علی آقای عبدالهی نوشته بودند که: ای که نمی دانم کجائی! شاید رفته ای سماموس که با همه خوبی هایش ای دی اس ال ندارد. میگویم ما یک استادی داشتیم که ....
خدمت علی آقا باید عرض کنم که تا نزدیکی‏های سماموس رفتم. عرض دوم این که ما کمی پیشرفته شدیم. نمره‏ها را ایمیل می‏زنیم.

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

آقای مهندس طاهری‏راد عزیز هم نوشته بودند که: آقا مهرداد دلواپس شدیم. دیر آپدت می کنی..
ضمن تشکر عرض کنم که شما لطف دارید. گاهی "وقت نداشتن" و گاهی "حرفی برای گفتن نداشتن" دلیل ننوشتن در وبلاگ است. قابل عرض اینکه وقتی Visual Studio را می‏بینم یاد شما می‏افتم. دیروز در کلاس ذکر خیر شما بود. حلال کنید.

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

دانشجویان عزیزم، آقای سیدامین میرزایی و آقای محمود هم لطف داشتند و از آنها هم تشکر می‏کنم.
علی آقا هم فرموده بودند که "و خداوند بروز رسانی را هم آفرید ..."
عرض به حضور علی‏آقا که "ببخشید که دیر شد."

گزیده:
گیلان ، گیلان، همیشه بهاره گیلان، الاله زار گیلان، می جان قراره گیلان، گیلان باغ چایی داره، پیله دریا ماهی داره