Scott Hanselman

Interesting discussion, though I was frustrated listening, because you both kept missing the fundamental issue: developing software is an engineering discipline (or at least should be) made up by people who aren't engineers. This isn't a surprise: it's only been in the last 10 years that colleges and universities have begun having "software engineering" degrees and that means that only a small fraction of practitioners graduating with engineering degrees. Some, like Uncle Bob, approach their craft as engineers do, however, engineers are given this disciplined approach for 5 years in college whereas programmers have to hope that they have a good manager and a good group of teammates that will mentor them.

Attend a thousand or even a million lectures in engineering courses and you'll never hear an instructor say "quality doesn't matter".

Here's an article and a wiki about the differences between science, art, and engineering as well as reasons why software belongs as an engineering discipline, not as a "science". Google will also turn up a number of articles i
http://www.stevemcconnell.com/psd/04-senotcs.htm
http://en.wikipedia.org/wiki/Software_engineering

Here's where training doctors and lawyers is different from training programmers. Medical schools hire doctors to teach doctors. Law schools hire lawyers to teach lawyers. But universities do not hire programmers to train programmers, they hire computer scientists. Some computer scientists are good programmers, some are not. In general a computer scientist advances his or her career by publishing theoretical papers, not by developing large software applications that have customers, budgets, and schedules.

Some schools will hire experienced programmers, such as yourself or Bob Martin, to teach classes, but this is the exception. In fact, I would imagine that the more prestigious the school, the less likely they are to hire experienced programmers and the more likely they are to hire people with grants and publications.

Even the great Donald Knuth said he was surprised how hard it was to write a large software application when he worked on TeX. He said it took far more concentration than he'd expected and that he had to reduce his teaching in order to finish writing TeX. He was a great programmer and a successful academic, but he didn't fully appreciate the challenges of working on a large system until he did it.

I think what Joel might have meant by "quality doesn't matter" is that customers may tolerate a low level of quality if they can get the software sooner. Or getting a product to market sooner than a competitor, though with lower quality can make short term business sense. Look at the stability problems some very successful products have had in recent memory. In Microsoft Excel (95 - 2003), if you just keep copying and pasting a document back in to itself (doubling its size every time), eventually the program locks up. It doesn't give some friendly error message, it just locks up. Seems like a pretty major software quality issue, and yet every version of Excel from 95 to 2003 had it. Still many copies of Excel sold.

Personally, I wish Microsoft would have fixed that bug, and many others before shipping, but the decision to ship the product with that level of quality appears to have been a good one for Microsoft.

Correction to above: I guess it was Jeff who said that and Joel agreed.

The whole apprenticeship, journeyman, master-craftsman process is utterly absurd in the world of programming because the technology changes too fast. Y'all compared programming to being an electrician or carpenter; tell me: how many electricians or carpenters have to learn their craft FROM SCRATCH every ten years? Becoming a master-craftsman, qualified to train apprentices, takes time. Are the DNA master-craftsmen finding many students for their field of expertise these days? When Ruby on Rails has been around long enough to have had programmers become "master craftsmen" of that technology, will Rails even matter anymore?

Sure, there are some core principles of programming that apply regardless of the languages in which they are used, but you max out that space of knowledge very fast and you quickly hit the realm where theory cannot be applied to reality anymore (again: do client-server or DNA principles have any place in modern programming? Will my SOA knowledge even be marketable in another 14 months?).

While I don't agree that quality doesn't matter, I agree with a core principle of what Jeff Atwood said: quality is meaningless if your app isn't used. It's more important to make a popular app, something that's useful and relevant that you can go back and refactor correctly in the future if there is demand for it (WordPress was the example cited of crap-code that is hugely popular and should be re-written correctly at some point).

Or to paraphrase General Patton: an ugly solution that works when you need it is vastly superior to the perfect solution that won't be ready before it's irrelevant. In the world of programming this truth is proven linguistically with PHP and application-wise with tools like WordPress or Twitter (crap code, but who cares -- it serves a popular need). Getting mired down in the principles of code gets in the way of getting things done by coding. Only if you have the luxury of success, and the time and budget that comes with it, should you attempt to follow every rule in the book for writing applications correctly.

On the topic of crap code that became hugely popular and profitable allowing the time and budget to go back and do it right later, I have one word for you to consider: Windows.

Interesting points. I personally have a "Software Engineering" degree, and when I got it, I was teased by my "Computer Science" peers. ;)

Scott mentioned he would link to Derick Baily's SOLID Development Principles motivational posters on LosTechies.com. I couldn't find the link here. Please let me know if I missed it.

Here are the posters:

In my previous comment if you click on the design it will take to the posters.
http://www.lostechies.com/blogs/derickbailey/archive/2009/02/11/solid-development-principles-in-motivational-pictures.aspx

Scott, I'm new to your blog (seems cool so far) and found that this podcast brought back memories for me. For the record, I used to skip most of my software engineering courses, but still slap together an ADA program at the end of the course (okay so how many people remember ADA)? This was a good discussion and you guys both hit some good points.

