I'll be speaking about the role of testing in agile development in a Merito Forum seminar on October 13th. The preliminary program is available in pdf.

I've got an idea of the things I want to talk about in the short time they've scheduled for me but if you've got a topic in mind you personally would like to hear about in this kind of a seminar, please leave a comment.

We're almost sold out for the September 7th Agile Seminar in Helsinki, Finland:

Amazing.

It's been a while again since the last release of my favorite CI server, but it looks like the wait was worth it :)

CruiseControl 2.3, which was released this past weekend, now supports (among other things) Ant style properties in config.xml, remote CVS modules, and a bunch of new publishers. There's also some kind of "preliminary support" for distributed builds for those who've been anxiously waiting for it.

Not that they wouldn't deserve it every day, I feel a warm "thank you" for Jeffrey, Joris, Hack, and the rest of the bunch is in place!

UPDATE: I was just browsing the RubyConf 2005 website and spotted a mention about DamageControl, the Ruby-based CI server, having a stable release scheduled for Q3/2005. Nice.

UPDATE2: I also realized that I had forgotten to mention the one feature I was most excited about in the CruiseControl 2.3 changelog--the binary distribution with a built-in Jetty servlet container. That should do wonders for simplifying the first steps towards a running CI setup!

A smart name indeed, Indeed is a new kind of online service--a kind of aggregator for job ads in major job sites such as Monster and JobServe. Personally, I find it as useful as replaceable cellphone covers*, but I suppose it can be a huge help for people who look for jobs using such websites.

* I once got contacted by a recruiter through a UK-based job site who mentioned some kind of a management role in the telecom industry that required 15+ years of work experience. I was probably around 21 years old at that time...

Someone asked on the #ruby-lang IRC channel earlier today whether there's a utility somewhere for extracting URLs from a string. Since I only have a gazillion things I should've been doing, I decided to hack together some Ruby...

So, here's UrlRegex and a test for it.

If and when you find a flaw in the code, post a comment and I'll see if I can get myself to fix it ;)

UPDATE: I wasn't aware rafb.net's "paste" application loses old pastes that quickly. I've now uploaded the source code on this server.

Some weeks ago, I flew down to Dusseldorf, Germany to do a quick TDD training with a friend of mine for a (rather big) bunch of people. The session didn't go quite as smoothly as some others but we also couldn't spot any clear warning signs during the training. It certainly wasn't like David's jaws-drop presentation on Rails but we thought it went ok.

Well, the attendance did go down throughout the day as people didn't come back from breaks but that's business as usual in the company so we didn't think twice about it. Besides, it would've been a small miracle if a room of 45 people including several managers would've stayed for the whole duration of a rather pure technical full-day classroom training.

The feedback we got afterwards really took us by surprise on some accounts. Apparently, we had lost some of the audience right in the beginning because of certain communication issues. We also screwed up some things involving cultural differences--things that were an issue in Germany even though it hadn't been in Finland so far (even though our cultures seem to be very close). It took a while before we could put together an analysis of some sort about the things where we went wrong, sitting at an airport cafe munching on overpriced but oh-so-delicious sandwiches.

We also realized that our content was too thick on theory and too thin on practice. Unfortunately, many companies prefer to "spread their peanut butter thin" by squeezing 20, 30, or even 40 people into a training--which leads to the session becoming more of a lecture rather than a training. At least for the majority of participants. Luckily, I've heard that they've themselves acknowledged that it's better to go for high-bandwidth communication with fewer people than low-bandwidth communication for more people.

I've long recommended to my clients asking for training a sequence of shorter sessions spread out rather than a single, more intense multi-day training. The reason being that it's difficult to absorb that much new ideas and new techniques without having the time to play with them a bit and to mirror them with your ongoing projects. This spreading out is not about spreading it thin. It's about spreading it just thick enough.

Anyway, it looks like I might be doing some consulting in Germany in the near future. I'll have to try and observe myself and my surroundings a bit more carefully this time. Oh, and I hope I'll actually get to meet some old friends this time around -- the last time I missed both Frank and Ilja because of bad timing and a tight schedule.

Here's my quote of the day, coming from Jon Eaves:

"Tools should be used to automate tasks that people understand how to perform,
not provide a crutch for people to perform tasks that they don't understand."

Here's a good one about the power of simple text files:

Right. It's 10:30 PM and about the right time to clean up my ToBlog list a bit.

