Crap Code Inevitable? Rumblings from the ACCU

Liam McLennan 25 minutes later:

• • I think he is right in a way – developers don’t value quality because their employers don’t value quality. But they should, because as you said, quality becomes cheaper almost immediately.

  • I for one embrace quality, craftsmanship and professionalism because that is the path that makes me happy. If I delivered shoddy work in the name of expeniency (and at times I have) I would lose my self-respect.

  • It sounds like Josuttis needs a holiday.

Stefano 29 minutes later:

• • Bob,

  • I immediately signed to the “Manifesto for Software Craftmanship”, which I just discovered.

  • I believe most developers are not familiar with the concept of Technical Debtand how procrastinating refactoring will only slow you down more and more.

  • I so much hope your vision of the future is the right one…

Seb 33 minutes later:

• • I think you’re misrepresenting Nico’s argument. What he said was that the people who ‘control’ the development process think that crappy code is cheaper.

Martin Larsson about 1 hour later:

• • I think you’re right when claiming crappy code is “vastly more expensive, even in the short term”. But it’s easy to write tests that make crappy code pass. So crappy code can be made to look cheap.

  • And it’s difficult to test the tests, to prove that the tests will weed out the crappy code.

  • But I doubt adding a layer of indirection (ie. DSL) will increase code quality. I predict a DSL, any DSL, will eventually be maintained into a general purpose language, but with only one purpose, the application it is embedded in. At that point (or possibly even before), maintaining the DSL will demand more effort than maintaining the application.

  • M.

Suresh R Iyer about 1 hour later:

• • Fantastic post, as usual, uncleBob. I think the two main impediments to code quality are a) lack of sufficient number of craftsmen—people who can show and prove it can be done with better quality and in reasonable time, and b) management (some of whom were once developers of some sort) don’t really appreciate the importance of code quality.

  • It was indeed a sad day earlier this week when I heard that you can’t expect everyone to read books and learn NOT UML, not design principles, NOT design patterns, but basic OOPS! And yes, we were NOT talking about freshmen out of college, but about people with a few years experience under the belt.

  • As long as we have such crappy benevolent attitude towards study (which is mandatory to become a good developer and eventually crafstman some day) and code quality, bad developers can thrive and continue to write crappy code. Of course it might be convenient for the blame to be fixed on them when the inevitable mishap happens, but that blaming occurs after the fact.

  • Earlier this week @venkat_s talked in the local Agile group about the circles of Relevancy (for the business) and Expectation (unit and other testing that assures code quality), and how the former cannot exist forever without the latter. However, what happens in reality is, most of the time, the management is worried only about the first circle, and in their mad rush to meet the deadlines, they allow the code quality to go for a toss.

  • The more years I spend in this industry the more I am convinced that you need real good programmers in the middle management to run the show if quality has to remain important, or we need non-programming who believe in the vision or ex-programmer managers who wouldn’t mind coding today if required. The best part of the deal for the management is that they don’t have to spend the weekends maintaining the bad code, the lowly developers are there to do that. They just have to give the orders on Fri evening to ensure the team is working over the weekend.

  • Though this comment post starts to appear like a rant, I guess there is lots of truth in it, at least from an Indian perspective.

Simon about 1 hour later:

• • Surely the people who ‘control’ the development process think that whatever they perceive to be quicker is quicker. If that perception is based on time to first delivery (for example) and that is quicker through clean code than through crappy code they will not press for crappy code. It is down to professionals to maintain the quality and the momentum that creates. I believe that the time to first delivery of any non-trivial system will be quicker done clean if the developers are “craftsmen” and “craftswomen”.

Simon about 1 hour later:

• • Surely the people who ‘control’ the development process think that whatever they perceive to be quicker is quicker. If that perception is based on time to first delivery (for example) and that is quicker through clean code than through crappy code they will not press for crappy code. It is down to professionals to maintain the quality and the momentum that creates. I believe that the time to first delivery of any non-trivial system will be quicker done clean if the developers are “craftsmen” and “craftswomen”.

Rob about 1 hour later:

• • I must confess that as I read your comments on Josuttis I flipped the bozo bit. I flipped it on Josuttis. Low quality is always driven out of the market place eventually. Low quality breaks trust between buyer and seller. Once broken it takes a long track record of quality to recover. Take a look at General Motors. I would claim the opposite: Quality is inevitable.

Mike Woodhouse about 1 hour later:

