Comments on: Is good code relevant?

By: Thierry Danard

Thierry Danard — Mon, 22 Mar 2004 01:00:19 +0000

Good code is relevant just as quality is relevant. It reduces risks, and saves efforts overtime. Quality is not relevant if you have short term goals. On the other hand, with technology evolving so fast, even good quality code becomes obsolete in a snap. So let’s say relevant at least in the mid-term.

Since this thread talks about frameworks, here are my two cents: a framework is not good because it’s popular.

Some frameworks are popular because they play the lowest-common denominator field. An example is JSP, which was initially designed to convert ASP developers. Bad technology for lots of projects, but adapted to some, and easy to start with for lots of people. Just like Microsoft Access which was a stepping stone for real database products (namely SQL server in Microsoft’s case).

The best framework is the framework that you develop overtime, as your needs grow. Today’s frameworks try to do too much for too many people. They become too complex, they overstretch themselves in and out, features are added before existing bugs are fixed, etc.

They are great tools for the beginners, but let’s not get confused between technical merits and popularity.

By: Anonymous

Anonymous — Thu, 18 Mar 2004 19:37:16 +0000

Hani,
I really appreciate your candor regarding good code. Do you use a framework? If so which one? How would you compare Struts, Webwork and Tapestry?

By: joib

joib — Thu, 18 Mar 2004 14:09:50 +0000

To connection pool or not to connection pool, that’s the question. ;)

The worst example I’ve seen was on a web project (jsp/servlet) where the lead developer boasted that they used their own connection pooling because they didn’t trust any of the third party stuff. It turned out that when a user logged in they added 10 (!) jdbc connections to the users HttpSession. Luckily it was an intranet application, so I didn’t fall on its face instantly. Still they wondered if they had a scalability problem with hundreds of db connections although only a few dozen users where using the system (gee, wonder why).

So, why allocate 10 connections per user? Well, it turned out that the developers where no jdbc gurus either, so instead of doing joins, subselects etc. in the DB they used other connections when looping through the ResultSet of another one.. *sigh*

By: Scarlet

Scarlet — Sun, 14 Mar 2004 20:29:13 +0000

Deep insight, jwzrd! Got any more pearls of profound wisdom to share?

By: jwzrd

jwzrd — Sun, 14 Mar 2004 05:28:46 +0000

This is quite the circle-jerk you started Mr Bile.

By: joe

joe — Sun, 14 Mar 2004 04:01:27 +0000

it's about theory building

people are trying to find common patterns in what they are doing. In the beginning of DATABASES, everybody was happily hacking into some pseudohierarchical database, messy pieces of data and code combined. After that, the first CLEANER designs (e.g. hierarchical..) emerged. Even AFTER that, the relational databases emerged which even have a very neat theoretical framework (Codd 1970).

I think that what the framework addicted web programmers are doing is to try to find their own, more solid, non-messy, well founded framework. Not only for estethical reasons, but also for the power that lies behind such frameworks (cf. Databases ==> relational theory ==> SQL!)

By: misserable

misserable — Fri, 12 Mar 2004 18:07:39 +0000

This kind of stuff just plain sucks if your the guy who end up having to maintain this after the creator leaves. Usually such systems have been build incredibly fast by this person and changing it was easy for him since he wrote the whole mess in the first place. Then you step in and people treat you like your stupid because what the creator did in 2 hours takes you 2 days, and even then you ended up breaking stuff you didn’t even know existed.

Currently I have to do some maintenance on some access and I am utterly misserable because of it, it has 1000+ line methods with goto statements in them all coded directly in the forms, there is no documentation whatsoever other then some code comments of the sort /* heavy wizardry follows */
Basicly i’be been told they where disappointed in me and had expected more. Pretty nerve wrecking

By: fx

fx — Fri, 12 Mar 2004 14:48:25 +0000

There is no good code. There is just code for a purpose.

By: BDKR

BDKR — Fri, 12 Mar 2004 12:21:04 +0000

Hey Odin, I feel your pain. It was the same thing when I first got the job I have at the present time. The guys had this huge slow as christmas abortion they called the “The Platform” but didn’t even the proper syntax for array initialization on PHP! All the while, I was stupid for not picking it up fast enough, in spite of the fact that there was no helpful documentation to speak of.

