I used to believe the practicing "good" software development methods tends to yield a better product in the long run. However, I've seen quite a few cases where "quick-and-dirty" \ "brute-force" \ "copy-paste" programming appeared to give decent results quicker, and cheaper. This appears especially in cases where time to market is more critical then maintenance overhead.
Is there a correlation between the quality of the development process and techniques and the quality of the product?
A Software Development Process (SDP) is simply the way your team builds software. A good process will allow you to repeat your results project after project. NOTE: this says nothing about quality, only that you can repeat what you did last time. It's about the day to day business of writing software and making sure everything that needs to get done actually does get done.
Process Improvement is something that should be part of everyone's SDP. Essentially you should keep an eye out for inefficiencies/choke points, and places where your process is working against quality. You want to change your process at the moment you identify the problem so you can fix it. One change at a time, until you are not only repeating results, but repeating quality results efficiently.
Concerning your example
A team that uses "brute force" or "copy-paste" code has an SDP. It's not elegant, but it exists. It's the way they are approaching the problem. However, it's not a sustainable process. It can only work for trivial and unimportant applications. Those apps exist (like the "Is it light outside?" iPod App), but are very small (i.e. trivial) and very quick (i.e. less than a month to build).
Any time you have a sizable app, or the application is important to a company, you can't skimp on quality. The short term gains you had in the beginning will quickly be lost as the team spends all their waking hours in a debugger. Or possibly tracing through to find the bug related to copy-paste code that was modified in one location but not another.
Knowing that the team using brute force has an SDP, they can start to change their process to force them to improve their quality over time. The key is to fix one part of the process at a time until the process is efficient enough.
Regarding process improvement
Whenever I'm tasked with process improvement, I'm looking at a couple of things:
You'll find a couple of things when adopting the philosophy of continuous process improvement. First, you may need to introduce some process (like a peer review) to address a quality issue. Second, the process you introduced (like a peer review) may no longer add value once the team is no longer reproducing those errors. Or you may be able to catch those errors in other ways (like static analysis programs, unit testing, etc.). Just don't lock yourself into a "Process" (note the capital P) and worship it. Small adjustments over time always produce better results than wholesale change.
You can only learn whether the improvement actually improved the process when you observe its affects in isolation. When you change everything, you haven't learned any lessons and are doomed to learn new painful lessons you didn't see before.
The fundamental question behind yours is how you define "good" software development method? So many Methodologies have been touted to be Silver Bullets and failed miserably, so one should have a way to assess and measure things. There are e.g. organizations claiming to be at CMM Level 5, and still delivering... well... suboptimal solutions.
To me, the only meaningful way is to actually see the output of the process, i.e. the delivered software (plus documentation, etc. if applicable). And the quality of the delivered solution can't be interpreted without context. You naturally expect a very different level of quality from an in-house experimental app, than from NASA spacecraft control software.
For a once-only throw-away prototype, it can be perfectly OK to throw something together quickly, without documentation, design, tests etc. If OTOH you intend to maintain the product for years, you need to invest in all these, which indeed requires good processes. (Note though that there is always a risk that your throwaway solution is kept being used, thus all of a sudden you have a maintenance problem - software tends to outlive its expected lifetime, so you better plan for this in advance).
I guess we all want to work on quality software development projects and people who care more about the processes will tend to end up answering questions like this.
There is a place for a quick-cheap-and-dirty software solution - and that is where the lifespan of the software is very short - say less than a year.
I think that if the software in question needs to work for at least 3 years then a quick and dirty solution will be more costly than a well planned development - because of the bugs and reworking that will inevitably follow.
Examples
But if a project has a life span of less than a year I would guess that a quick-and-dirty approach will be cheaper to implement - and fixing bugs and adding new functionality may well be pointless.
Examples
Quality of Software usually doesn't decrease or increase gradually, but rather in a discrete and erratic way. So low quality software development won't necessarily impair the user experience imediately, but chances are increased that all of a sudden and seemingly out of nowhere your stuck with a bug or a set of related bugs that are not going to be fixed easily.
The quality of the construction substantially affects the quality of the software.
and
... your understanding of how to do construction determines how good a programmer you are ...
Says Steve McConnell in Code Complete 2nd edition, on page 8. I highly recommend you to read Code Complete for answers on this subject.
The only correlation that comes to my mind is that low quality SDP can result in more bugs, which in turn reduce overall product quality. Other than that, there is no real correlation, ie. I've seen poorly engineered applications that are percieved as great products and solid applications that are considered extremally crap products.
There is zero correlation here, as you note in your question.
The software development process is aimed at solving management and project problems - making sure the project is completed on time and on budget, requirements are identified and fed back to the team, bugs identified early, and so on.
As they say, pick two: "Cost, Speed, Quality".
Utilising a quality software development process is about managing costs and timeframes (note: not specifically minimising, but ensuring predictability). A lot of low-process projects deliver great software, and a lot of high-process projects deliver a dog.
I think you are funder-mentally mixing up "Good" with "Workable" solution.
A "quick and dirty" copy and paste does indeed deliver a working solution, but its gain is only short term.
Over time this leads to complexity and effectively a "ball of mud" code.
On the other hand software that is created that follows best practices, are initially longer to develop, but in the long run easier to maintain and add new features.
Its the old story of the Turtle and Hare Race
Quick-and-Dirty tends to create products that linger in the "95% finished" limbo. It's not uncommon to see a project "almost done" in just a few months, but then literally struggle for years to make it ready for productive use. This is especially critical since the go-live date is postponed again and again, month after month, causing all kinds of organizational and financial trouble.
Or, in the case of boxed software, the product is shiped anyway, but the company loses a lot of reputation and has to deliver patch after patch to angry customers. In these days, when you can always find reviews of any product within seconds on the internet, this has become a very dangerous strategy. "Time to market" is worth nothing when the product is simply not accepted by the market because of the negative reviews.
Just consider the iPad competitor "WeTab". They were months ahead of most other tablets, featuring a more powerful and versatile hardware than the iPad, but everyone knew that the product simply wasn't ready for prime-time, so AFAIK it didn't sell well.
It depends on who is doing the building.
If it is a small company trying to build 1 thing that is the crux of their business, and they want to be the first to do it, then time to market is the MOST important thing.
That being said, if the software is really bad, you might be first and then lose your customer base.
So the answer is....it depends.
I understand the point of getting to market. You have to start paying bills. The real advantage is getting to market AND being able to adapt to the features and functionality that the market really wants. At some point you'll want to refactor the quick and dirty code.
Based on your logic, there is no reason to discontinue this practice. Everybody always wants everything sooner, but that doesn't mean you should do it. Eventually, your app will slow down, you won't be able to keep up with the changes, and you'll continue to introduce bugs into the system. Users will assume if you grant their wishes, these consequences will not occur.
Edit: Correlation/Causation: Maybe those that follow a quality software process just know how to make good software. If you don't know what you're doing, following good methods will only take you so far.
