The crisis of software development in 1965—1985 identified many problems related to both productivity and quality. Over the last 50 years the community of IT industry made a great effort trying to change the situation. Many software-centric companies today are showing much better results in terms of productivity, quality, as well as time and budget control over projects. However, many organizations out there are still behind of what should be considered a standard in XXI century.
While software development is not a science, it is even less a craft than people often think. All important concepts can be learnt by everyone over time. The application of those concepts is the most frequently faced aspect that can be classified as "craft", but even the efficient application can become one's second nature with enough practice.
It is not uncommon to hear the indicators of huge issues in process or attitude or both: "We can not touch this code because things may break." "We do not have time for testing, deployment, and/or automation." "We can throw in more people to get things done." "We may need to work overtime the next one or two weeks. It is a temporary measure." "We will add a technical debt for it." aka "We will fix it later, after we meet the milestone." "Everything is our top priority." or too frequent "Drop what was a priority yesterday, and work on something that seems to be a priority today."
Those phrases are often trying to tell that the way the organization operates does not involve important principles of effective software development:
| Doing the right thing the right way by investing into knowledge and staff | as opposed to "this looks good enough" thinking. |
| Defining a problem jointly as a team before thinking about its solutions | as opposed to making devs working against a "spec". |
| Quality above all through constant self-assessment, and process improvement | as opposed to quantity focused deliveries. |
| Delivering one thing 100% ready for use | as opposed to having many things in progress or "code complete". |
| Realistic planning through as many informative metrics as possible | as opposed to wishful thinking. |
| Right technology for the job | as opposed to hype or "well-known" old-school techs. |
| Focus on highest standards engineering practices | as opposed to "too fancy for us", "no time" mentalities. |
| Favoring rule enforcement via tools | over relying solely on discipline or good intentions. |
These ideas combined together suggest a few conclusions.
The Software Developer role must assume greater responsibility than it often does. IT industry engineers' contribution must be present at all stages of business problem resolution, starting as early as at problem definition step. Developers must also fight for quality over quantity. They must be honest about their expertise and the limits of it. Last but not the least, developers have to keep asking their why's, think of better ways to operate, and push their organization towards learning best practices from the most successful members of the IT community.
Dependent on the interpretation of Ardent Developer Manifesto, it may or may not work as an efficient framework for Agile Manifesto to operate in.