There’s something software engineers are famous for saying in response to pretty much any question about their craft, which is considered evasive/a non answer - it depends.
This begs a question. “It depends” is half a sentence. It depends… on what? Perhaps it seems absurd to try to provide an answer to this, given the frequency with which and the range of situations in which this phrase is used. I would argue that the answer is often, if not mostly, context. It depends on the context in which the original question, which prompted the response of “it depends”, is being asked.
In software engineering narrowly, and more broadly when developing a product, the sources of context are myriad. We are working in the context of some project or product. If such questions are being asked, we’re likely working in the context of a team, or perhaps multiple teams. Often, we are working in the context of a company, and consequently also an industry. In the opposite direction, at times we are working in the context of a particular codebase or module or microservice, down to a file, a class, a function, etc…
Frequently then it depends on layers and layers of people, processes, goals, technologies and other decisions. No wonder this all gets shortened to it depends!
The it depends meme is usually quoted when talking about some question about technical choice or specific code “things”. Given that this article series doesn’t aim to discuss these aspects of software engineering, but rather broader questions around leading teams together with their technologies and products, I will point out that all this applies just as much to everything that happens around the code and the technologies etc… # Everything In Its Context
There’s something software engineers are famous for saying in response to pretty much any question about their craft, which is considered evasive/a non answer - it depends.
This begs a question. “It depends” is half a sentence. It depends… on what? Perhaps it seems absurd to try to provide an answer to this, given the frequency with which and the range of situations in which this phrase is used. I would argue that the answer is often, if not mostly, context. It depends on the context in which the original question, which prompted the response of “it depends”, is being asked.
In software engineering narrowly, and more broadly when developing a product, the sources of context are myriad. We are working in the context of some project or product. If such questions are being asked, we’re likely working in the context of a team, or perhaps multiple teams. Often, we are working in the context of a company, and consequently also an industry. In the opposite direction, at times we are working in the context of a particular codebase or module or microservice, down to a file, a class, a function, etc…
Frequently then it depends on layers and layers of people, processes, goals, technologies and other decisions. No wonder this all gets shortened to it depends!
The it depends meme is usually quoted when talking about some question about technical choice or specific code “things”. Given that this article series doesn’t aim to discuss these aspects of software engineering, but rather broader questions around leading teams together with their technologies and products, I will point out that all this applies just as much to everything that happens around the code and the technologies etc…
In this article series I plan to focus rather on those “non-technical” questions around software development - process, governance, leadership. Each approach, tool, technique, etc… for these will usually best apply or be used in specific contexts, and perhaps not work well in other contexts. It’s very rare that something will always work well in all contexts.
Hence, when discussing these ideas I will try to place the different approaches and recommendations covered in their own appropriate context. I’ll focus where possible on my own experience, where I’ve seen things work well and maybe not so well. I view this as a “living” article series, since I’ll be discussing thoughts that might not be so well solidified, so when I forget then I’ll just add the context later.
Many of my notes will focus rather on those “non-technical” questions around software development - process, governance, leadership - because I find that these bits are often what are working less well in a team or company, rather than e.g. certain technical choices. Each approach, tool, technique, etc… for these will usually best apply or be used in specific contexts, and perhaps not work well in other contexts. It’s very rare that something will always work well in all contexts.
Hence, when discussing these ideas in my notes I will try to place the different approaches and recommendations covered in their own appropriate context. I’ll focus where possible on my own experience, where I’ve seen things work well and maybe not so well.