First I would like to say that I think that software quality matters. The degree to which it is important is variable however. For example, a website that services millions of users every day like Facebook.com better have a high degree of software quality, otherwise it will crash or be very difficult to maintain. On the flipside, for an intranet website that perhaps a few employees in a particular department use, maybe the quality of the software isn't one of the top priorities of the dev team. In the latter example, it may not be worth making the quality of the software as one of the most important characteristics of it; perhaps the features are more important so more time is spent focusing on that aspect.

Regarding Joel's comments that "...excessive TDD cuts time from other activities that could benefit the software product...", I do agree that having a great software product that nobody cares about is missing the point and counterproductive; I think most people will agree with that. You don't need to sacrifice quality in order to sell a product, but time is definitely a factor and taking too MUCH time to develop the perfect product means you may be too late.

Regarding the addition of quality post-production, I personally think that quality has to be built in from the beginning, the longer you wait to add "quality", the more difficult it will be and the less impact your actions will have towards actually achieving a higher quality level. Typically adding quality later means rewriting the code and that is expensive.

Finally about young developers, mentorship and universities I agree with what you and Uncle Bob said, that it takes time for a developer to mature. Even fantastic coders need time to blossom and get exposed to different scenarios. I would emphasize that variety is equally as important as time spent developing. A developer that has only been exposed to the same environment for many years, may still be lacking the maturity to write more robust code because of the lack of experience in heterogeneous scenarios.

One way that I think colleges could improve the state of the development profession is to partner with local companies and require that students who intend to program professionally, undergo internships. This way, they can be sure that their students have a taste of what it's like to really code at the workplace and they won't be blindsided once they graduate. It's better for companies too, because they will get more qualified entry level programmers after graduation.

Great show! I'm glad you had Uncle Bob back on the show. He brought up some great points. Here is what I took away from this "entire thing".

-SOLID principles are all about decoupling your code.
-Decoupling your code helps you write good unit tests.
-Unit tests and (if you're up to it, TDD) are great ways to have quality software.

All this has me thinking a lot about the quality of my code. (ie. testability, how decoupled it is etc) I'm not trying to adopt the SOLID principles as a commandment, but more as a guideline, which I am more than glad to follow.

This has been very enlightening and has pretty much changed the way I picture what good code should be.

I personally think that Jeff and Joel would do well to show a bit more respect to other EXPERT skilled developers who are willing to give up valuable time to share their experiences and knowledge on development. If Uncle Bob's ideas are not for you then thats just great, but there is no need to have a very public go at him.

"Attend a thousand or even a million lectures in engineering courses and you'll never hear an instructor say "quality doesn't matter"."

Not in so many words, but what you will hear is, "Engineering is the art of doing with one dollar what any damn fool can do with two." Engineering is not about the pursuit of quality for it's own sake, it's about producing a product hat meeds the specs as efficiently as possible. The watchword in engineering is efficiency, not quality.

The other thing that struck me Bob and Scott talk about quite a bit of experience and experienced developers. Experienced does not always mean better. In fact, "'Experienced' often refers to someone who's gotten away with making the same mistakes over and over again for longer than you have."

Greate discussions, thanks for having Uncle Bob back.

My comments on the whole thing are here:

http://geekswithblogs.net/btudor/archive/2009/02/21/129583.aspx

Keep up the great work, Scott.

Did I miss the link to the motivational posters?

Too many words, philosophy and what ifs...Software development should be compared to artists not doctors, electricians. Doctors have very well defined procedures and you train years with them. Software guys don't have this and our world is never the same.

Matt - Here's the posters: SOLID Motivational Posters

Hi Scott,

In the podcast you mentioned pain in your hands (I seem to remember that you have brought it up in a previous podcast as well).

I have had RSI problems with my arms, and I just thought I'd point you to my description of my problems, and how it was resolved (at least not getting any worse).

I wrote it up on Stackoverflow, here: http://stackoverflow.com/questions/1915/how-do-i-know-if-have-rsi-or-carpal-tunnel/57676#57676

Hope you can manage to sovle the problem, and that you can keep programming as much as you want.

Best regards,
Henrik Warne

I believe it is important to have 100% test coverage on the 20% of your app that is used 80% of the time. Not as important to do so on the remaining 80%. In other words focus the higher quality push on the core of the app, and use a good balance on the remaining 80%. This means that with 30% extra effort you get an 80% higher quality app.

I rather deliver half a product than a half as* product. So cut features to get there early not quality. Most of the time you can cut 30%+ of fluff in each app which will provide the time you need for that higher quality push.

I've been using this method successfully for several "REAL WORLD" projects. I've built two production apps running on ASP.NET MVC since Preview 3 using this method. I've been able to refactor these (one of the major benefits of test coverage) with each preview release with minimal effort. The bug count on these apps has been roughly the same as that of other apps I've written using the 100% code coverage mentality on more stable framework.

**WARNING** This opinion is based on REAL WORLD personal experience, not academic theory! :)

