От простого к сложному или от простого к тривиальному?

В последнее время часто задумываюсь, а хорошо ли, когда у программного продукта сложная архитектура? Хорошо ли это для тех кто на проекте работает. Много ли опыта можно получить, если работать с чем-то простым. Ведь делать хорошо простые вещи это тоже искусство.  Не придумывать решений сложнее чем необходимо для текущего продукта  - тоже нужное умение. Теперь для меня нет разницы между тем инженером, что работал над сложной системой поддержки принятия решений и тем, кто занимался автоматизацей службы заказов онлайн.

Поспешишь, людей насмешишь.

Старая пословица как никогда верна в наши дни, когда постоянно надо двигаться вперед, что-то делать и не стоять не месте. Но сделал для себя вывод что, когда выбираешь из списка задач что-то вроде: "Связаться с тем-то, обсудить то-то", надо четко представлять, как пойдет беседа. Часто, получается, что желая закрыть тему, просто делаешь звонок, беседуешь с человеком и так ничего и не решаешь. То есть по сути теряешь время.

Гордость и предубеждения

Иногда политика "Да, мой белый гаспадина..." приносит свои неожиданные плоды. А именно все всем довольны. То есть если ты хочешь работать как специалист наравне во спецами заказчика  - не надо добиваться признания этого официально. Пусть спецы заказчика говорят, что они делают очень много работы и, причем, самой сложной, а ты им просто помогаешь. На самом же деле все наоборот. Если забыть про гордость все может выйти совсем неплохо. Так тебя никто не достает, пытаясь показать что он тут главный, а ты себе работаешь. И при этом не выгодно говорить что ты плохо работаешть. Если тебя сместят, кто же будет делать всю работу, да еще и так чтоб можно было говорить обратное.

Не думаю что тработает всегда. Даже сказал бы что работает иногда. Очень редко. Но бывает.

Финал ЛЧ

Второй год подряд нахожусь в Берлине во время финала Лиги.  По моему очень четкий случай проявления закона парных случаев.

Что такое QA?

О том что такое QA споры идут уже давно. Расшифровка аббревиатуры это Quality Assurance. Вопрос в том, что в нашей части света под этим очень часто понимают тестировщиков. А это не совсем так. Посмотрел в Википедии и вот что нашел:

Sub-disciplines

While Grace Hopper was working on the Harvard Mark II Computer at Harvard University, her associates discovered this moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system. Thus starting the popularity of the term software bug.

Software engineering can be divided into ten subdisciplines. They are:[1]
Software requirements: The elicitation, analysis, specification, and validation of requirements for software.
Software design: The design of software is usually done with Computer-Aided Software Engineering (CASE) tools and use standards for the format, such as the Unified Modeling Language (UML).
Software development: The construction of software through the use of programming languages.
Software testing
Software maintenance: Software systems often have problems and need enhancements for a long time after they are first completed. This subfield deals with those problems.
Software configuration management: Since software systems are very complex, their configuration (such as versioning and source control) have to be managed in a standardized and structured method.
Software engineering management: The management of software systems borrows heavily from project management, but there are nuances encountered in software not seen in other management disciplines.
Software development process: The process of building software is hotly debated among practitioners with the main paradigms being agile or waterfall.
Software engineering tools, see Computer Aided Software Engineering
Software quality
Software localisation, a branch of the language industry.

Отсюда:

http://en.wikipedia.org/wiki/Software_engineering#Sub-disciplines

И вот тут мне стало яснее что есть две дисциплины Тестирование и Контроль качества и состав у них немного разный. Для разнообразия можно посчитать статьи. Но мне понравилось вот, что:

Software Quality Assurance (SQA)

Though controversial[12], software testing may be viewed as an important part of the software quality assurance (SQA) process.[citation needed] In SQA, software process specialists and auditors take a broader view on software and its development. They examine and change the software engineering process itself to reduce the amount of faults that end up in the delivered software: the so-called defect rate.

What constitutes an "acceptable defect rate" depends on the nature of the software. For example, an arcade video game designed to simulate flying an airplane would presumably have a much higher tolerance for defects than mission critical software such as that used to control the functions of an airliner that really is flying!

Although there are close links with SQA, testing departments often exist independently, and there may be no SQA function in some companies.

Software Testing is a task intended to detect defects in software by contrasting a computer program's expected results with its actual results for a given set of inputs. By contrast, QA (Quality Assurance) is the implementation of policies and procedures intended to prevent defects from occurring in the first place.

Взято отсюда:

http://en.wikipedia.org/wiki/Software_testing#Software_Quality_Assurance_.28SQA.29