Joel Spolsky has always been a PR wizard of a kind. His latest is a good example of how he manages to get attention to his company/product by (I assume) intentionally making provoking statements that get people talking. And here I am, giving Joel a couple of more click-throughs... My motivation is, of course, to draw some attention to exactly what Brad is saying in his blog entry--that Joel either doesn't know **** about XP or is knowingly seeking attention by throwing flamebaits at "the XP crowd."

Someone on my blogroll--or someone who's on the blogroll of someone who's on my blogroll--brought URL123.com to my attention. URL123 is a competing service for TinyURL.com, i.e. they generate you a short link that forwards to a longer URL making it easier to embed, for example, links to emails and so forth. Even though URL123.com seems to boast about having more features than TinyURL.com, I find the additional features rather irrelevant. What matters most is not that I can create "personalized short URLs" but that I remember where to get the service I want--the short URLs. An important factor is whether such a service can be integrated into the browser. URL123.com and TinyURL.com both offer a JavaScript link that you can import into your "personal toolbar", for example, and from thereon create the short URLs a bit easier. I just wonder how many services are losing customer because they do not have such integrations available? I mean, those JavaScript snippets are hardly rocket science...

While I haven't personally suffered much from Sun not fixing too many bugs in their JVM and libraries and ignoring clearly essential missing features for years and years, I can't resist the urge to post some of them out in the open again. Many have done so in the past and for a number of years, no less.

For example, this little feature request has been on the record since 8 years ago and will only be fixed once Mustang (Java 1.6) comes out although they did mark it closed/resolved already. This one has been waiting for 6 years and is scheduled for Java 7.0 so it'll probably be 2007 before it gets done. Unless they postpone it again, of course.

I don't mean to slash against Sun and cry foul but, seriously, is this the way Sun invests on the future of Java? Seriously? These things aren't exactly rocket science--just hard work. Now, the trick is of course that Sun isn't charging us a dime for using Java and it has certainly been an improvement over C++ and VB...

Steve Freeman blogged only some minutes ago about Kent Beck mentioning a team somewhere [too much indirection already?] that...

...has become so good at delivery that they can release to production from the development desktop. No testing cycle, no staging environment, no sign-off; straight to production -- and this is a serious mission-critical system. Obviously, it takes a while for a team to build up that kind of reliability and trust, they have a track record of near-zero errors in the live system. Think how fast they can go [1].
...
[1] A measure of the sophistication of the team is that they don't work on production code when they feel tired or burnt-out, they know it's not worth it. I know of hardly any organizations that understand this.

While I'm not sure I know what it feels like to deploy "mission critical" systems to production straight from my desktop (I've only done that for non-essential funds type of stuff), I can certainly respect the wisdom this particular organization is exhibiting by having their developers work on the critical stuff only when they're at their best.

Alistair Cockburn was in Helsinki some weeks ago to run a workshop on agile software development for the AGILE ITEA project and since they were running short of participants from within the project, us externals got a chance to get in as well.

In general, I enjoyed the workshop a lot although Alistair seemed to be too harsh on XP in particular. Lots of familiar faces of course from Nokia and F-Secure, for example, but also a lot of interesting discussions.

Some of the observations made during the workshop were that some saw agile from a pure software development or project perspective while others saw it as more of a property of an organization. A lot of this variation was obviously due to people coming from varying backgrounds and varying roles. Similarly, while Alistair clearly separates "agile" (able to respond to change) and "adaptive" (agile + able to adapt itself), the audience (including me) considered the two to be largely synonymous. I suspect some of that is because the adaptiveness is largely a given these days even though the first descriptions of XP, for example, may not have included it explicitly.

Along these lines, Alistair also posed the suggestion that XP and Scrum are "Shu" processes while Crystal (his own agile method) is a "Ha" process. This of course refers to Shu Ha Ri, the progress of one's skill level from imitating known-good techniques to adapting the techniques to making no difference between techniques. The argument was that XP and Scrum define concrete practices to follow while Crystal suggests ways to adapt a process to the situation. Honestly, I found this a bit far-fetched since XP and Scrum also recommend very explicitly these days to adapt the process once you've got the experience to know how to adapt it.

Some specific ideas we went through included the use of video tape as documentation (in the context of the bandwidth and temperature of various communication media), the slope and the cliff, and a certain reality TV show as an example of setting yourself up for the next game. (this all makes more sense if you've read Alistair's writings in the past)