• • Marketing pressure to ship crappy code can only be applied in areas where there are financial imperatives to do so. You could argue that, in some companies (cough Symantec cough Corel cough) we may already be there. I won’t mention Vista (more than that one time) because it’s just too easy.

  • Enterprise developers have, in their capacity as the underwater element of the iceberg, and only for the most part, been delivering crappy code for ever. I’m one of them and I see plenty. Heck, I wrote a lot of it when I didn’t know better. Now I know when I’m writing crap, which is at least a start in the right direction…

  • Open source software, on the other hand, doesn’t suffer from the same need to feed the children/dogs/hamsters/crack habit. Will we then see OSS becoming the home of quality software, and paid-for being hived off to the niche? I’m wondering how that world might be different to today’s one and what would have to happen tfor that to be the case. Could, for example, an OSS OS be built that could replace Windows (or OSX) on the average person’s computer? There’s nothing out there at present that seems to fit that particular bill.

  • Fun times.

Martin Larsson about 1 hour later:

• • Rob said “Quality is inevitable.“

  • You haven’t watched much TV lately, have you? :*)

  • M.

Gabriel Lozano-Moran about 1 hour later:

• • To use a metaphor: sometimes a customer wants a Fiat instead of a Ferrari so why should the Fiat car builders use the same build process and quality control as used in the Ferrari factory. Sometimes the customer has only money for the Fiat and wants it build in less time than it would take to build a Ferrari. Sometimes the customer does not mind that the Fiat goes slower or accerelates slower than a Ferrari because it is good enough.

  • I agree that software quality is important but we should stop trying to find the holy grail of software development.

  • Having these discussions just shows how immature our world of Software Development really is.

  • The real answer is: it depends.

  • It depens on what the customer wants and what they are willing to pay for as long as they are aware of the implications of having a specific degree of software quality.

Mario Gleichmann about 1 hour later:

• • We do not need to much developers producing to much code – we may need few developers producing the right code …

Andy K about 2 hours later:

• • Coming from a 1000+ employee corporation with several national offices, Mr. Josuttis’s comments sound spot-on to me. The business decision-makers do not comprehend the process of technology – they want to see implementations that produce revenue. They don’t really care how that happens.

  • Blaming developers for writing crap code is to ignore the context in which they find themselves. They make the best of vague and incomplete requirements demanded on an unreasonable schedule.

  • In a better economy, these developers would move on and that may cost the company. In the long run, the technical debt will cost the company, but they’ll never see it that way.

  • Short-term thinking is the name of the game. One solution is for developers to go consultant and sell their services back to these companies. Same work – process control shifts in favor of the developers.

Channing Walton about 2 hours later:

• • I wonder how bad does it have to get before the business wake up.

  • I have just come from a bank in which it is standard practice and expected that a project will require a small army of people to maintain it once its gone live. eg 10 people build the project and 120 maintain it – I am not joking!

  • Even when bad code results in multi million dollar mistakes the business do not put pressure on IT to improve quality.

  • Even when a high quality system is delivered that shows no bugs in production for months, nobody wakes up and says, “how did they do that, can we have more of that please!”.

  • High quality code is not more expensive and does not take longer to produce. Seems like a no-brainer to me.

Tiago Fernandez about 2 hours later:

• • If I ever accept that crappy code is inevitable, please fire me. Mr. Josuttis got it miserably wrong!

Dave N about 3 hours later:

• • Even though I am at the core a bleeding heart liberal, I do believe in the market and incentives. So this leads me to think, “A lot of crap code exists, what are the incentives that support this.” We have to look at the incentives.

  • As a mid-level to senior developer, I have seen some incentives for producing crap. Incentives to individual programmers, read bonuses, are often based on “meeting” the ship date. Uncle Bob argues, and I agree, that there is an ethical imperative to deliver quality code. However, as I am human, I am sure that I am influenced by the prevailing incentives. Sure the technical manager can influence the distribution of the bonus pool, but often this pool only exists if the ship date is met. And with the short-term focus of such incentives, often the “shortcuts” taken are not apparent until after the “incentive” distributions. The design debt is real, but often the payment comes due later.

  • Now I am trying to not just whine about this, I am seeking answers to the questions that I believe Mr Josuttis was really asking; at least this is the question I am asking. Not “We must finally accept that code will be crap and so we must ???”, but “organizations don’t seem to value solid code, how do we convince them.” And with the incentives that I see in the marketplace, I am convinced that they do not value solid code.

  • Just curious and in the Dennis Miller vein, “Of course, that is just my opinion, I could be wrong.”

Channing Walton about 3 hours later:

