Re:Software Projects vs. Traditional Projects (Score 1)

The difference between a "Programmer" and a "Software Engineer" is analogous to that between a "Mathematician" and an "Accountant." The former uses a creative process that cannot be broken into discrete parts. The entire process is design. The latter merely manipulates the work of the former in a formal, discrete process toward an end goal. This is not a value judgement on either; it is merely a definition. The problem is that, in business, there is either a lack of understanding or of acceptance of this definition. The roles then get blurred. People more inclined to the creative side are stifled with detail, while those with great attention to the details are thrown into design. Other terms can also confuse the issue: "Architect," "Developer," "Analyst," etc. all have implications that are often not natural to the industry. Next comes the systems/software divide. It seems that when people are promoted in the corporate world, their focus tends to shift from software to systems. This nearly guarantees that "Programmers" will turn into "Software Engineers," and often "System Administrators," as that is where the promotions are (note that most middle management essentially performs the role of a "System Administrator"). Unfortunately, this makes for a bad programming environment. The hybrid model that "Programmers" and "Software Engineers" are forced to live in creates this hybrid culture of creatively designing a system that takes on a new life during implementation, finally culminating in failure. Agile project models are better, but this still does not address the issue that creativity cannot be time- or resource-constrained. Management hates this because that is exactly what they are supposed to figure out how to resolve. I certainly don't have the answer, but I can at least recognize the problem for what it is. Until we change the industry to support separate "Programming" and "Software Engineering" positions, projects will continue to fail tremendously.