Most software professionals have never seen a successful software development project, continuous delivery evangelist Dave Farley said, and have “built careers on doing the wrong thing”.

Author Joe Fay’s recent article in The Register sparked a bit of my interest. In today’s world of iterative design, constant development, and component rollouts, what is success?

How do you define success in your software projects?

• meeting internal/external deadlines
• meeting customer requirements
• meeting management’s requirements
• good coding practices
• … simply surviving the project until the next iteration?

For our teams, I feel it is a mix of all of those. Success for a modern software project that is constantly in a state of flux has to be defined up front as there isn’t a state of done.

I think, to that, almost every software developer has seen some form of success–or they wouldn’t remain employed–because success is a metric created for and by the organization.

For the teams I work with, the definition of success is defined in terms such as:

The iteration will be successful if {application} includes feature(s) {a,b,c}, fully tested and bug free to the best due diligence of the team, by {date}.

Promising perfection is impossible, but stating goal on paper–even if a project plan implies it–goes a long way to make it happen.

When does the responsibility of success no longer fall on the developers?

One study of 5,400 projects, by McKinsey and Oxford University, showed that 17 per cent of projects were so catastrophically bad they had threatened the very existence of the company.

Given these sorts of statistics, Farley argued, individuals could plausibly spend their whole career in software development without ever encountering, never mind running, an unequivocally successful development project.

“I think the vast majority of people in our industry have spent the vast majority of their careers not knowing what a successful software project looks like,” he said.

As a developer, I think this would be extremely discouraging and would cause rot within an organization if they were constantly failing. Without knowing the details of success, there has to be accountability at the organizational level, recognizing the trend, and course correction.

Failure is fine–in fact, encouraged–but constant failure requires remediation and shouldn’t become a culture of any developer or organization.

So what’s your take? Are all of your projects failing to reach success and how do you define success?