It was a good workshop. I hope you're coming back before XP2006, Alistair ;)

Just wanted to post a quote from Keith Ray on the XP mailing list:

If you recognize your place of employment from this rant, you're not alone. I've seen a lot of that, coming from a global consulting giant working for some of the largest corporations in Finland. My advice (and not just if you want to do XP) would be to consider whether you're proud of what you do and whether you would like to be, try to make management see the problem, and bring in a management consultant who actually knows something about delivering quality software (I realize that excludes most of the so-called "management consultants"...). Who knows, maybe it's not all lost yet.

With the risk of getting biled for a lousy conference report, I'll try and spill some of my XP2005 experience into bits and bytes. I haven't written about all of the sessions I attended, nor have I managed to capture everything that went on. Goes without saying, you need to have been there in order to get the full effect.

Coding Dojo

Laurent Bossavit and Emmanuel Gaillot ran a workshop around their concept of "Coding Dojo". Laurent and Emmanuel had started this weekly meetup in Paris, France where a small group of software developers interested in developing their programming technique while having fun would gather into a place somewhere--the dojo--to witness someone driving through a "kata", a choreography of developing a given piece of software if you will. Laurent and Emmanuel talked about developing one's understanding of three aspects of writing code: method, form, insight.

This concept of having a presenter code something from scratch on a projector in a rehearsed order of tests (test-first was one of the few rules they had laid out for presenting a kata) with a rehearsed implementation of each test and a rehearsed narrative talk to go with what's shown on the projector. The audience's part in this is to listen. The goal of the presenter is to get through the kata with everyone on board. Ideally, no member of the audience should at any time feel the need to ask "what the heck are you doing?", or "why are you doing that?", etc. The audience is also responsible for asking questions as soon as they fall off the wagon. Fast feedback, remember... This explicit focus on keeping everyone "on the bus" leads to a very simple suggestion for modifying your behavior when presenting a kata: don't assume, explain!

Laurent and Emmanuel also introduced a new term for a class of ping-pong development: "randori". Randori is basically "exploratory kata" where the whole group participates in carrying out the choreography. Except that there's no predefined choreography--you just go with your intuition. In practice, the group decides what they're going to implement (typically someone has written a set of acceptance tests before the meeting) and someone writes the first (unit) test. At that point, that someone will also make the first test pass and write a new, failing test before passing on the keyboard. The group will then go into a rhythm of getting the keyboard with a failing test they need to implement, implementing the test, and writing a new failing test for whoever's next in line. People would applaud upon each and every green bar. It's ping pong development. Nothing new, not nearly as enlightening as a regular kata can be, but loads of fun.

An interesting observation was made during the randori session we did in the workshop. The time spent without a green bar seemed to correlate strongly with the amount of chatter in the room. Spending more than 2 minutes on a given test and you could count on people starting to move their attention from the screen into something else. That's actually a pretty good indicator for many other kinds of situations as well. Keep an eye on chatter.

Regarding the community aspect of the coding dojo, the group in Paris had come up with a very nice routine for creating continuity. In order to keep the dojo going, they would start each meeting by agreeing on the next meeting. Similarly, they would not do a retrospective on the day's kata right there and then but would delay it until the next meeting. In other words, the agenda for each session would look roughly like the following:

1. Agree on a date for the next meeting
2. Discuss the previous week's kata
3. Vote today's kata/presenter
4. Run the kata
5. Go home

I haven't yet tried anything like the dojo myself but it would be interesting to see if that kind of a thing would fly here in Finland as well.

Weekly Refactoring Sessions

Jeff Nielsen of Digital Focus mentioned in a corridor discussion that they're doing weekly refactoring sessions with his team. They're essentially keeping a list of refactoring targets in an internal wiki, get together once a week to vote on what they're going to do from the list, and then go ahead and do it. This sort of a routine can be very useful if it works out--there's a lot of social issues to look out for, mostly to do with egos and perceived individual code ownership. I've seen plenty of teams keep lists. Most of them haven't acted on them, though. I was glad to hear that Jeff's team has.

Coming of Age

