Fog Creek Software
Discussion Board




Don't worry, be happy

Hmm, it's not April 1, yet Joel's advice currently at the top of the page sounds like a joke to me.

If someone hands you a spec and you don't understand it, you should just not worry?  So what's the point of the long, involved spec writing that a certain author ( http://www.joelonsoftware.com/articles/fog0000000036.html ) likes to promote?

I know, I know, if the spec is too complicated, people won't use it.  Bosh.  What they'll do is misinterpret it, implement it halfway or broken, and claim compliance.  But that's an argument for plain language in specs, not an argument for why you should do half a job of implementing something.  Half the reason Windows sucks so much is because nobody follows the spec (not even MS) so you never know whether a given program will work on your machine.

Acowymous Nonerd
Wednesday, April 03, 2002

I think he is referring to industry standard specs - like XML and XSLT - rather than program specs.

Ged Byrne
Wednesday, April 03, 2002

I know he's referring to industry specs.  Why the author of the spec is a concern is beyond me, though.  If you can't change the spec, clearly you can't fix it.  But that just tells me that you should not claim you're implementing a spec.  You're implementing a subset of it.

The reason this is important is that Joel's advice is, as nearly as I can tell from all the half-compliant software I have, already something programmers do as a habit.  Telling people it's ok is a good way to make interopeability an even greater challenge than it already is.

Acowymous Nonerd
Wednesday, April 03, 2002

Exactly, since everybody only implements a subset of the spec then if you bust a gut complying to an overcomplicated spec, you are wasting your time.

If you see that a spec is too complicated, then its best to leave it because others just won't comply to it.  A standard is of no use if only a minority are actually sticking to it.  In fact, you make yourself non-standard.

Look at XSL.  XSLT is quite complicated, but with a bit of work you can get your head round it.  XSLT has become quite popular.

How many people are using XSL Formatting objects?  Its just to complicated to use and hasn't caught on.  For most people XSL is XSLT, FO is almost forgotten.

So, if you've spent a week making your new system using XSL:FO when you could have done it in a day using Crystal Reports then you've fallen foul of the architecture astronauts http://www.joelonsoftware.com/articles/fog0000000018.html .

Ged Byrne
Wednesday, April 03, 2002

The problem with w3c/rfc type specs is that the spec writers have to be very concise about what they are defining. Ambiguities in a definition can cause problems in vendor implementation. Of course, a hard to read spec can also cause problems in vendor implementation. But spec writers for technology have to focus on being "correct" first, and focusing on being "readable" later, because it's harder to go back and make things "more correct" than to make a hard to read spec "more readable". In fact, w3c recognizes that and have started introducing primers (spec part 0's), which are more human readable and readily used. For the hard to read stuff, you'll often find that they are labeled 'normative forms' or 'concise forms'.

That's just a fact of life. Imagine if the POSIX or HTML spec were "more readable" and "less correct", then we'd have even more problems with compatibility. Because these specs serve as a translation language between different vendor implementations.

Better a vendor correctly implement a subset of a spec than incorrectly implement portions. Because at least we won't have to code workarounds. Unreadable? Perhaps. But for the person trying to implement the entire set described by a certain spec, that spec better be correct and not have ambiguities.

Of course, for consumers of a technology, we need lots and lots of example usages. This is the part that is often severely lacking in most "formal specifications". Samples usage patterns are what programmers learn from, not linguistic grammars and functional descriptions.

James Wann
Thursday, April 04, 2002

Whew, Just read the Astronaut Rant.

If you are writing an application as a single person do it however you can do it most easily.

Anything more than that, and you need coding standards.  Two people can do this informatlly.  Three less so (Ugn, a meeting!)

Architecture is just that:  Standards.  Having lived through many iterations of MS standards (and in 5 shorty years of doing this full time)  I can understand the frustration.

But doing something to a standrads VS doing it to a roll your own implementation Has its benefits.

And a lot of people that are those just get it done types produce write only code.

Somebody here shoult out the % of time that code spends in Maintenance.  Think Architecture helps there?

One thig Sun does with Java, and Does well, is produce an architecture for people to work in.  JDBC Is usable to any DB programmer.  It is just a spec.  But there are no hidden  Gee Whiz things there, becasue the code I write to go to Oracle looks a hell of a lot like the code I write to go to PostgreSQL/ MySQL and MS SQL Server. 

Don't talk to me about ADO. That is a tool from MS, not a spec.  OLE DB is a spec, but it ain't usable by Joe Average DB programmer. 

I agress with Joel's view of refactoring.  I also agress with the spearation of concerns that is a baseline programming virtue.  So to Do most DB programming, I probably am goping to use CMP Enitity Beans as my programmic INterface.  Why?  Becasue I don't want to write another Object/Entity Mapping tool.  It's been done for me, and It's called JBoss.

OK, I feel better now.

Adam
Friday, April 05, 2002

Well, actually TBL didn't dumb down SGML, he was solving a different problem. 

One of his collegues saw what he was doing and said something like "hey, this kinda looks like something I'm doing with SGML" and tada, a dtd was sorta whacked in at the end.

To understand the lack of adoption of SGML, just look at who it appealed to:
* Defence
* Legal publishers
* Govt agencies

All of which are particularly bad at saying stuff like "look what I've done" and "why don't you take this and try it"
hence, not much takeup.

Goldfarb inspired the spec by solving the information mgt problem of legal info, hence it's market placing.

XML dummed down SGML.  With all it's fan-fare it was initially underwritten as a ramp up from HTML (an application) to SGML, by then an enabling technology.  A ramp up which solved (as Joel points out) the complexity problem.  I've often heard the initial XML recomendation being described as "the SGML that everyone was using anyway".

Following a thread from the UI arguments, make it easier to understand & more people will use it.  Which they did & would ya just look at all the XML based apps that are out & about today.

So, now looking back, the technology didn't really change that much, the understanding of what you could do with it did.

the moral of this story: It's all about perception. 
If somethings percieved to be useful, then it will probably be useful.

Ray
Monday, April 08, 2002

*  Recent Topics

*  Fog Creek Home