The art of saying yes, and the art of saying no

We are the IT engineers. We design and build the software. The approach we take while designing the software will determine the quality of the result much more than DRY, SOLID or any other coding principles we learned about.

To put it another way: code quality is an important component of a good software. But it is not crucial. A good software must be able to respond to specific needs of people using it. A good IT engineer must be able to:

• recognize the needs of the stakeholders, even if they didn't verbalize them;
• manage the stakeholder expectations, while fine-tuning the processes in order to get the best possible results;
• define a minimally viable product (MVP) and protect it from the scope creeps, while keeping the agility.

This session will put the emphasis on the ugly parts of software design: saying “no” to the stakeholders in order to deliver the best possible quality of the product in the least amount of time while keeping the morale of the development team high. It will try to answer the questions "when" to say no, "why" to say no, and "how" to say no in a way that will keep the stakeholders happy. It will be useful to product owners, but also software architects and engineers in contact with stakeholders.