Jutta Eckstein's keynote titled "Agility - Coming of Age" brought up a bunch of perspectives on the (agile) software development world today that I hadn't really thought of until Jutta said it out loud. For one, the projects adopting agile methods are no longer the ones in severe crisis with nothing to lose. Projects are started anew using an agile method because it has seen to work and work well. Similarly, the projects adopting agile methods are no longer the simple, small, non-essential funds type of projects. Companies are betting their whole business on projects run with agile methods and being successful in doing so. On the same note, the projects are also not necessarily co-located--distributed agile software development seems to be a hot topic for many companies with global presence. Further evidence of agile methods approaching mainstream is that the German government has recently revamped their famous V Model for software development into "V Model XT". The "XT" stands for extreme tailoring and, apparently, it's not that far away from Scrum or XP--provided that you tailor your process in that direction.

Jutta's mention of distributed agile development raised some discussion on the type and volume of communication necessary to make distributed agile development a non-oxymoron. Obviously people's opinions and experiences were somewhat varied. Daily phone calls, netmeeting, whole-team video conference calls, daily hand-offs between continents with the whole team present... Whatever good techniques were mentioned, none of them are silver bullets. Using any of these tools does not guarantee a thing about the effectiveness of your distributed project team. Point. Blank. It's all about the people--your particular people.

The Elusive Business Value

John Favaro's keynote on the "elusive business value" was simply an excellent talk. In essence, John wanted to say that IT is myopic, nearsighted. IT in itself doesn't do much good in terms of revenue and profits. IT's influence on the company's success is indirect and John had come to the conclusion that many of us software professionals seem to forget that too often. As a true management consultant, John presented a diagram with four squares. The X-axis would represent the "goodness" of IT, and the Y-axis would represent the "goodness" of management. The lower left quartal would represent 0% increase in profit. The lower right quartal, with good IT but average management, would amount to some 2% increase in profit. The upper left quartal, with average IT but good management, would already bring a 400% improvement over the influence good IT alone has with an estimated 8% increase in profit. It's no surprise that the biggest increase in profit (20%) was in the upper right quartal with good IT and good management combined. These numbers are obviously rather meaningless (John had picked them up from some sort of a statistical analysis, I believe, but still) but the point behind the numbers is strong. IT alone won't do s*it for your investors. IT's role should be to support the strategies developed by management.

I made a note about looking more into value-based management after John's talk. Speaking of value-based management, John also noted that "XP has great decision-making processes that support value-based management" which is actually true for many other agile processes as well, including Scrum.

How to sell XP?

I also attended a workshop on "selling <your favorite agile method>". Some of the points brought up during the workshop included the gap between the customer and the buyer and, of course, the neverending annoyance called contracts. In short, and also according to my personal experience, the customers love agile. They love it. They might actually marry it if the church would let them. The problem is in convincing the buyer.

Some might argue that "selling XP" is not a problem--nor should be--and point out that you can succeed in being agile within a fixed-price, fixed-scope contract. That's actually what Reaktor has been doing a lot and with success. Actually, the scope often becomes unfixed rather quickly as the customers realize that their requirements specification was far from a perfect expression of their true needs and wants. Timo Lukumaa, one of our Scrum masters, will actually talk a bit about this in his talk.

When it comes to selling anything, we must be aware who we're talking to. That seems obvious but take a look around and observe how often people go into a "sales" situation with a wrong slant. For example, if you're going to try and convince someone to go with an agile process, you most definitely want to pick your focus according to the personal interests of the audience. Management cares about visibility--focus on the constant delivery, bringing problems on the table early, the savings from avoiding late bugfixes ($1500 a pop, according to some IBM/Gartner/whatever analyst report I once read), and so on. Customers care about functionality they themselves need--talk about how they're in control and free to change their mind. Developers care about quality software and personal safety--talk about the rhythm of delivery creating confidence, talk about the collective ownership, talk about people helping each other, talk about the techniques that help them produce high quality with less effort. Talk about them having the say on estimates. Talk about the customer listening to them. Remember who you're talking to.

The Sommerville keynote

You're probably familiar with "the Sommerville book", i.e. that textbook on software engineering that's going on its 10th edition or something and is being read by tens of thousands of undergraduates around the globe every semester. That Ian Sommerville did the opening keynote at XP2005, believe it or not.

Now here's the scoop: Sommerville believes Extreme Programming can deliver speed, quality, and lower cost. There you go.

