Good results in software engineering depend on robust decisions over the trade-offs involved in solving problems with computing devices. This can only be done through a good understanding of the problem being presented, and the context/platform that will support its resolution. Technical choices should not be elevated above that.
Note that both the problem and the platform’s definition should not only consist of inanimate objects. Both always incorporate human elements that must be understood.
By nature, engineering therefore involves learning, knowledge formation, skill development and acquisition.
It is as much about forgetting and ignoring the non essential as it is actual knowledge acquisition. The goal should be to acquire actionnable knowledge i.e. knowledge that supports decision making.
The platform is most often known in advance, and therefore one is often already aware of its properties. If it is not known or isn’t fixed in advance, its definition and refinement will be essential.
Enumerate the skills that are necessary to correctly analyse and solve the problem at hand. Verify that your platform incorporates those skills. If not, as is most often the case, skill acquisition and development will be involved in the resolution.
My practice almost always start with the enumeration of the entities involved in the problem and of their relationships. This is an attempt at understanding the data involved in the problem, its cardinality and relations.
Going through a process of normalization (as introduced in the design of relational databases) will help create the most compact documentation of that data.
Then comes the enumeration of the most coarse operations/actions that involve this data. These are the transformations that become visible by observers/users of the computing system at its boundaries. Again, it is important to keep an eye on the frequency at which these transformations are going to be performed, so as to focus on the most critical ones first.
The study of those transformations will highlight the data that is often operated on, which can help drive the design of the computation and where data models have to be denormalized.
For clarity and peace of mind one can choose to split the discussion around the team’s function and the problem solving practice itself away from the problem at hand. It is often formalized in team roles such as with explicit leadership roles or teams. This does however not make it any less part of engineering, and as it will have an effect on the result, should also be a concern of the problem solvers.
The platform is what defines the limitations of your problem solving. It starts at the lowest level.
While sometimes one is called to form a team from scratch, most often the team comes partially formed.
It is essential to get to know the skills and biases that a team has so as to counteract the latter and align the former to the goal.
The quickest way to grasp a team’s skill is to figure out the tasks it has performed most often. It is the source of most of its skills and biases.
In terms of computing platforms, there isn’t any easy shortcut. One has to read about it and understand its strengths and limitations. Reading official manuals, articles from genuine practionners for instance.