Standish Group بیشتر با گزارشهاي CHAOS شناخته می‌شود .
آمارهايي كه دراين گزارش از مؤفقيت يا شكست پروژه‌هاي نرم‌افزاري و عوامل تأثيرگذار بر آنها، ارائه مي‌گردد، مرجع بسيار مناسبي است براي آن كه در اجراي و انجام پروژه‌هاي نرم‌افزاري به فكر تبيين راه‌كارهايي براي بروز يا عدم بروز آنها باشيم..

ديگر كاربرد اين آمار، ارقام و تحليل‌ها، ارائه ادله قابل استناد مبتني بر داده‌هاي آماري براي تأكيد بر  اهميت بسياري حوزه‌هاي مهندسي نرم‌افزار است . به عنوان مثال، هر گاه مي‌خواهم اهميت حوزه‌ي مهمي مانند «مهندسي نيازمندي‌‌ها» را يادآور شوم،‌ عوامل شكست و مؤفقيت پروژه‌ها را بر اساس آمارهاي سالهاي متمادي  CHAOS فهرست مي‌كنم.
با اين مقدمه، آمارها و تحليلهاي سال 2006 اين گزارش را به صورت تصاويري در زير آورده‌ام. 
 مرجع:InfoQ

 

 

 گزيده:

A little learning is a dangerous thing.
Alexander Pope

 

مرجع: Thoughts on Information Technology
گزیده:
فرصتها را جستجو کن. جای قایق در بندر امن است، اما به مرور كفش پوسيده مي‌شود.

گريدي بوچ در مقاله‌اي با عنوان The promise, the limits, the beauty of software كه در سال ۲۰۰۷ نوشته شده، به بررسي برخي ابعاد توليد و توسعه نرم‌افزار پرداخته است. پس از اشاره به محدوديتهاي طراحي نرم‌افزار،‌ نكاتي براي بهبود آن ارائه كرده است كه  در زير آمده است.

1- Grow a system's architecture through the incremental and iterative release of testable executables;

2- Those things which change should be kept separate from those which have changed;

3-To build simple systems requires injected energy to make it simple (the number of lines of code should decrease).

گزيده:

You have riches and freedom here but I feel no sense of faith or direction. Why don't you use computers in search of love? Lech Walesa

دانستن شرایط پيراموني فضاي تولید و توسعه نرم افزار  کمک شایانی به تحلیل درست و تفکر در ساماندهی آن می‌نماید. مطلب زیر بخشی از شرایط را توصیف می‌نمايد:

IT development does not take place in isolation. The purpose of IT is to facilitate the operations of a business. The needs of the business environment drive the way we develop IT.
Current business drivers include:
The On Demand Business:
As businesses are expected to be more adaptable and flexible, so too are the IT systems that enable them.

Business relevance:
Now more than ever, there is a strong focus on IT departments to deliver business value. Software must be business relevant.  Miscommunication between business and IT people can lead to projects that, successful from an IT-delivery viewpoint, are deemed business failures.

Cost control:
The days of IT being invested in on the strength of its promises are long gone. IT departments now operate under strong budget constraints and are expected to demonstrate value for money.

Increasing complexity:
Software systems continue to increase in scale and complexity to meet business needs. Techniques that work well for small-scale development do not necessarily scale to enterprise-wide initiatives.

Skills availability:
The sophistication of today’s IT platforms means that specialists’ knowledge is required to deliver software. Many organizations struggle to find sufficient skilled professionals to support their development. In addition, projects often depend on key individuals and suffer significantly if those individuals leave a project or organization.

Changing middleware environment:
Today’s applications are deployed to a huge variety of middleware platforms, and the rate of change in platform technology is showing no sign of slowing up. Businesses want to take advantage of advances in middleware but do not want to repeatedly rewrite their applications.

Ref: Patterns: Model-Driven Development Using IBM Rational Software Architect, IBM Corp.

گزيده:
با مشکلات می‌جنگیم که به آسایش برسیم ، وقتی به آسایش رسیدیم، آسایش را غیر قابل تحمل می‌دانیم . بروکس آدامز

The Tyranny of Tools

I have seen teams attempt to enforce a style through the use of tools. Some tools are benign and helpful. Many IDEs, for example, allow you to specify things like indent level, brace placement, etc. With a single keystroke you can ensure that a batch of code conforms to the team style. I use tools like this, an depend upon them. I make sure that all the team members set their IDEs to use the conventions.

Other tools can be more intrusive. Some tools can act like compilers, generating errors if the style is not adhered to. Such tools might be useful for an occasional scan of the code; but I think you have to be very careful if you put them into the normal build cycle.

