Prototyping vs Designing

Long ago there was a question raised on habrahabr.ru about a balance between detailed designing and prototyping of a new product.
From one side prototype allows you to:

• get understanding of technology;
• feel how something similar to a final product works and this helps to clarify requirements;
• make client happy by a visualized result.

From the other side:

Expanding The Iron Triange

As I have mentioned in my previous post I don't presume "The Iron Triangle" as a right approach to desribe project parameters. Instead of this I prefer to consider four parameters: scope of work, project duration, monthly cost and quality.
These are, roughly, parameters that can be discussed with a client at the moment of forming a vision of project. If you fix two parameters then the other two will depend on each other, if you fix three then the forth will be defined automatically.

The Iron Triangle

I've met a lot of definitions of "The Iron Triangle", i.e. "Quick, cheap and with high quality - choose two" or "Cost, time and scope are related, but quality is not an option". Different people put parameters on tops or on sides of the triangle...
To my mind this caused by the fact that the iron triangle simply does not exist.

Interview Question

During job interviews we often ask a question that looks like very simple one: "What is the purpose of testing?". Here we are talking about the first term from the classical triad: testing, quality control, quality assurance.

In 99% of cases the answer is "To improve the software quality". And I consider this answer as wrong.

When Problems are Your Friends

As a follow-up to the previous post I'd like to rise а question which was mentioned in the talk on AgileEE 2010. That's about "why the crisys is good".

The accurate statement surely should be "why crisys is not only bad, but also good". No doubt that it's bad - otherwise it would not be called "crysis". :)

But there are positive sides.

The Best is the Enemy of the Good

Can you think about half of dozen schemes and processes of your project that are not going very well, but "well, we all adapted", "don't touch it - it works like this" and "it is actually not used very often"? Surely you can.
And of course these things are not going very bad, they are just bad, but nobody cares. They are similar to a creaking door or leaking kitchen tap - it will work fine for years.

I can think about 2 types of situations with those just bad processes. Think about analogies above: they are describing two different situations.

Manifesto for Software Craftsmanship

On AgileEE 2010 someone has mentioned Manifesto for Software Craftsmanship.
Here it is:

• Not only working software,
      but also well-crafted software
• Not only responding to change,
      but also steadily adding value
• Not only individuals and interactions,
      but also a community of professionals
• Not only customer collaboration,
      but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

See original version

About me

During two and a half years I was working in Kharkiv, Ukraine in Validio company which later became GlobalLogic on positions from Junior to Senior QA Engineer. During the next two and a half years and till now I have been working in TeamDev company on a position of Senior QA/a-sort-of-Business Analyst/and-a-little-bit-QA Lead.

I like Agile approach to software development and accompanying methodologies.

I've never faced the tricks of Sales work and I know as much about cunning politics and legal aspects as it can be seen from outside. However I hope that being out of the box of this topic allows me to have a more clear vision of some things.

My English is far from excellent (also Russian is :)) and I will highly appreciate if you correct my mistakes.

--------------------------------------------------

В течение двух с половиной лет я работал в харьковской компании Validio, которая потом превратилась в GlobalLogic, на должностях от Juniour до Senior QA. Следующие два с половиной года и до сих пор - в компании TeamDev на должности Senior QA/вроде-как-Business Analyst/и-еще-немножко-QA-Lead.
Я люблю Agile подход к разработке и сопутствующие методологии.
Никогда не сталкивался с подноготной работы Sales'ов и в хитрых политических расчётах и юридических аспектах разбираюсь ровно настолько, насколько их видно со сторны. Впрочем, надеюсь, нахождение out of the box этой темы позволяет смотреть на некоторые вещи более ясным взглядом.
Мой английский далёк от идеала (русский тоже :)) и я буду очень благодарен, если вы будете меня поправлять.