4 ms·

> When you have no idea what the system is, you just stick to the function definition and have it handle all the weird cases. You don't make assumptions. You ca

> When you have no idea what the system is, you just stick to the function definition and have it handle all the weird cases. You don't make assumptions. You can still make mistakes, though, some of them caused by the lack of global understanding of the system because the specification writer had those assumptions in mind and did not write them down in the specification of this function because they were obvious to him or they were already written in another part of the specification. This, alone, deserves an article. It's a fundamental knowledge in any software development made by different teams, or even a discussion about the pros vs cons of having a monolithic team versus distributed teams. If you expect that small teams, doing parts of a project, take care of all possible interactions of their piece of program with all other components, you'll fail. They just have a subset of the knowledge, and how all those information was passed so that they could act is relevant. And in general nobody writes down every single detail that could make a difference. In those scenarios, analysts who are able to write requisites until the point that some can be considered non-sense or obvious, should be paid in gold.

pjmlp 10y ago
Which is why actual C and C++ code written at these companies, in these type of projects is so "fun" to debug. Yes, everyone can be a super coder on his little bubble and use all the latest techniques to write high quality code, the problems arise when his/her bubble needs to interact with an ocean of unseen bubbles, many of which tainted ones.
- ethbro 10y ago
  The longer I've coded in practice, the more suspicious I've gotten about "you don't need any domain knowledge, here are perfect specifications" approaches. The fingers on the keyboard should always have some grasp of the bigger picture, or bad things are likely to happen.
  - pjmlp 10y ago
    Fully agree, I never understood the stereotype of coder closed in a cubicle breaking LOC records, coding without any other knowledge than programing language and libraries. I always have spent a big part of my time interacting with those that would eventually use the programs/libraries. Without domain knowledge and communication skills, there is a high probability of misunderstandings.

pjmlp 10y ago

Which is why actual C and C++ code written at these companies, in these type of projects is so "fun" to debug. Yes, everyone can be a super coder on his little bubble and use all the latest techniques to write high quality code, the problems arise when his/her bubble needs to interact with an ocean of unseen bubbles, many of which tainted ones.

ethbro 10y ago
The longer I've coded in practice, the more suspicious I've gotten about "you don't need any domain knowledge, here are perfect specifications" approaches. The fingers on the keyboard should always have some grasp of the bigger picture, or bad things are likely to happen.
- pjmlp 10y ago
  Fully agree, I never understood the stereotype of coder closed in a cubicle breaking LOC records, coding without any other knowledge than programing language and libraries. I always have spent a big part of my time interacting with those that would eventually use the programs/libraries. Without domain knowledge and communication skills, there is a high probability of misunderstandings.