Automatic enforcement is power; and power corrupts. We do not want a well-meaning bureaucrat deciding, one day, to enforce the style that every function argument must have a javadoc comment. This leads to comments of the form: //required comment.

This is not to say that tools like findbugs and checkstyle should be avoided. Indeed, I find them very useful. However, I think they should be run occasionally and manually, not as part of every build. The issues that these tools discover should be dealt with on a case-by-case basis.

Many tools like this allow you to insert special meta-comments that override the warnings. If these tools are placed in the build process; then the code will become cluttered with these meta-comments.

I have a pathological distaste for meta-comments.

Conclusion

Coding style is a matter of team pride and team identity. Teams should be free to adopt their own styles, and to change those styles as the spirit moves them. Each member of the team should follow the team style, and work to ensure that the body of code is a consistent statement of that style. If this sounds too artsy-fartsy, keep in mind that pride of workmanship is a powerful motivator. We want teams to be proud of their creations.

گزیده:

 Comments are free but facts are sacred. —Charles Prestwich Scott

Style not Substance

A good coding standard should be about style and form, not about substance. It should not attempt to legislate good design. It should not, for example, proscribe goto or public variables. Those rules are part of the body of knowledge that all software developers should have, and are not a matter of style.

Coding standards should be about the things that don’t matter. They should be about brace placement, naming conventions, the use of blank lines, indentation levels, etc. A coding standard should describe the way code looks, not the substance the code is made from.

It is important to keep style and substance separate because they matter for different reasons. Issues of style matter only for consistency. It does not matter whether your indent depth is 2 or 4, so long as everyone uses the same depth. It does matter if you use public variables inappropriately.

Oral/Code Tradition

Documents that describe coding standards tend to be useless. They often become a bloated battleground for many different competing ideas. My advice is to avoid writing them.

The real document that describes your coding standard is your code. If you want to know how to name a variable, look at how they are named in the code. If you want to know what the standard indent depth is, look in the code. The code is the living document that describes the coding standard.

Oral tradition plays a role as well; especially when communicating issues of substance vs. style. Teams should make use of code reviews and pair programming to communicate with each other about issues of style and substance. New members of the team should have frequent exposure to the more seasoned members, so that the issues of style and substance are inculcated with moral authority. Nothing is quite as persuasive to a young programmer than pairing with the lead programmer and hearing him say: “We don’t do things that way; we do things this way.”

گزیده:

 Real seriousness in regard to writing is one of two absolute necessities. The other, unfortunately, is talent.  Ernest Hemingway

  یکی از مهمترین مراحل در توسعه نرم‏افزار، برنامه‏نوسی و کدنویسی آن است و یکی از مهمترین مشکلات در این مرحله، کم‏کیفیت و ناهمگون بودن کدی است که توسط برنامه‏نویسان نوشته می‏شود.  برای حال یا کاهش اثر این معضل، یکی از روشهایی که معمولاً به کار می‏بریم، تدوین استانداردهای برنامه‏نویسی است که برنامه‏نویسان ملزم به پیروی از آن هستند. Robert Martin در نوشته‏ای به بررسی این موضوع پراهمیت پرداخته است.  

Coding Standard
Coding Standards are a good idea. Every team should adopt a coding style and standard, and stick to it. The code produced by that team should have a consistent look and feel that is devoid of individual preferences and fetishes.

Of course this means that the members of the team will have to be mature enough to realize that it doesn’t really matter where they put their braces, or how they adorn their member variables. What matters is that they all use the same conventions.

Consistency

My goal for a good coding standard is to eliminate individual styles in favor of a team style. The code produced by a team should look like the team produced it. I don’t want any code recognizable as Bob’s or Bill’s.

This is not some egalitarian fantasy to hide individuality for the sake of the collective. Rather, it is a raw necessity. We’ve all seen products that look like they were designed by a committee. We’ve all used software products where the look and feel changed depending on which part of the application you were using. The result feels messy, clumsy, inefficient.

Individuals, used to their own particular style, will reformat other people’s code when forced to work on it, further shuffling the patchwork of styles. Over time, as each team member touches different parts of the code, and team members come and go from the team, the code begins to look like a jumbled Rubick’s cube of different styles.

Code is a product, in and of itself. The team producing it needs to take pride in the elegance of it’s structure, and the expressiveness of it’s presentation. This kind of pride is infeasible when the code is crisscrossed with a patchwork of individual styles. Without this pride, there is no drive to keep the overall product clean. Without that cleanliness, messes build up at the boundaries. And, as we all know, messes slow us down, and they spread.

گزيده:

Write your code to be read. By humans. Easily. The compiler will be able to cope.   Pete Goodliffe