The Joel on Software Discussion Group

I don't know if they wanted to imitate the style of jwz's style - could be as he's quite renowned for having 'made better software' - but still, c'mon people...

That said, the topics chosen seem very interesting, I'll certainly try to convince my employer to organize a little video-afternoon with the entire dev team here :-)

is there some context for what you're talking about?

I guess you're referring to this?

http://training.fogcreek.com/

Wow, that looks very cool.

Wow... $2000 for a set of 6 DVDs. I imagine not too many employees will be buying this for their bosses like happens with PeopleWare. But it's probably worth it for a company that really wants to tune up their process.

Uhm. How do you train people to make "better" software? Better than what? Beyond the obvious points and smart, hard-working people what could we get from this? I've read JoS for years and love the observations and insight into what I think is a different (as in better) kind of software company, but I don't see any sort of prescriptive recipe that would help me build better software. Is this some sort of SW Developer targeted infomercial-type pitch?

Maybe my questions and the fact that I just don't get it indicates I should immediately purchase...

Joel has a lot of good advise about both software design and running a software business. You can buy the books for $100 or so, read the articles in the books here for free, or if both seem like too much trouble, watch it on 6 DVDs and go through some workbooks and quizzes, in a form that corporate trainers like. He is just making available a variety of ways to get the same information.

The annoying part is that each time you show the videos to a new employee, the license requires you pay FogCreek $59.

I think its great more IT shops are realizing whats really important.

A. Making "better" software, no matter how you define that. That translates into lots of money made and saved over time.

B. Respecting the creative process and what smart experienced IT can do when managers get out of their way.

There is one thing left out of that equation though.

C. Hire local programmers and engineers (problems with ofshoring IT innovation)

Until thats seen and felt and understood, we are still stuck in all our "better" software models and expectations. You cant commoditive high level work and expect some idea dreamed up on a gold cour4se by a CEO is all you need to make lots of money in software. Until thats also shown and discussed and measured and evaluated, Im not buying it.

"Maybe my questions and the fact that I just don't get it indicates I should immediately purchase... "

Mark,

I apologize in advance if the following takes your comment out of context.

My observations over several decades are that people who buy a software package because they just don't get it are buying a package for the wrong reasons.  They often expect the package to teach them how to do the job.

Well, the 6 DVDs are a teaching tool, so maybe this objection doesn't apply.  But if nobody at a company "gets it" about the point Joel is trying to make,  then that company's culture is probably not ready for the wisdom that the DVDs impart. 

A company where everybody "gets it" doesn't need the DVDs either, unless it's to teach new employees.  (Maybe that's the reason for the $59 license fee). 

It's a company where a few key people "get it", but they don't know how to spread it to the other employees where the DVDs might be worth every penny Joel is charging for them.

This response, of course, assumes that the wisdom in the DVDs is worth getting.  I'm making that assumption, but I really don't know.

<<<<<<<

I've read JoS for years and love the observations and insight into what I think is a different (as in better) kind of software company, but I don't see any sort of prescriptive recipe that would help me build better software.

>>>>>>>

One thing I've learned from Joel (although he did not invent it) was the "eating your own dog food principle.". I took me some time to understand how to implement it correctly for http://fc-solve.berlios.de/ . At version 1.0.0 of it (first version was 0.2.0) I converted the code to be compilable as a library capable of instantiation and provided a simple API. However, the command line programs I provided still used the more internal APIs which were subject to change.

At one point , a KDE developer integrated it into KDE Patience (or kpat  for short) and used the internal API because the external API did not provide everything he needed. This made me unhappy, but eventually I realised that I should eat my own dog food and use the external API in the sample command line programs. I did that and it required adding many extra API functions.

So it helped me write better software, though the dogfooding realisation took some time to sink in.

Another thing that Joel made me realise was that I should not spend too much energy complaining about how inelegant a piece of code is, and instead either keep my judgment  (which may be false) to myself or alternatively improve the code by writing automated tests, fixing bugs refactoring and bug fixing. (In that rough order).

"Maybe my questions and the fact that I just don't get it indicates I should immediately purchase..."

LOL!  I'd think we're going to see that angle worked into one of those get-rich-quick tape infomercials at some point if we haven't already.

From the web page: "For ten years, Joel Spolsky has been teaching millions of programmers how to make better software."

How much up his own arse is he? Millions? If there are millions of software developers in the world, I very much doubt they have all been taught something by Joel. Visiting his web site, or browsing this group, doesn't constitute learning.

I could just as well say that millions of people have been taught to use Version Control by me over the past 10 years.

Flim flam

SM: I think you are quite right :-)

Business must be bad