Egineering truths, how to make better engineering decisions

Often in an engineering problem software developers tend to try and find the perfect solution and quickly fall in love with one idea that may work or then shoot down ideas that could work but not in all hypothetical circumstances (even if they are realistically not possible).

Many discussions I’ve attended could have been cut short by just agreeing that we cannot come up with a perfect solution in a meeting and then proceeding to brainstorm -- during a limited time (say 1 day) -- 2 or 3 ideas that could possibly work and would be further analysed for validation.

Instead of following the recipe outlined above, many times engineers will debate for long hours what the perfect solution could be, only to see each of the ideas shot down due to an hypothetical case in which they may not work. This discussions create a large ammount of lost time (waste) in the software development process. Let’s take a simple example.

Imagine that you are in a team of 3 people that are faced with a technical/engineering problem. You set-up a meeting in the hope of finding the solution quickly, you call all stakeholders in and start the meeting:

The normal way a meeting would go would be:

1. 1. Short introduction to the problem and the considered restrictions so far (5 minutes)


2. 2. Presentation of one or more proposals for a solution (15 minutes)


3. 3. Discussion about which solution to take (40 minutes or the remaining of the one-hour meeting)

Now, it may not be obvious but when you reached point 3 the meeting should have taken a different direction.
When you have two or more solutions to evaluate you cannot go on with the discussion before you clearly define evaluation criteria. If you had only one solution you probably should first brainstorm a while to come up with at least 1 more idea, but then you should follow that with a discussion about the evaluation criteria, not the solution to implement.
There’s a number of reasons for this, but at least two of these are crucial for a good quality decision: a) discussing the evaluation criteria will give all of the meeting participants a better understanding of the tradeoffs involved in the decision making process and b) you will also most likely find other factors to consider that you have not considered in the first proposed solutions.

So, the point 3 should be changed to:

• 3. Discuss evaluation criteria to follow when making a decision (30 minutes)

What about point 4? Well, there’s none! At least not within the meeting. Once you have discussed the environment of the decision with the key stakeholders and you have agreed on the evaluation criteria your next goal is to make the best decision possible, you cannot do that without good quality alternatives for your decision. Therefore the next step should be to generate those alternatives. Take (at least) 2 groups of people (groups of 2 with 1 from each stakeholder group for example) and brainstorm a limited set of possible solutions (I would say that you need to have at least 3, but that’s my rule-of-thumb), evaluate them according to the criteria decided in the meeting and propose them to the stakeholders. Then call another meeting. This process should not take more than 0.5-1 days for medium-sized problems. The longer you take the more time will be “wasted” by not implementing a solution

In the second meeting you should have the following agenda:

1. 1. Prior to the meeting each participant must learn about all the proposals put forward and be prepared to discuss them – not being prepared will produce a bad quality decision.


2. 2. Shortly review the problem (to refresh people’s memories: 2 minutes)


3. 3. Present each proposal’s tradeoffs (the proposals were presented prior to the meeting via a proposal document) and answer possible questions (20 minutes)


4. 4. Possible new proposals arising from the discussion. For example: merging two complementary proposals (10 minutes – this is possible because the people in the meeting are aware of the details of all proposals)


5. 5. Final decision on which proposal to take forward (5 minutes).

The second method is a possible implementation of Set-based engineering and even though it may not seem so, this approach often takes less time to converge to a final solution and additionally it yields better quality results that lead to less rework which means less waste.

Many people in the software world have forgotten some basic truths about engineering. In this method I’ve tried to explain how to use 2 of those truths for your benefit:

1. 1. Failing or making mistakes helps you learn: make several proposals and learn from the shortcomings of the ones you did not select;


2. 2. Critical engineering decisions should be made following a disciplined process to ensure that the needed factors are taken into consideration: define evaluation criteria and follow that when evaluating an idea.

What is important is not to find the right solution, but to generate several solutions in a limited time-frame and pick the best from those. If you do that you are likely to fine-tune and improve one of the original proposals and come up with a much better solution in the end.