His keynote, however, focused on the things he considers lacking in XP. For example, stressing that software projects are really socio-technical endeavours, he argued that systemic requirements often don't have a real customer, many users don't really want to be part of software development, and that customers and users are a bad source for requirements. I mostly disagree with that last one, but I do see his point.

Sommerville also suggested the creation of "why" documentation over "what" documentation (fully agreed), that we must define system boundaries (I think I disagree here), that we need to tackle architectural design explicitly, and that in general the literature needs to tell the whole story before XP can really become mainstream. Not surprisingly, the suggestion about architectural design raised some discussion among the audience...

Sommerville also talked about why we're still using waterfall even though practically everyone has said it's suboptimal and rarely works out smoothly. To quote him, "[waterfall] kind of works in sort of a way." That's so very true. People buying software projects are more afraid of getting yelled at for being different than for a constant stream of late projects with a constant budget overrun and a constant rate of churn. This is an aspect of the IT business I believe would improve significantly if people in charge of buying IT would be held accountable and given the power to do the right thing.

Training

I also dipped into the agile education and training panel on Monday. The panelists (Angela Martin, Steven Fraser, Rachel Davies, Mike Holcombe, Rick Mugridge, Duncan Pierce, Tom Poppendieck, Giancarlo Succi) were pretty evenly divided between industry and academia.

Some of the topics discussed included follow-ups. The academia has it easy. Myself, doing a lot of short training sessions with no chance for a follow-up, was very much interested in hearing other consultants' tips and tricks on who they're dealing with it. Rachel mentioned her contracts often being something like "three days a week for a couple of months", which sounded really good. In general, it's kind of obvious that long-term mentoring is more effective than a blitz training session. That's exactly why I've started suggesting multiple short sessions spread out instead of a single, intense two-day training, for example. One problem with traditional classroom trainings is that there's no think time. People need to relate what they're hearing and seeing into something their familiar with. Often times, the trainer cannot provide that experience productively.

The same problem is with measuring your own effectiveness. The follow-ups are also a chance for the trainer to get concrete feedback on how well he has managed to transfer ideas. One can do a lot of useful reflection based on purely self-observed details but it's no substitute for coming back a week, a couple of weeks later and see how the trainees have changed their behavior and routine.

Another issue mentioned was the "real world code" problem--how to balance between the "hello world" and the "seven-layer EJB architecture with integrations to a proprietary content management system, an SMS gateway, and what not." Unfortunately, and not surprisingly, nobody had a silver bullet to present. I've personally used a combination of simple examples to illustrate the technique, and more complex examples (focus on a single "difficult" technology) to illustrate feasibility in the real world. "It kind of works in sort of a way"...

There was also some discussion about letting students coach other students. Rick Mugridge is doing something like that in Auckland, and Alex (?) is doing something like that in Brazil. This is again one of those things that one can only wonder why didn't we start doing this earlier. It just makes sense. I suspect the biggest problems are, as in most cases when it comes to academic education, in how students are graded.

Tom Poppendieck also asked if anyone's training students to be customers before training them to be software developers. That really seemed to make people think--I could sense that a lot of people in the room were getting that "oh, hadn't thought of that" feeling.

When it comes to training (and this is what I had scribbled down as a "summary" when people were walking out from the training panel), there's no substitute for doing.

Kent Beck's ending keynote

Kent Beck was back this year to attend a panel on leadership and to make the ending keynote for the conference. In line with his recent theme, the keynote was titled "Up another notch" and focused on accountability (which is not about setting blame!). Tim Bacon had already posted a pretty good report of Kent's keynote so I'll focus on a couple of things Tim left out.

Kent mentioned the need for support. If it's you against the world, the chances are you won't come out as the winner. Everyone needs support. That's a given. The context in which Kent talked about support, however, was in "doing the right thing". It's easy to do the right thing if the rest of your team/department/company is also doing the same right thing. When they're not, we need support. We've all bit the bullet and survived a project where someone on the team has done more harm than good, and we've all had those moments when we've felt like that other guy is just too stupid to see what a wonderful idea we have. That's only human.

The insight that Kent gave me in relation to support was that the support doesn't have to be from your workplace. That really opened up a whole new dimension for me as I looked back a couple of years. Looking at all the discussions I've had about work related stuff with people who in many cases don't know Java from COBOL, I realize that those very discussions have helped me both vent my frustrations as well as guide my thoughts towards actions to take. I'm pretty sure I would've made a lot of worse decisions than I have if I hadn't had that support.

