They touched on something in the article but it deserves more emphasis. The most difficult and critical part of software development is requirements engineerin

They touched on something in the article but it deserves more emphasis. The most difficult and critical part of software development is requirements engineering. I will includes requirements negotiation as part of that. Something that I have always had to fight against is the tendency to take business stakeholders at their word when they say they have a specific set of requirements or deadline. Project success often hinges upon modifying or rejecting supposed requirements given unambiguously. The hardest part of this is that business analysts or executives prescribing requirements often have more seniority or political power in an organization than the software engineer. They also don't really know what requirements engineering is or that it is something the _software engineer_ _has_ to do. It's necessary to understand the details of business problems and then do some level of analysis of how to address them with technology. The majority of projects have done about 50-90% of the necessary depth of business analysis and that is what they present to the programmer as a supposedly complete description. But pushing a little harder on those details it's often possible to find process descriptions scrambled, missing important information, and processes that really aren't required. Once the engineer truly understands the business, they can think in depth about ways to use technology to deliver value. They can come up with design outlines for the software and think about how to break things up into different iterations. What is worthwhile in terms of programming effort versus business value. They cannot do that without having drilled down into details. It's quite common for an important detail to be omitted in discussions initially, which dramatically increase the programming difficulty or changes the approach. That's why it's so important to always be digging to uncover real requirements (and especially at the start). Getting all of that resolved requires not only strong communication skills but also favorable political outcomes. If the project management isn't good, they can interfere or fail to provide support during the requirements phases and therefore kill any possibility of success from the start. But regardless of how good the managers, requirements need to be negotiated and agreed upon which is another challenge. Beyond all of that, programming really is hard. If it wasn't, it would not be programming. It would be copy and paste or configuring existing software. The premise is that you have unique problems that have not been solved yet. So you need expertise but also strong problem solving skills. Which all the while you may be dealing with all the people issues at the same time.