Just Stop. Please.
I’ve tried to stay out of the whole “Spolsky Thing” of late as it seems like it’s spectacle for spectacle’s sake. That seems to be Spolsky’s thing and it’s one of those things you sort of ignore most of the time.
But he just keeps going – sort of like your parents revving your kids before bed while you watch, knowing there’s nothing you can do – he’s just going to do it anyway. It’s weird how that works – my family and my wife’s – they love to rev the kids up at bedtime for some reason and then I spend the next 2 hours trying to get them to go to sleep. It’s not fun, but to my dad, who’s upstairs reading a book (complaining about all the noise coming from downstairs) I just “worry too much – let them be kids!”
Sure. I’ll do that. And I’ll pay the price when they wake up tired the next morning and cry through breakfast while you remind me how discipline was handled when you were a boy.
Anyway - as I read through Joel’s latest train wreck, this clip of Jon Stewart on Crossfire popped right in my head…
Joel – it’s not funny any more. You’re hurting the industry, not helping. You’re acting like my dad did – revving up the industry and spewing old-time wisdom that does not apply anymore.
Here’s some tea – time for bed. Please stop.
At that point I decided Joel wasn't terribly relevent to me or my industry. Everything Joel says has to be viewed through a filter that a) only software that is for sale matters, b) only his view of how the development process works is correct.
The thing that saddened me in his latest post was once again he takes a swipe at unit testing, guess his code works the first time and he doesn't have to worry about changes mucking it up... sigh.
The gist of the post is to keep it simple and ship often. That's not new, and it's hard to disagree with that.
It's not just the keep it simple stuff. Take a look at this post on IoC containers: http://tinyurl.com/lame-post-on-IoC and scroll down until you see Spolsky's answer. It really is the coding equivalent of "Hey, you kids stay off my lawn". It celebrates ignorance and assumes that the best way to write code was perfected about 10 years ago.
I used to think Joel on Software was required reading, now I just think of it as a voice from the past.
He's done a ton of good for software development and developers over the years and though he's slowed down and makes some quick judgements at time he does continue to contribute.
Rob, I think it's very unfair to compare Joel to those douche bags (not sure you spell that) on Crossfire or the Bush administration. I think your just frustrated with some of his opinions and that he speaks into a megaphone. This post is more than a bit of a stretch.
I agree. Seemed like Joel spent the whole Duct Tape Programmer article except for the one small paragraph arguing for one of the tenants of XP... "Do the simplest thing that could possibly work."
I'm not going to try to tell you that you should agree with Spolsky. Far be it, in fact, because I happen to agree that some of his stuff is a little over the top. But I am firmly of the opinion that if we can't read his stuff and make intelligent decisions about whether any of it applies in our lives, then the primary problem lies with us.
Additionally, if you browse his writing over time, a great deal of it works because it's always been just a little bit inflammatory. It rubs a nerve or pokes at a stereotype, and it gets us to think about the issue and start talking about it. If the end result of Joel rubbing some salt on the wounds of our industry is that we educate a few more people about IOC or software development best practices, then I'm not sure it's all that bad.
Of course, each of us is more than welcome to simply stop listening. No audience == no problem, right?
Here's the issue - there are times when it's funny/interesting to go against the grain. There are times when you can say "hey - we're being crazy here!". To do so with rhetoric rather than a reasoned argument becomes flame-baiting, and that's what his posts are resolving to.
At this point Joel *isn't* helping - he's reprimanding. He's tilting at windmills and using COM in his examples. It's clear he doesn't write code anymore and that's cool - but stop telling people what they should pay attention to.
His *entire* duct-tape post was ridiculous. "Just Get'er Done" doesn't work - it might when you're doing things in your head, but when you need to actually do something - well you need to do better than duct tape.
So yes - people can and will make up there minds. But a lot will have their lack of desire to learn re-affirmed by a Guy Named Spolsky and they can appeal to authority for the mess they create.
You have some valid points - but it's not you who I'm worried about.
I hope the TTD advocates take their own advice as they get older and new methods and techniques displace TDD.
Seriously... His writing has required more and more filters to be relevant. At a certain point he becomes that friend you have who calls at odd hours to rant and you just nod your head cause, gosh he's your friend, but gosh is he out of touch.
That's where I agree with Rob that Joel is no longer doing us a service. Joel has more and more started sounding like the "get off my lawn" type and not offering decent critique.
You bet - crummy developers are everywhere, but I've got real doubts that they're going to turn into better developers just because one source of "ammo" dries up.
On top of that, I think the real problem isn't just those developers, it's our industry. It's a fact that we work in an industry where there's still a choice whether to use unit tests or not. The mere possibility that there can be a debate about this tells you a ton about the maturity of software development as a craft.
Go watch a home being built, and see if you find framers trying to argue that 18"-on-center studs are more than sufficient for this particular home, or electricians trying to decide whether or not to use conduit when they're running power out to the garage. These decisions are taken out of the hands of those people because building codes lay down the law on at least these aspects of how homes are built, leaving you to argue about really important stuff, like whether or not to run Ethernet to all the bathrooms.
We, as an industry, aren't to that point (and probably never will be, for reasons that follow). There exists no equivalent Software Building Code that says, "you will have unit tests" -- and here's the important part -- that has the support of all the businesses who are paying for the development, because without them on board, the cheap duct-tape guy starts to look pretty good with his no-way-that's-gonna-work quote.
But, we also don't have a "building code" because of the pace of innovation in software.
If we had a Software Building Code in place - say, five years ago, I bet it would have locked down how thou shalt build data access, and it sure wouldn't include something cutting-edge like Subsonic, and we'd be the worse for it. So, how do you get an entire industry of do-it-yourself developers to agree on how we're all going to develop when the landscape changes every two weeks? That's one of the key arguments that Software Development is never going to be standardized like Civil Engineering -- the domain just changes too quickly.
So just like that, you're back to needing smart guys to figure out which noise is real and which noise is just noise.
I think Joel should continue to post things like his 'duct-tape' post and all 'elite' programmers should have to read it. Seriously.
People who 'worry about the state of the industry' seem to me to be people who are hurting the state of the industry.
Agreed! Joel may well be successful but I want to feel pride in what I create.
If I was an accountant, that pride would stem from the bottom line; but I am a programmer and hence that pride is in the code I write.
Kindness,
Dan
I think the point of the article is that a) anyone who cares about what they do wants to do things the "right" way and b) doing it the right way gets in the way of shipping. Strive for the golden mean!
Oh yeah, lets not forget about the secret that the "right" way isn't defined and never will be because things change so much and once we figure out the right way someone is going to come along with something cooler, faster, easier. Damn you Ruby! Damn you Python! And of course, damn you C# . . . you are so much safer than C but C is the right way . . . it's the only way . . . and Joel said if I don't know C I am useless!
I'm not really worried about "the state of the industry". I find it incredibly sad when people shit all over something they know nothing about, using the old, tired astronaut stuff.
Like it or not - the future is calling and we need to advance.
Two words sum this up:
1) Blizzard
2) Vista
The soon to be available (assuming ms does the right thing and puts it in professional edition) design by contract features of .NET 4 are almost certainly going to have a significant impact.
Anecdotal evidence at best, I know. But it's just not black and white.
Much <3 for this post.
Shipping just isn't the gold standard of the PM Rob. It's the gold standard of the entire company, and as a developer it pays for my meals, house, and other things I'd like to have. It doesn't matter how well the code is crafted, if the project gets canned because it misses the scheduled release (and release dates are very important to software companies) or it doesn't sell because a competitor moved the product faster. Then all the unit tests and frameworks in the world aren't going to help.
Anyway why do you think Joel is hurting the industry? Because programmers will suddenly stop writing unit tests and frameworks like Subsonic? You're selling your customers and your fellow developers short if you think Joel has that much magical influence. All the hubbub strongly reminds me of the noise people make when you challenge something about their core belief system or threaten their bottom line.
Listen man, you're not John Stewart calling truth to power, and Joel and Zawinski aren't Tucker Carlson.
Well that's my two cents.
Listen, its his opinion that unit test don't give you much in return for the amount of time it takes to create and maintain them (and its a real cost...every hour you spend refactoring your unit tests is an hour your company / client is paying you).
My gripe with this post and I suspect with a lot of posts elsewhere crying foul over Joel's "trainwreck" is that its not like you or any other agile blogger can't respond back with a blog post of your own. Instead of breaking down Joel's arguments again using unit tests, or frameworks in specific scenarios where time is a factor and posting that in a reasonable blog post. Instead you take the lazy way out, find a three year old YouTube clip, and whine about how "mean old man Joel" is just being a bully that's hurting our "industry." (Which I still don't get, does that mean all of the software development shops have stopped writing unit tests...assuming they were in the first place...and are in danger of failing?)
I would have found a post like that to be far more interesting that the gratuitous back-patting "there there now agile boys and girls, things will be okay...look...John Stewart!" that this post turned out to be. Its a shame because I know you can do better.
That's the whole point. If that frankensteinian creation of duct tape and bailing wire had been put together with solid design principles in the first place, then it would've been more maintainable from the get go.
You can't always *fix* bad software with the 'right things', but you can almost always *prevent* it with them.
"Like it or not – the future is calling and we need to advance."
Yeah, that's scary. It's new, therefore it's good. Continuous change isn't necessarily continuous improvement. We really need an entire industry full of brittle tests. That will make things SO much better than they are now.
and you should return result codes in your methods.
They write "smackdown" blogs. It's us versus them. The good guys versus the bad. Black and white. No gray. Gray is boring. Nobody reads nuanced gray articles. It's all about the page view.
Joel knows that the real world is a lot more nuanced (his blog is featured blog at ACM Queue, after all), but he apparently doesn't care about nuances, because nuances bore people. Joel and Jeff can't just say "a good solution solved now is better than a perfect solution that's never implemented". Instead, they have to turn it into "Shipping is the thing that matters".
Joel and Jeff are the Jerry Springer and Maury Povich of tech blogging. They get page views by generating a reaction. Nuances are ignored, because nuances put people to sleep.
So they write and say absolute nonsense. Quantity over quality, says Jeff (I'd hate to be on a life machine in the hospital whose software was written by Jeff). Solid principles = waste of time. Shipping date is more important than testing (I sure hope that Boeing does a couple of rounds of testing the software in the new planes before putting them into the skies).
And what world does Joel live in where the biggest problem is overengineering? I'm sure there are, perhaps at MIT, people who look so long for the perfect architecture that they never actually create a real product, other than for themselves.
But the real world is mostly the opposite. I have seen time and time again, so many accidental architectures. Bad method names, bad class names, long methods, and rigid structures that require gigantic hacks, because the architecture no longer reflects the real business domain. And those piles of dung were created by duck tape coders.
But Joel didn't mention that. That would make the blog nuanced and he can't have that.
You don't have to do things that way, because you actually have good material to share with the community.
You're missing my point, entirely. Joel is making noise for noise sake - not help anyone. He wants eyes on blog, he's a sensationalist. A sideshow freak. I don't care normally, but it's getting to the point where the sideshow is causing distractions we just don't need.
He's a respected blogger who's imploding and loving it tossing out BS wisdom that will come back to bite me.
Joel is aggressively advocating ignorance and I'm not going to tolerate it. We need thoughtful discussion and discourse, not some guy giving license to duct-tape and laziness.
What I think is most telling about your post is the fact that you compare developers to your own rambunctious children. I suppose then it's not surprising that the tone of your post is essentially "Now do your unit tests boys and girls, and don't listen to anybody who tells you different because *I* know what's best for you!".
I agree that Joel is more of a story teller and knows the art of making noise . . . but that's the kind of guy you want on your side . . . not someone you want to shut up!
Sure, Vista was a flop but is that because the code sucked? Is that because MS didn't write enough unit tests? If they would have waited a few more years to "do it right" would it have been better? NO! It sucked because the UI got in the way of people doing their work. And the only way to learn that lesson was to SHIP!
Sheldon
But when it has already happened, then you often have to live with it. And here the hero shines, even though his kingdom is made of mud.
Yay for metaphores ;)
But Joel isn't talking about creating a successful company, he's talking about software development. You can have a successful company and have NO IDEA what the developers are doing, and not care as long as they are producing quality software.
He's talking from ignorance and outdated knowledge about how to produce quality software. My Biochem degree is over 14 years old now, should I tell researchers how they should be conducting research? Probably not because my knowledge is over 14 years old. I'm sure that the state of the art has moved on considerably.
Over Engineering is a massive problem in this industry, just massive. At least everywhere I've worked. People get way to smart for their own good, over promise and under deliver.
I think if you ignore Joel's rhetoric and actually dig down deep into what he's saying, I believe he's arguing against Over Engineering. While I don't agree with the "A shipped incomplete product is better than a non-shipped product" philosphy, but I do agree with the fact that a simple solution will likely be better than the "right" (re: complicated) solution.
Sometimes you just need to throw a value in a config file, but give a developer some leeway, and before you know it you've got a complicated rules engine on your hand.
In that respect, he has value (as a contrary view point), because you have to remember, in this niche he's actually in the minority. "Bad" developers (or 5:01 developers or whatever we're calling them these days) don't read his work.
Let's put it this way, if it wasn't Joel who wrote the Duct Tape blog, and we replaced the words "Duct Tape" with practically any other set of words, would anyone really have cared?
The problem is that Joel reinforces bad programming (note, I didn't say that Joel was actually a bad prgrammer himself. I suspect that he's not).
Case in point: I don't read Joel's blogs (don't want to contribute to his page view addiction), but it made its way to me, because a former employee sent it to some programmers where I work. I just happen to be the person who now maintains the spaghetti code that was written by said former employee who used quality method naming, such as GetArray() and GetFullArray on data that returned something specific. So said employee keeps on with life with the attitude that architecture is overrated and that gettin er done is what matters.
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
C was the only "sane choice for Git". With all due respect to his talant - Linus Torvalds doesn't want problems with abstractions and "idiotic 'object model' crap" :) Now we've got the situation : state of art LINQ/T4 Subsonic is kept in Git repository of duct tape programmers ( I doubt, unit tests do exist for Git ). Real life and the industry interconnections seem to be more complex than following the patterns and the best practices.
Also with Open Source widely spread now, how could you convince an individual or group of people to follow certain practice. They are not obliged to fix a problem in 24 hours and may not care about easy maintenance and unit testing. At the same time it might be quite useful application like Git. I remember one of the articles in this blog quite clearly states referencing Jeff Atwood - that if something doesn't work in Open Source, don't demand to fix it from the author, fix it yourself.
http://codezest.com/archive/2009/10/07/worst-development-blog-post-ever-ndash-by-joel-spolsky.aspx
In case anyone is wondering - this is the guy who's project you don't want to inherit. Read what you want to - you don't have a license to stop learning. My kids are awesome btw :).
I agree with the tone of most of Joel's stuff (question authority). But do it with intelligence, not a six pack and a shot gun.
Give me a break, what a line of BS just like Joel's. And I wouldn't want to work with you.
It's about finding the balance between Code & Run and Over engineering. It's about clean rusable code. It's about when your boss goes and asks you to create a new feature but you spend 2-3 days just trying to figure out what a 300 line method is doing and then try to get that working with 2-3 other 200 line methods and then realizing you can't reuse the code because most of the logic is not in methods and your 300 line method is actually costing now the business money.
It's not about "the right way", it's about caring about wtf you're building so that the rest of your team and the business are not putting out fires, refactoring the entire damn UI, because of Code & Run tactics making the excuse that "business wants it so I don't have to care about quality". And again, quality doesn't mean over engineer. It means having some sort of reasonable time to code it, so you can at least think about how this can be extended later and how the next guy on your team might kill you for building that 300 line pile of shit method.
Stop making analogies with terms like "perfect", "pretty", etc. with clean code. Over engineering is one thing but trying to and having decent time and a balance to focus on at least producing clean code while you code that important business feature is only common sense. Managers who think Code & Run is the way are amatures. They are not leaders and they are very unprofessional.
Is that the kind of profession we are in? If so, I feel very sorry for development and business overall. Shame.
It's not a competition. It's not about being "elite".
It's about building applications that don't fall on their face, don't cause other developers and the business days of refactoring costs, or days of even figuring out how to deal with the pile you're trying to build on top of.
you talk about business value, making money, and then talk about Code & Run being a solution? Why do you think American cars were losing to Japan and other foreign makers? Because they fing cared about what they build. They didn't duck tape their cars together.
I cannot believe people actually debate that what he is posting is good advice. I guess maybe those "elite" developers you label us as are the only ones with "common sense" because I can tell you creating clean code (no I'm not talking over engineer, I know wtf that is) is the only way to go. And Agile...coding your features in iterations that CAN be hit without code & run will produce ROI now, tomorrow, and 10 years form now. It will also build a HAPPY team who can go home and enjoy their lives without trying to spend a day figuring how how the f you're going to refactor or even use a 300 line method in another class that needs some of that logic.
I like to go home to enjoy the time I have left after work instead of dealing with chaos, hack code, and unorganized piles of Shiza.
With that kind of typical comment, I guess you haven't done unit testing I take it.
I'd like to know where this was. In my experience Code & Run costs you in the long run and dictates that you fix shit later. Is that how you view our profession? Run now, fix later?
Are you kidding? Of course they would care. The content tells use to Code & Run.
>>>Sometimes you just need to throw a value in a config file, but give a developer some leeway, and before you know it you’ve got a complicated rules engine on your hand.
What is complicated? That term is very relative. So do you feel making sure you're abstracting stuff out into a new class, interface, or method "complicated"? No, its not. It's clean code. And you should never view creating a class taking x amount of time as a way to determine if you're over engineering when it makes obvious sense not to take shortcuts all the time and do create that class for extensibility, readability, and maintainability now and later on so you don't have to come back and refactor some pile of shit.
Complicated would be forcing your team to use IoC container, code contracts, stuff like that. Stuff that's very hard to do for the avg developer. But clean code, and logical abstractions are not complication...their smart development and ensures that the product you build is not going to waste your developers time or the business's time. In fact if the code makes sense and is clean, your team can bang out code even faster!
That's a blanket statement. You're saying every developer who takes just a bit more time (I'm not saying spend too much time) but a bit more time instead of hurrying up to always be frantic to "get it out the door" is going to end up over engineering and creating a huge rules engine? So do you view abstractions as over engineering when you're just coding basic BL, DL, and stuff that is pretty much common in most good development shops? So if I think that an Interface would work really well, but the excuse is "we don't have time for this" because an Interface would be over engineering are you really sure about that? Maybe if you did move that to an interface or maybe if you did separate it out into another class, or whatever the case may be that you're actually not over engineering and saving your development team a lot of pain as well as yourself now and later on and maybe later you can spend your time actually hammering out code because your base is clean and you actually put some thought behind a feature rather than "banging it out" just to make yourself proud that you were able to push that feature out in 2 hours?
That's a totally ameture way of doing things...very careless, and just promotes chaos.
and you should return result codes in your methods.
Wow, Unreal. It just gets better and better. Lets listen to such sound advice as we hack together our applications. Everyone, Joel's driving the bus. Run for your lives.
The problem is that not everyone is smart enough to do that. Managers or even developers who don't have enough experience yet or just have never worked anywhere else don't know any better and read it as the bible or some kind of "Real World" type of advice or think it's good advice overall. I know of one manager that does and the entire shop is complete chaos and we have code that is just a huge nightmare/pile which is why everyone on the team just bitches day in and day out. It's hell and we work our asses off to fix the pile..same old story. Methods are way, way too long. Class names make no sense so reading code takes days to filter through.
So you can't just say ignore him and be smarter than his post. Sure good developers who have been in environments that are not Code & Run can do that. It's the people who don't really know what reality is or should be because that's all they've ever known are the ones we have to worry about because a lot of these leads or managers do read his blog and believe every word he says. Then we may have to work for these types of idiots some day. So no, I don't feel it's just something to ignore or "brush off".
Patrick, why do you like every other hacker out there blame things on Agile or unit testing? And have you actually written unit tests? Anyone who has pretty much 99% of the time agrees that it's essential and benefits the team and the business in so many ways you can't possibly argue it...again IF you've done it.
It's those people that don't know jack shit about unit testing that say the kind of remarks you are stating. Very generalized, very naive and I bet you know nothing about unit testing other than "I hear you have to write more code, and that means money". That's so close minded and so inexperienced that I can't even fathom why people like you state stuff that you have no idea or experience doing let along saying unit testing is BS.
Besides the point.
Lots of software projects fail and personal experiences, though valuable, fuel the vehemence with which points of contention are debated; this project failed because it turned into a tarball; this project failed because the designers were too inflexible and unrealistic in their demands. In this sort of forum people almost feel pressure to align to a side even when the divide is not so black or white nor so wide.
The pragmatist might argue that taking the middle ground is what they are doing, whereas the believer of a particular practice(s) might claim the middle ground or correct approach because the benefits are so vast and apparent.
My personal take would be for everyone to keep saying what you are saying but perhaps spend 5 minutes to work out where you do agree and then say where your views intersect and benefits could be arise. Once you start preaching to your own choir or deriding the other side (and hey you’ve done with proper discussion now because you’ve done that all before and they just won’t listen!) you’ll find that the real moderates (floating voters) give up reading (or voting) and just gets on with things their own way regardless of what you might hope for them.
Cheggit: " What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer."
You can read more at: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx
I think, at the core, this comes down to a difference between an entrepreneurial programmer and a programmer. It's all right to improve your methodologies, to improve the world with better software, to change the way the community writes and learns about software for the better -- but you have to make money first.
See, you are falling into the "You're either with us, or with the Terrorists" type mentality. I never said "Run now, Fix later", I just said that over-engineering is a problem in our profession.
This is also a huge problem with the ALT.NET-ish sub-section of our profession. The idea that if you don't 100% agree with what they consider "right", that you are somehow advocating hacking together untested crap.
"Why should I have to “read into” a blog and ignore the inflammatory rhetoric?"
First of all, it wasn't all that infammatory, stop being so sensitive. Since it was an article by Joel, you probably went into it with a bias and you found exactly what you were looking for. For someone like me who doesn't give two sh!ts who Joel or Jeff Atwood is, the article wasn't that bad. I said I didn't agree with his main point, what else do you want? Do you want me to stamp my feet and scream that this guy Joel who I've never met is evil? Hardly, the guy writes a blog that I sometimes read.
Secondly, as a thinking human being, you have to "read into" everything you read, hear or see, otherwise how would you ever form your own opinions?
Even at the risk of over repeating myself, over-engineering is a real problem in this industry, to me that is what the article was about. Again, get it out of your head that by saying that I'm advocating writing untested crap, because the two are mutually exclusive.
I didn't say one thing that you apparently seem to think I said. How is it that you even remotely jumped to that conclusion is beyond me?
For example:
"That’s a blanket statement. You’re saying every developer who takes just a bit more time (I’m not saying spend too much time) but a bit more time instead of hurrying up to always be frantic to “get it out the door” is going to end up over engineering and creating a huge rules engine?"
I am not saying that, and I never did. I fully expect all my developers to adhere to the SOLID principles, DRY and YAGNI. I also require Unit Tests everything, although more in the TAD manner than TDD (for a variety of reasons not worth discussing here).
When I say "over engineering" I mean overly complicated solutions to a what is probably is a simple problem. For example, my config file v. Rules Engine problem is something that has come up in the past. We had a setting that need to be set in a windows service, and quite honestly it'll rarely (if ever) be changed. Adding a setting to the App.Config was a simple solution that would have worked just fine. Instead, a developer convinced his manager that we needed more and went off and built an entire rules/setting engine and an application to run it...he also decided that it needed custom encryption so nobody could ever know what the settings are...before you know it, six months went by and we had a new app and five new DLLs needed for every project, all for one freak'n setting that really wasn't all that important anyways. That is what I mean by over engineering and I see it all the time.
I saw much validity to his post, but then again I am just a lowly corporate development manager and not a figure head of the industry as some of you are. I knew exactly what he was talking about when he said that some times you just don't have time for unit tests. It is true, when the vp/pres of the company comes to you and says I need X yesterday well you hack something together for them to use and hope that you can come back to it later to refactor it. Some times the corporate world could care less that it is a little buggy as long as the primary functionality is served. Bugs can always be fixed later but that TPS report that they have lived perfectly happy without until today will absolutely make or break the company.
I may be out of place in saying this, but I believe there may be a disconnect between the developers who are writing commercial software products and the developers who are writing proprietary software custom to business practices. When you are writing a product that will be generic in terms that many varying businesses/consumers can use it you have the time, and if you don't you should make the time, to unit test everything, refactor where you can refactor, develop very clean and maintainable code, etc. When you are responding to immediate internal customer needs because some department just signed up with vendor xyz and they need some new functionality that will fulfill a requirement for said vendor, well you don't always have time for these niceties. It is all fine and dandy to say what you should do in theory, but practice is often quite different and sometimes adverse to theory.
Then again, as I said, we all read things and apply them relatively to our perspective. So in my perspective of being a SMB development manager I realize the time constraints that can be imposed by the executives of a company that don't understand the level of work that goes into development. It is my job to balance the amount of time and effort required to deliver and the determine the level of expectations of business unit. If they are rushing a project but they are acceptable to the idea that it could be buggy, then I work with my developers and I begin whipping out my duct tape. If they are rushing a project and it has to be bug free (or as bug free as possible) then I have to work with the business unit and explain to them their expectations are unrealistic and this is what I can deliver in x time and I can meet or exceed their expectations in y time, then give them the choice.
It in no way means he's right about what he's saying, but dismissing him as someone who doesn't know anything about the business he's in is a bit on the ignorant side.
I think the reality is that we should be somewhere between the two extremes. Software is a young industry compared to the other engineering fields and it seems to me that the pendulum is still swinging.
The company writes the paychecks so I hope we want the company to succeed.
I will agree with the sentiment that talented programmers can become distracted with fascinating side-problems, but the solution is not to dumb down your development staff. The smart ones can produce valuable software if you are able to engage them and focus them on the demands of the project. Don't expect developers to manage themselves - mastering one wickedly difficult profession is enough for one person.
Quality == Success.