I was so depressed that I gave notice. Screw it!

BDKR

By: fred

fred — Fri, 12 Mar 2004 11:00:37 +0000

Back to the whole “perfect” code thing….I’ve seen sites that get a lot of “hits” designed poorly too…I’ve seen the same developer struggle for days though on a web based application as opposed to a mere company home page. Nothing has to be perfect…the design should at least make sense though. It may not be important immediately but good code might be important over the long haul…especially if a few bugs are lurking and someone needs to go back in someday to fix. I agree that some go way too far in design.

By: Bob

Bob — Fri, 12 Mar 2004 10:58:40 +0000

XML should die. It awkwardly and inefficiently solves problems that have been better solved before.

By: enterprise developer

enterprise developer — Fri, 12 Mar 2004 07:37:57 +0000

Consolidation of companies in all markets require larger systems that handle thousands of users, and a framework that is flexible, extensible and scalable.

Maybe you haven’t had to scale or migrate apps or data. If you have you know the value of frameworks and flexible design patterns.

By: P"

P" — Fri, 12 Mar 2004 05:10:13 +0000

I hope you not write articles like this because your job is too boring. But you may need to find joy somewhere else and not reiterate something that has been said million times.

By: Scarlet

Scarlet — Thu, 11 Mar 2004 10:59:00 +0000

Good programmers don’t foist XML on their customers! They build configuration tools.

By: Mike Spille

Mike Spille — Thu, 11 Mar 2004 07:44:40 +0000

It’s true, XML is not very friendly at write time. But it seems just friendly enough that writing a custom alternative doesn’t seem worthwhile.

By: fred

fred — Thu, 11 Mar 2004 02:29:33 +0000

Mike, you have a point by limiting the complexity of a single config file. My point however is to prevent that complexity in the first place by designing things so that the “inscruitable” stuff is merely extended by the programmer audience. Perhaps it is moot whether or not it is in a class or xml file other than that both have their fringe benefits.

I myself am not pleased however even with well-known systems that puke on their own xml. (tomcat pukes some rather nice hairballs) Ever have a dyslexic sysadmin try and edit your server.xml only to get the slashes bass-ackwards or missing or they don’t know how to well-form? Even a pro will get frustrated with hand-editing xml. It’s back to punching holes in punchcards.

By: Mike Spille

Mike Spille — Wed, 10 Mar 2004 19:01:43 +0000

Ah Scarlet, just in case you’re serious – what you’ve just said sounds to my ears like “good programmers tell the customer that any change requires a compile/jar/QA/deployment cycle”. Yeah, I can see this working well for vendors – I’ll pick on Cameron for a moment. :-)

Cameron, when you sell a Coherence license , you ask your customers what defaults they’d like and then ship them a custom-compiled jar file, right? This must be the true secret to Coherence’s success!

By: Cameron

Cameron — Wed, 10 Mar 2004 18:37:53 +0000

Mike: Fred, in my opinion the best thing to do is to support hierarchical configs e.g. multiple config files for the same component that are processed in a well-defined order. .. Think of VendorDefaultConfig.xml –> CompanyDefault.xml –> ProjectConfig.xml –> DeveloperConfig.xml.

Yup. Works great, if there is a simple and clear “inheritance / override” concept behind it. We designed just such an approach with one of our customers and it’s worked out quite well.

By: Scarlet

Scarlet — Wed, 10 Mar 2004 17:55:27 +0000

You can make the same sarcastic comment about a single long config file. And since these files can’t inherit from each other in an OO manner, simulating encapsulation is silly. I’ve seen tiny projects with globals pointing to config files which pointed to other config files. And still, a single punctuation mark wrong and all is lost. These config files are overrated when many of them are doubly buried inside compressed archives. Good coders like me try to write intelligent code, reducing the dependence on configuration files to begin with.

By: Pawn

Pawn — Wed, 10 Mar 2004 17:16:49 +0000

A sad thing about most configuration systems is that the implementor got all excited just about the fact that they where using xml at all, who cares if it’s for something as mundane as configuration. That that making a change to said file requires a restart of the damn server anyways.