The underlying layer is problem solving: digging deeper until you find the problems to solve. Then there's product and management. Then there is writing software and the skills inherent to it. Then there are the methodologies. Then there are the tools.
It is a combination of all these and more. You take one out, and you're developing for the wrong problem or one that does not exist. You take the other, and you take too long or do it. You take yet another, and you're making cool technology for its own sake. You take the other, and you're solving problems in the wrong order. You take another, and people are making different things than the one you're thinking about.
Depending on what you are trying to accomplish, you stress on one more than the others. It is a balancing act in which the weights and priorities change, assumptions change, landscape changes.
You can follow agile all you want, if you're in a brainstorming meeting where you haven't clearly defined the problem, the job to be done, and are instead talking about buttons and interfaces, the project will fail and not all the great code will save you. It is tricky especially if you are with a client and they're very into it and you have to focus everyone on problems.
You can have SWEBOK in your head, if you are too dogmatic about it you risk of missing the bigger picture, or a market.
You can wield GitHub, GitLab, and editors all you want, if it is your main concern you risk of spending way more time on their interfaces than thinking.
You can know all these, if you don't get out of your metaphorical room to confirm the problem exists, or lack interviewing skills to extract a problem, then the software will be a thought experiment with no usage.
Comments
The underlying layer is problem solving: digging deeper until you find the problems to solve. Then there's product and management. Then there is writing software and the skills inherent to it. Then there are the methodologies. Then there are the tools.
It is a combination of all these and more. You take one out, and you're developing for the wrong problem or one that does not exist. You take the other, and you take too long or do it. You take yet another, and you're making cool technology for its own sake. You take the other, and you're solving problems in the wrong order. You take another, and people are making different things than the one you're thinking about.
Depending on what you are trying to accomplish, you stress on one more than the others. It is a balancing act in which the weights and priorities change, assumptions change, landscape changes.
You can follow agile all you want, if you're in a brainstorming meeting where you haven't clearly defined the problem, the job to be done, and are instead talking about buttons and interfaces, the project will fail and not all the great code will save you. It is tricky especially if you are with a client and they're very into it and you have to focus everyone on problems.
You can have SWEBOK in your head, if you are too dogmatic about it you risk of missing the bigger picture, or a market.
You can wield GitHub, GitLab, and editors all you want, if it is your main concern you risk of spending way more time on their interfaces than thinking.
You can know all these, if you don't get out of your metaphorical room to confirm the problem exists, or lack interviewing skills to extract a problem, then the software will be a thought experiment with no usage.
What are you up to? Working on an idea?