One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike,
always wear white.
As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
Wednesday, May 01, 2002
Too many people think real coding is like html coding, but it isn't. Change a line of html 4 and the worst you've done, more likely than not, is mess up the display of one page. Change a line of Java or Visual Basic (yeah, yeah, "if you can call that real coding" har har har) and you may have trashed the whole application. You can't nickel and dime real programming like you can html; you can't endlessly tease the application to see if you prefer that button at the top left instead of the bottom right. That's a large part of why I think it's important to differentiate between coders who script and scripters who try to code; they're just different animals.
By the same token, I'm happy to see that Mozilla is shooting for a version 1.0. There's nothing like having a nearly robust application with enough major bugs out of the way that you know where the next great feature lies. Tying up loose ends is a pain, and when you're close to and familiar with the development of the program loose ends are easy to ignore. Eventually, though, if you want an application someone other than the programmers and familiar users can enjoy, you need to stop changing the application and start cleaning up the bugs that are there.
There are two types of application -- those that have great features that are nearly implemented but-not-quite-ready-for-grandma-to-use and those that aren't quite bleeding edge but work.The biggest problem is that app "designers", especially those with an html design background, have no idea why things have to be this way, and why there's a sizable investment required (and a corresponding sizable delay between "nearly implemented" and "an app ready to ship") to bug test and QA these apps every time the code is touched. In their minds, this delay is time better spent on developing their latest great, last-minute idea -- and then they're struck dumb with disbelief (oh if only "struck dumb" was the right phrase) when you tell them that fixing their beloved "foo" a week before you're scheduled to go live accidently broke "bar" and nobody planned time to test to make sure it didn't.
posted by ruffin
at 5/01/2002 10:10:00 AM
The postings on this site are [usually] my own and do not necessarily reflect the views of any employer, past or present, or other entity. About Our Author