• • Gabriel said: Sometimes the customer does not mind that the Fiat goes slower or accerelates slower than a Ferrari because it is good enough.

  • True, but we seem to be in a situation where its acceptable to have a van of mechanics following the fiat down the road to repair it when it crashes every 5 km, taking out a pedestrian or two.

  • I don’t think its a question of us trying to find a holy grail, but simply having a basic level of quality. It is never acceptable to deliver software that crashes or is full of bugs that could have been avoided at no extra cost.

Simon about 3 hours later:

• • What if the Ferrari were cheaper than the Fiat, both to buy and then to maintain? Which would you choose then?

  • Design metaphors (such as the architecture of buildings or a production line of cars) for software creation may be (have been?) useful for some purposes we must know when to let go of the metaphor because it just doesn’t fit for the purposes we are applying.

Zach Dennis about 3 hours later:

• • Gabriel, the metaphor for a Fiat and a Ferrari doesn’t work very well given your “it depends” claim at the bottom of your comment.

  • A Fiat and a Ferrari are built w/quality, but they have different product goals so they are built differently, and for different total cost. If our software is like a car, I would think the customer would want a quality car rather than a lemon that has to go in the shop every few days, regardless of whether it was a Fiat or a Ferrari.

Shane H about 4 hours later:

• • I agree with Andy K. This is just another example of common short term thinking. Maybe some of the managers figure that they won’t be around when the application needs to be re-written because it becomes too expensive or too slow to maintain and change. I suspect they figure that this will be someone else’s watch – so they don’t own it and don’t mind that the company now must spend millions to replace the application. How these managers are measured also impact how they will behave – if they are measured on short term results (like faster delivery) and not long term results (like maintainable applications) I can forecast how they will act. Overall, it reminds me of the recent advertisements that Honda has on TV now – they are encouraging customers to look at total cost of ownership before they buy.

  • If managers were measured on long term: 1. Customer satisfaction 2. Velocity (how many story points delivered) 3. Cost per story point 4. Bugs/quality 5. Technical debt we might see some change in behavior. Unfortunately, many managers are willing to build up a huge technical debt that will be someone else’s problem.

  • A lot of this is driven by current management culture. A manager with “problems” (like technical debt) must be a bad manager, so those managers don’t want open and honest discussions around these problems. This tends to hid problems until they can’t be hidden any longer – instead of exposing the problems and engaging the organization to fix them before they are un-fixable.

JohnOpincar about 7 hours later:

• • I’d be happy if we got to the point where most developers could at least recognize crappy code.

  • I’m surprised that anyone that’s spent significant time in the industry could advocate for crappy code. As someone above pointed out, you can and should produce quality code all the time. If you have a tight timeline, you can still do things in a quality fashion. The only way you can “deliver” a product more quickly with “crappy” code is to simply shift development costs from before to after some arbitrary release date. Sadly, this is the current state of affairs in most of corporate America—it’s not specific to IT.

  • Alot of the problems we’ve faced recently stem from a lack of basic integrity in business today. Hopefully we will see the folly of always managing for the next quarter and get back to the point where leadership strives for real, long-term, ethical gains.

Roland about 9 hours later:

• • We could not create reliable requriements, we got agile We could not create good programmers, we invented code completion, intellisence and automatic refactoring and the invention is still going on.

  • A wise man said that we should not be angry on the management for doing bad decisions about our code. They have the companies best intrest. A bad program today might get them an affair tomorrow. If the program is deliverd in two weeks the developer is unemployed and the company bankrupt. Look at facebook, there wasn’t a craftman ner the code in the beginning, but they got customers.

  • So, please be a little humble about salesmen and managers. They pay most of our salary.

Roland about 9 hours later:

• • We could not create reliable requriements, we got agile We could not create good programmers, we invented code completion, intellisence and automatic refactoring and the invention is still going on.

  • A wise man said that we should not be angry on the management for doing bad decisions about our code. They have the companies best intrest. A bad program today might get them an affair tomorrow. If the program is deliverd in two weeks the developer is unemployed and the company bankrupt. Look at facebook, there wasn’t a craftman ner the code in the beginning, but they got customers.

  • So, please be a little humble about salesmen and managers. They pay most of our salary.

Ollie Riches about 9 hours later:

• • Sorry Bob I think you missed an important point about ‘drag’ – when the drag of keeping up a velocity becomes to much, management scrap projects and start again with a new ‘version’ or a new ‘greenfield project’ and the whole cycle repeats it’s self.

  • When the whole world (business and society) is modelled on ‘just in time’ supply, why do you thinking people are going to pay more upfront when people (management) only work for their yearly bonus or promotional prospects…