Kent also mentioned a couple of real life examples of how accountability means rendering an account of your actions. Google's "I feel lucky" is one such example. Simply by having that feature, that button next to the search field, Google is making itself visibly accountable for the quality of their service--the first hit must be the most relevant one. Another example Kent mentioned was how Agitar makes their own software metrics publicly visible. Although I can't find them anywhere on their website, the idea certainly is valid (although I'm not so sure about whether "metrics" is the best type of information to expose...) and worth considering if you want your company to produce quality software--make it clear that there's no room for bad quality.

Ok. That concludes my report from XP2005 (which was already two months ago...). I hope you got something out of it--I certainly did. I'm already looking forward to XP2006 next summer in Finland.

Starting with a couple of pointers into the blogosphere...

• Glen B. Alleman posted a briefing of a $3.3 Billion program which looks quite much like a briefing given by an agile coach to a regular software project.
• James Bach's thoughts on making intermittent problems reproducable was a nice read.
• Robert Watkins blogged about a nice-looking approach to maintaining test data in simple YAML files. I should probably try that some time.
• Jason Yip shrinked the manifesto into four suggestions. While I still kind of prefer the longer version, Jason's dumbed down version certainly speaks to me.
• Kevin Rutherford stresses the importance of asking the three questions. I'd like to stress *not asking* and instead suggest that it's better if everyone *tells* the answers to those questions proactively. It's already easy enough for teams to forget that they're not reporting to the Scrum master but to each other. I'm afraid focusing too much on asking, this small but significant difference will be forgotten.

Oh, and I recently got a domain for our Agile Finland seminars from DreamHost.com. They pack 8 gigs of diskspace and Ruby on Rails for $20 a month. Worth considering, I'd say. Oh, and if you'd like to support our new community site while signing up with Dreamhost, please consider signing up through the above link--that'll get me a referral bonus which comes off from the hosting costs. Oh, and don't forget to register for the seminar itself which takes place on September 7th in Helsinki, Finland!

You, my beloved reader, are hereby privileged to get a glimpse of what's not going to be in my book:

"Yes, it's cheating... and we love it!"

The book's going forward slow but still. It's surprisingly difficult to move beyond traditional storytelling or descriptive text.

I also recently got feedback from some early reviewers (excellent stuff!) so I'm now looking at how to adapt the first third of the book according to the numerous suggestions. A word of advice: If you're planning on writing a book, make sure you get early feedback -- it's just as vital in writing a book than it is in shipping quality software.

I just waded through the referrals logs of the past couple of days to see if anything interesting would come up. Sure enough, something did.

I have no idea why I got a referral from someone named Suzie's "friends" page, but at least I spotted a super cool animated gif while checking it out:

Ben Griffiths brought some quotes from Paul Graham to my attention. The following is by far the best of them, in my opinion of course:

"At this point, anyone proposing to run Windows on servers should be prepared to explain what they know about servers that Google, Yahoo, and Amazon don't."

This other quote gave me a very warm feeling inside:

"Google is a rare example of a big company in tune with the forces I've described. They've tried hard to make their offices less sterile than the usual cube farm."

The warm feeling is because I recently moved from a dominantly cube farmish environment into a much more friendly open environment. Highly recommended.

Talking about cube farms... Check this out for some serious co-location :)

The illusion of costs incurred by having to change something late is a very real part of every day life in the IT industry. We have been schooled to think that late change is bad and should be avoided at all cost. Yet, we can and do accommodate, embrace even, late change every day. The question is how to make the change less expensive.

Generally speaking, I would name two contributors to the cost of late change: excessive bureaucracy and bad quality.

We have traditionally tackled late change by introducing change control boards and change request management, which has increased the cost of making changes significantly. According to my experience with a number of "enterprise projects", we have not actually succeeded in managing change using these processes. We have prevented change from happening but at what cost? The process of pushing a change through the organization in place is generally slow and requires non-trivial effort. At the same time, we're decreasing our throughput—the very thing that defines our productivity.

Often, the need for the change in question is real. Why should we purposefully prevent that need from getting fulfilled? Wouldn't it make more sense to serve our customer's needs as effectively as we can?

Bad quality is another very real problem with many software projects today; just like it has been for as long as I've been in this industry. Preventing change is a good way to avoid getting rid of that problem among others.