Drs are REQUIRED to update their skills on a regular basis or face losing their license to practice medicine.

@Scott, I think a valuable read relative to this topic is Malcolm Gladwell's book "Outliers". Bob makes that comment that "it takes 5 years for a developer to really become experienced", which is a statement backed up by the research in this book (10,000 hour rule). A lot of this podcast felt like "dancing" around the subjects discussed in the book.

The core of your podcast is dancing around the question of "What is good enough?"

The definitions of enough vary quite dramatically from project to project and person to person.

In particular the definitions will vary by the size of the project / company. And this is where Joel and Bob really work at odds. They are coming from two completely different realms project / company. Let's say there are 4 classifications:
1. Small / Micro / Start-up
2. Medium, established niche
3. Large, thousands of users, typically a legacy base
4. Web-scale, millions of users (Google, MS)

Now Joel clearly comes from world #1. Bob is from world #3 or 4. Scott, you're from world #3 (& now #4).

For most developers in world #1 or 2, Bob's SOLID principles are at best guiding lights for solving the "next big bottleneck". (But there's a lot to be said about first having bottlenecks worth solving) There is simply not enough value generated by writing interfaces for the large mass of internal layers that are never exposed. Lots of objects simply don't need a "single responsibility", because the cost to change is very low. In my simple DB app, I don't extend more than 1% of my classes, so why do I worry about the OCP? In "Fog Creek" world, there's a lot of leeway in the term "Quality".

The cumulative sum of generating unit test for vast swaths of Maintenance screens simply doesn't justify the time spent on this screens. In fact, most people in world #1 & #2 seek out tools (like CSLA) quite specifically to generate Maintenance screens b/c they just don't justify any custom functionality.

Let's flip this into a practical application. (with no offense to Jeff here)

I can tell you right now that StackOverflow will not scale to 100x as it is currently architected. If the number of StackOverflow users grows by 100x the entire architecture will need to change. No, I've never seen the codebase, I've just listened to the podcasts (Hanselminutes and their own) but just listening to the problems it's obvious that things would need to change.

For 100x, they would need multiple databases. They would needs specialized services to push data back and forth. Your rep score would be updated every 60 minutes by a service (not in real time), there would be a server responsible for updating RSS feeds. Data about updates would be pushed to the DB and replicated to bulk insert files on the RSS server to manage the reads against the primary.

As I said above the SOLID principles would be a guiding light in solving these problems. They would need to break out interfaces for "high-communication" features and build standard interfaces for communication (Web Services, Bulk Insert files, etc.). They would need to reduce connectivity dependence, LINQ-to-SQL would suffer as tables became stored on different DBs. They would need IOC model for managing connections at a table level so that they could point connections at the right spots.

Of course, in the process of growing by 100x, they move from world #1 all of the into #3. And the nature of these SOLID principles is that they become more valuable as the scope of the project grows and the available resources to build that project also grow.

I work for an ad network, so I live in world #2 & #4. In one world we serve 100s of millions of impressions in a day. In another world, we operate a user interface with 100s of users. The definition of "Quality" varies dramatically between these worlds. In one world, we can build drag & drop UIs with MS AJAX and average response times. In another world we write these massively scalable and distributed apps with lots of interfaces and IOC and robust, error-resistant code.

When Joel talks about Bob having "never written much code", he's talking about Bob not having written very much of the type of code that Fog Creek writes. When Bob lays out the framework for a new project he simply has too many tools that do not provide value in Joel's world. When Joel lays out the framework for a new project he ignore many of the tools in Bob's framework because he's never really needed them before.

And that's OK... I mean look at StackOverflow, it already has every dev on its mailing list :). It doesn't actually have to grow 100x to cover its potential market.

I find it interesting when self taught programmers say that they are surprised that current computer science don't know many cs principles like TDD when these programmers taught themselves TDD. Same for other principles. I hope they are faulting the school curriculum, which doesn't change quickly enough, and not the students.

Abdu - Isn't everyone who is "first" at something (science, etc) "self-taught" until it becomes a best practices and then standard part of the curriculum?

GatesVP - *Excellent* comment. That's a blog post on its own!

As was stated in the first Uncle Bob podcast, musicians usually make the best programmers. Many of the best musicians are not trained at Julliard or somewhere else. Who was Hendrix's mentor? Who was Van Halen's mentor? Who was SRV's mentor? Many of the best musicians have a sense of accomplishment from being self-taught.

Musicians are artistic and yet apply structure in the form of harmony, rhythm, scales, etc. Good programmers are like musicians.

There is great beauty in classical music. I love Bach, Mozart, Beethoven and many others. Classically trained musicians bring that music to life. Yet I would be afraid to hear most classically trained musicians improvise over a jazz chord progression. There is a place for highly-trained programmers but that is not the only effective approach to programming.

Perhaps programmers resemble musicians more than they resemble doctors, lawyers, and architects. The craft should be approached in a similar manner. What are you listening to on your iPod this week?

PS. I love your podcast and blog. Thank you for all you do for the developer community.