zvolkov about 11 hours later:

• • Let me add some color to the world of black and white.

  • Like I argued with Alistair Cockburn the other day, we need a well-defined Dirty Development methodology, or more precisely, an ordered set of practices that we drop as business pressure increases complete with reasons why certain things should be dropped and the sequence in which we should do it. This way people would know that it’s Ok to drop, say, formal requirements documentation as long as you have Fitness tests intact, or it’s Ok to layoff the QA department (if you have to) as long as you have automated tests in place, but not the otherway around.

Phil Nash about 14 hours later:

• • Of my last two jobs, in the first, during an appraisal I was marked down for writing “elegant code”. In the second I was marked down for spending time improving the quality and productivity of the developer community within the whole company, rather than just churning out lines of code.

  • The first was a mid-size software company, the second a top tier investment bank.

  • I really hope you are right, but I don’t think Nico is barking up the wrong tree either.

BJ Allmon about 17 hours later:

• • Good stuff as always. Management never forces me to write crappy code. It’s my job to do that. Or not. :)

Wedge about 20 hours later:

• • I think both impressions are correct. The total number of programmers will almost certainly continue to grow. There will be growth in both the number of expert software craftsmen as well as the number of crap coders. Indeed, even if the percentage of coders who are expert craftsmen grows, it’s very likely that the absolute number of crap coders will increase.

  • Sad. But probably realistic.

  • Yet I very much agree with Uncle Bob’s imperative for greater code quality. The existence of crap is no excuse to ignore the very real benefits of quality. Furthermore, the distribution of code is uneven. Quality code is more likely to be important code, crap code is more likely to be unimportant.

  • Consider written language. The volume of examples of poor uses of written language has exploded exponentially over the last several generations. Does that render Shakespeare, Dickens, Twain, and Faulkner irrelevant? If I span a creek using a 2×6, does that invalidate the value of the Golden Gate bridge?

Jack 1 day later:

• • In my experience, Josuttis is right. Especially in a time of belt-tightening, the notion that a company is going to let you spend your time learning the latest and greatest coding techniques and training other developers in these latest and greatest techniques is ridiculous. So the premise of the Uncle Bob argument is flawed, because the formation of this legion of “professional developers” will not satisfy the “business’ need for speed.”

  • Also, the Uncle Bob argument seems to assume that “quality code” relies on these latest and greatest principles. I think you need to take a step back and realize that most companies are still running on mainframe COBOL backends, while this “quality code” is the pretty user interface. The reason the backends don’t change is because they just work. And they also aren’t written with this month’s favorite development methodology. So the assumption that quality code relies on the latest alphabet soup of principles is wrong.

