Software Development Success
Software Development Success(refactored from InsightsFromWhatArePatterns)
BTW, how do we define success and failure (in software development) in the first place?
Hmmm. This question made me think. I think I define success and failure only in relative terms - project A was more successful than project B. This makes using subjective "gut feeling" judgement easier, which I guess is what I use.
I think success (or failure) has multiple aspects. In AgileSoftwareDevelopment, AlistairCockburn talks about "methodological success" - the software shipped and, given the chance, you'd do the process the same way again next time. But there is also "business success" - it doesn't help to do a good job of building and shipping a product that doesn't sell and create value for its builder/owner (this might get to what is RealValue, etc.). There is also "design success" and "professional success" - were you happy with the design of the software, and did you contribute to the knowledge in the software development profession along the way. Finally there is "people success" - at the end of the project, were the relationships between people worse or better than at the beginning? -- RandyStafford
On time, on spec, and on budget. That's necessary, but not sufficient. What if the product doesn't sell or serve its users, the architecture sucks, and everybody hates each other at the end? Is the development still a success?
Poor selling is not generally a development failure (for software that otherwise works). This is definitely true for shrink-wrap software. With in-house software the *actual* users are near at hand you have fewer excuses if they don't like it.
The main point here is that a development group doesn't operate in a vacuum. It has been asked to produce something, and if it does on time/spec/budget then it's done its job.
#1 providing value to the customer
#2 at the best cost
#3 doing this for the whole life cycle of the software
This means you have three major issue to consider :
Roughly stated, productivity will grow if the quality level reached by the team gets higher, or if it takes less effort.
Developers alone or customer alone cannot decree the SoftwareDevelopmentSuccess :
Only the customer can define the quality required and assess the quality reached by the product. It means that attempts from the developer (or development team manager) to modify the "quality level" variable (by lowering the requirements or decreeing the level attained) are not only frustrating the customers but are also leading the project further from success.
Only the developer can really estimate the development effort needed, the maintainability level required and assess the current maintainability level for the code. It means that if as a customer (or project owner) you lower the required level for the project or try to differ code refactoring until the next release (e.g.), you are not only frustrating the developers but you are also equally steering the project further from success.
You may need a software development process model. And a project centered organization (requirements, deliverables, schedules and so on).
I personally have a growing conviction that SoftwareDevelopmentSuccess implies some form of agility. This means (at least) testing and refactoring at a frequency level way higher than in the traditional approach. -- ChristopheThibaut
Product Quality is not the same as development success. Product quality is a perception by customers of how well a product met their expectations for it. Many non-development factors can affect it - a sales force that over-hype a product will raise expectations and therefore lower the quality perceived by customers. Price too affects quality.
Development success is a measure of how well a development team fulfilled their role in the organization. Small companies expect development to do many things: develop new product ideas, development, deployment, and support. Big companies tend to be more segmented. A spec is thrown over the wall to development and they write some code and throw it over the wall to QA.
Good points; these get to the heart of the matter. Should "development success" be (narrowly) defined as a measure of how well a development team fulfilled their role in the organization? Where does a "developer"'s responsibility end? What roles comprise the "development team"? Should a "successfully developed" poor-quality product still be considered a "software development success"? There is also the difference between ExternalQuality and InternalQuality - should a development that is on-time and on-spec, but ships inferior InternalQuality, be considered a "software development success"? If LeaderShip is accomplishing the task at hand while building relationships, as asserted in TheServant, then should a development that ends in broken relationships be considered a "software development success"?
I should have clarified the point that customer here is a role in the software development team (project owner; the party that defines, invest for, and assess the product quality). We're talking about a software development success, not necessarily about a commercial software product success. Many development teams are involved in large benefits projects which are technically speaking complete failures.
If you want to be able to measure software development success and that only, you should exclude any marketing, price, hype consideration. Given the requirements I would assess a software development success upon quality reached as stated by the "customer", productivity and maintainability. Of course the success of the software as a product relies on a multitude of other considerations.
That means that a PC 286 quickbasic software project done into a 10 people company in order to solve a very specific problem can be a software development success. And that a million buyers COTS product can in fact result from several software developments which were not quite successful after all.
Should a "successfully developed" poor-quality product still be considered a "software development success"? If by poor-quality, you mean that the quality level as defined by the customer has not been reached, then definitively not.
should a development that is on-time and on-spec, but ships inferior InternalQuality, be considered a "software development success"?
If new releases are needed, the maintainability (internal quality) will affect the cost of change and therefore the success of the development on the whole life of the software.
But for any non trivial project, it seems clear that maintainability is an issue even for the 1st release and has to be maintained from day one. For a 25 lines development project you can have a hideous code showing perfect external quality. But a 25 kloc software is not just a 25 lines project x 1000. In other words maintainability is the faster way to external quality.
As to the other outputs of a development software (new ideas, enforcing the organization cohesion e.g.), successful projects obviously allows such output. But failed projects could, too.
I like your success distinctions, Randy. If you divide success into categories, it makes a subjective "relative" definition of success easier. Project A was a better methodological success than project B; project B was a better people success than project A; projects A and B were about equal in design success; project B was a better on time success.
Maybe dividing success into categories makes mining success commonalities easier, too? Line up all the people success projects up against the metaphorical wall, and extract their commonness. Line up all the on time success projects against the wall... etc. -- StanSilver
p.s. I think that this topic is related to why Ward didn't allow one word wiki page names - two word page names often encourage a meaning-narrowing adjective and a noun.
Thanks for starting the thread, Stan. "Meaning-narrowing adjective" - I like it! -- Randy
EditText of this page
(last edited November 16, 2005)
or FindPage with title or text search