Jack` 1 day later:

• • In my experience, Josuttis is right. Especially in a time of belt-tightening, the notion that a company is going to let you spend your time learning the latest and greatest coding techniques and training other developers in these latest and greatest techniques is ridiculous. So the premise of the Uncle Bob argument is flawed, because the formation of this legion of “professional developers” will not satisfy the “business’ need for speed.”

  • Also, the Uncle Bob argument seems to assume that “quality code” relies on these latest and greatest principles. I think you need to take a step back and realize that most companies are still running on mainframe COBOL backends, while this “quality code” is the pretty user interface. The reason the backends don’t change is because they just work. And they also aren’t written with this month’s favorite development methodology. So the assumption that quality code relies on the latest alphabet soup of principles is wrong.

Balabin 1 day later:

• • It looks like everybody is talking about creating software – be it quality code or complete crap. What about maintaining crap software? Lots of people have to deal with huge mountains of crap being constantly pressured for new features instead of nice refactorings and being a good craftsman does not help much because in this case copy/paste and following cargo cults does really seem as a quicker way of doing things. I am not advocating for anything, just trying to look at things from a bit different perspective.

mob 2 days later:

• • I think Liam makes a good point; employers don’t value quality, period. Some say they do but their actions speak otherwise. They are looking for a quick fix, long term is not important. And I also think that Phil Nash makes a great point that managers (and even other crappy developers!) act as if your not doing your job when you strive for quality in new and existing code. While you’re being reprimanded for craftsmanship, Fast Eddie is whipping out crap code and getting praised. This is a real and widespread and while personal integrity is essential, managers and coworkers can stifle craftsmanship by their attitude.

  • As far as time/money goes, poor quality code is much cheaper and faster in the short term. And it seems that getting a feature to market as quickly as possible is the priority even if its coded like a prototype. It’s VERY rare that a manager is concerned with the long term. As an experiment I’ve often wanted to write a feature in the worst way I could but in the shortest amount of time and see what the reaction would be. I guarantee it would be favorable in most organizations. Reprimanding craftsmanship and rewarding crap is a serious problem!

  • We can change ourselves but how do we change these organizations and their managers? I really think that should also be a real high priority of the craftsmanship movement.

AlisdairM 3 days later:

• • I think you misunderstood one of Nico’s key arguments, and that is at the heart of the discussion here. It is not crappy code that is cheap, it crappy developers. Developers are often seen as a commodity resource purchased by management, and supply/demand is driving price down with too little regard to quality. This makes crappy code an inevitability, a fact of life we must cope with. Therefore, successful development practices of the future will be those that accept a large part of the team write crappy code, and adapt to that, minimizing the cost/risk they add to the system, and making best use of the few key experts that can do better. The prevalent view at the moment, with ideas such as software craftmanship, is that we should train all developers so they write code like experts. We have been trying the ‘education’ strategy for 30 years or more, and although a proven success where it happens, the trend is more frequently to replace the expensive experts who can educate with cheaper developers who will just write code without asking questions.

  • I still believe the craftmanship agenda is important. The experts need to understand how to take the state of the art forward. For those pockets of excellence that survive, they still need to find ways to excel. However, the reality is far too often we are dealing with non-technical managers who still believe you solve problems by throwing manpower at projects (oops) and Nico’s call makes a lot of sense from this perspective. It is not so much that we praise crappy code, but accept it is going to be a fact of life and look for how we can best manage it, and mitigate its risks. Where are the key places to apply ‘best practice’ if we can cover only a small portion of the project-space?

[email protected] 4 days later:

• • The problem is that in software, the product quality in terms of craftsmanship, is not directly “seen” by the final costumer. They see the product working, they don’t see the code. So managers, in general, have the misconception that code quality just influences developers and not the costumers. which is wrong because, even though the code quality seems transparent for the costumer, its costs in time of development, that is charged to the costumer, and the costs in bugs, influences them directly.

Steve Py 5 days later:

• • Crap code has always been around, will always be around. It is a part of human nature no more or less than the desire to attain a new height in efficient, elegant code.

  • It’s no different than the blog/wiki/twitter/myspace/facebook movement. Sure, there are people out there that want to put in the hard yards to write the next Pulitzer prize winning novel, and for every 1 that succeeds, 1000+ try and fail, but that’s a infantesimal fraction of the number of people that blurt out their thoughts, opinions, and drivel as fast as their fingers will type; spelling and gramatical errors part-in-parcel.

  • Worrying about code craftmanship is worth no more concern than authors worrying that there’s no point writing books because everyone can just drivel online to reach massive audiences. The simple fact is that there will always be people that respect and value quality. But there’s no point bitching just because “everyone” doesn’t have that same respect.

  • I was recently asked “What is Quality?” and my answer was simply that “Quality is delivering what the customer wants.” It’s not about what they “need”, or what they “say they wanted.” (From day 1) It’s that by the end of the project they can confidently say you’ve delivered what they are happy to use. That is what quality means to “me”, and Agility is a tool I use to accomplish that. I use Clean Code principles to try and provide value where I can, and self gratification that I can accomplish something better and faster than before. But that alone isn’t the end-all of my quest. I seek customers that hold my efforts in praise and come back. Quality is a badge that is earned by putting in the hard yards and making every effort to deliver what will make customers happiest. Just remember that the customer includes the people providing the investment.

  • My $0.02 “drivel” ;)

JR 5 days later:

• • Over the years, I have seen the company I work for go from a place where engineering would not ship a product until they felt the code was of a high level of quality to one where Time to Market is king.

  • I was recently in a meeting where a relatively high level manager complained when QA actually wanted to test on a real prototype device prior to launch.

  • QA was worried that some of the assumptions put forth by the product team were highly risky and they wanted to minimize the risk by testing on a “real” device and not a similiar device that was modded to act like the new product.

  • Add in the global economic meltdown and you have even more pressure to do things on the cheap.

  • And many companies believe that it does make business sense to slap things together and throw them out the door….......

Indrit Selimi 6 days later:

• • Hi Bob,

  • I immediately signed to the “Manifesto for Software Craftmanship”. I have changed working place from about 2 weeks and I’m facing exactly the crappy code problem that you have described here. I fully 100% agree with you. In my precedent work place I was working in Milan within (in my opinion) a highly productive, high quality and in some way “homogeneous” team; but the company doesn’t fully understood the potential and hard work that my team was doing and some stupid “political” problems started to rise; so the result was that one of my “preferred” moved in other companies, as after them I did. But I’m discovering than in this company developers, managers and etc doesn’t no nothing about code quality(and in general about software engineering)!!!. I’m very very sad about it… because this company is a very big (and successfully) one that I thought they have a high quality standard but I seeing that they are of “Josuttis’s Party”... they are giving to me exactly the same (IMHO absolutely not valid ) arguments: “here the time required by the business staff doesn’t permits us to have a good quality and bla bla bla”. The irony is that I’m analysing a crappy program(that MUST go in production) that no one knows how it works and practically the effort will be much much higher….

Which Wins 9 days later:

• • If you folks will forgive an observation from a Non-tech Craftsman:

  • The conflict in which you find yourselves ensnared is neither new or unpredictable. Since (at Least!) the beginning of the Industrial Revolution, the concept of craftmanship has been under pressure from the demands of “the market”. The central problem is when the consumer of a good or product is either unable to discern or uncaring about the quality of the product s/he is purchasing AND there is an abundance of inferior, but still serviceable options to the quality product.

  • Historically, the Very Best practitioners of such a craft manage to carve themselves a commercial niche catering to that shrinking segment of the market which is willing to pay more for the best. The rest become cogs in the machine….(think textile workers vs. Quality Tailors).

  • The other model is the Unionization of ALL labor, either through a Guild which certifies The Craftsmen ( Doctors, Lawyers, Educators, Diamond Cutters…) and is able to enlist The State to encourage or require that their standards be upheld…..OR the more common (and less effective ) Trade Unions ( AFL-CIO et.al.)

  • Good Luck.

  • You folks have a fight ahead of you

Jeff 10 days later:

• • I agree with AlisdairM.

  • Software craftsmen are rare and highly differentiated individuals. Their value is immeasurably greater than their salaries and related expenses. Hiring large numbers of them in one place is next to impossible.

  • Crap programmers and crap product managers are cheap readily available fungible resources. You can hire them by the boatload sight-unseen and outsource their provisioning if you like. They come with certifications of minimum competence excreting code. With adequate training a few of them may become software craftsmen themselves. Left to their own devices they will sink or swim which is just fine for most businesses as long as they produce some immediate value and don’t rock the boat.

Eric Smith 11 days later:

• • ” ... Low quality code is not cheaper; it is vastly more expensive … “

  • Where are the numbers, Uncle Bob? This kind of argument will continue until someone can put some solid, irrefutable numbers against all of this; and in a way that is accessible to decision makers:http://skepticabin.wordpress.com/2009/04/30/the-great-microsoft-imposed-development-culture/.

• >

Dave D 14 days later:

• • Unfortunately, at least where I work, those of us who consider ourselves professionals, and try to maintain a level of craftsmanship are finding ourselves more and more outsourced. We are finding that the code we are getting is pure crap. The level of expertise demonstrated in the code that I have seen is abysmal; it appears that the developers have recently completed a 6 week course in Java. My attempts to encourage best practices have been met with disdain and an attitude that I have no idea what I’m talking about.

JM 20 days later:

• • It would be interesting to know what people think is quality code, crap code, best practice, etc.

Norbert Winklareth about 1 month later:

• • Mr. Smith, the problem is that there are no irrefutable numbers as they are situational, there are however irrefutable models. It is has long been determined, not only in software field but in many others, see Managing the Design Factory that the earlier defects are removed the less the overall cost of developing and maintaining a product. ProfessorKhaled El Emam has researched, developed and tested predictive economic models that show The ROI from Software Quality. A more recent, 2009 versus 2005, cross industry model that shows that investing in quality and learning leads to superior performance see Stephen Spear’s Chasing the Rabbit.

• By the way, just because there are these irrefutable models and or numbers does not of itself insure adoption of a practice, technique or methodology. As proof I submit:

  • Nato Science committee report on the 1968 conference on Software Engineering

    • Barry Boehm’s Software Engineering Economics, first published in 1981.

  • Both of these publications show the need and/or irrefutable benefits of improving quality, yet neither resulted in wide-spread adoption within the development community or the businesses that use the services of this community. Note that this is true of all industries as Mr Spear has shown in his book, so for me this is a basic human problem and we know that we can change.