Is good code relevant?
A few days ago I had a rather interesting conversation with someone. This person is the main developer for a popular site (in its niche). The site gets a few million hits a day, running on a couple of piddly little servers. The servers have fairly high load, but for the end user, it’s surprisingly fast.
The issue at hand is that this developer thought that maybe ten thousand connections to the db is a bit much, and was wondering whether it’d be worth using a connection pool.
Needless to say, I was rather flabbergasted. How on earth could anyone NOT use a connection pool?? It turns out that this was the least of the site’s problems, from a development perspective. Servlets happily emit html, there are no design patterns to be seen for miles. There’s nary a whiff of anything vaguely web frameworky. The mention of TDD would have illicited a blank stare at best.
Yet at the end of the day, the site is a success by any other measure. Users are happy, developer is happy, management is happy, there are no fires to fight outside of the normal operating issues that every project has.
Clearly, this is somewhat of an extreme case. However, it does beg the question, why is everyone so obsessed with the perfect design, the perfect framework, the perfect web methodology? Don’t give me that bullshit about it paying off, or how it ensures the project is a success. Excluding the children amongst you, almost everyone has seen projects that have awful awful code succeed, along with projects using all the right buzzwords and cool frameworks fail. Out there in the real world, I’d be amazed if there’s any correlation at all between success and anything that actually matters to a developer.
Of course, there are plenty of cases where it matters. This rant is directed mostly at all the webmonkeys out there who feel they’re part of some grand adventure or who like to rub their sexual organs against anything off the factory floor. Having said that, there are still plenty of examples where it should matter but apparently doesn’t. JBoss for instance has some truly….interesting code. It’s written in a childish idealistic way, textbook academic applications of patterns, all of which result in abysmal performance. Yet, it doesn’t matter. JBoss is a success, and clearly the quality of the code has nothing to do with that (I’d be surprised if ANY other appserver is slower). Websphere is another example. Developers will cry and wail at being made to use it, yet by any measure that matters, it’s a roaring success.
Back to the issue at hand. I think the reason that webmonkeys are so desperate to feel they’re doing something grand is rather simple. Their work is simply….too….boring. All these frameworks and web doodahs are more often than not simply the product of a hopelessly bored mind desperate to inject some sense of meaning into their daily grind. All the business asked them to do was product an app that solved a specific need. Nobody told them to go invent a framework for it, or to maximise reusability, or to componentise the moving bits, or to use TDD, or to opensource anything.
Yet, all these things happen. The poor developer’s task is so menial and trivial that he is forced to go out of his way to justify his sad pathetic little existence. What better way than to open source it and seek approval from other equally sad pathetic individuals? What better way than to inject the project with what is perceived to be cutting edge, intelligent, and exciting?
So come on people, if your job is boring, please accept that and try to find fulfillment elsewhere. Do not write a framework or seek the approval of other tossers in your field. Find some other, more private, way of coping. There are plenty of ways to find fulfillment that do not involve using the latest ‘cool’ library.
March 9th, 2004 at 2:07 am
first post :)
March 9th, 2004 at 2:30 am
Boring code writes itself, pretty or not. Innovative stuff can be written in hideous ways (*cough*).
The main niches for good code are on projects that are going to evolve or on projects that are going to involve a lot of people.
Eclipse is an example of an evolving product with a large number of developers. Without good code, it would have crashed long ago.
A lot of large open source projects get away with bad code because people don’t mind wasting effort fixing things and working around stupid deficiencies when they’re on donated time anyway.
March 9th, 2004 at 2:54 am
Servlets + JDBC1.0 is a very nice solution for projects with few developers, with standard notations and a good understanding of the schema and design.
Also, these kind of projects are fire-and-forget, more or less. You code it once, and if you need to change something it’s easier to rewrite the entire method than try to change it.
March 9th, 2004 at 3:06 am
I once worked in the same company with a guy who, when I proposed to use a connection pool for a web app, he looked at me in shock and he said “Why not use a single static with synchronized access connection ?”. Now what do you say about that ?
But those were good old days of the web tier when being a web developer was such a honor even if you were coding endless ureadable stupid scriptlets :-). Now it gets boring with all those frameworks (As allways the bitch has a point). You even get to ask “why oh why”. Sad…
March 9th, 2004 at 3:16 am
You mean spawning multiple threads, but allowing only one of them to have database access, blocking the others until the first one has returned out of the synchronized method?
Hmm. Might possibly be a bottleneck if you had serious database access.
March 9th, 2004 at 3:54 am
Well thanks for pointing out the bleeding obvious, Mr. Sargent. I think that was exactly St. P’s point, but thanks for spelling it out for all the morons out there who actually thought it was a good idea.
March 9th, 2004 at 4:30 am
One word for you: KISS. Frameworks are sooooo nineties.
Btw, why didn’t they just use PHP? Java/Servlets/JDBC seems to be way overkill for a website. With PHP you just install Linux+Apache+MySQL and off you go. You don’t even have to use a version control system! If you feel like cutting edge of quality you might possibly consider a staging server.
March 9th, 2004 at 4:31 am
Bad code makes as many projects fail as does over-dependence on frameworks and using other people’s tools. Unless you embrace the framework and code outward from it, as oposed to trying to make your way of doing things work with the framework, the project will likely become a mess.
Truth is that there is no point in using any 3rd party framework or libraries if you are making a final product yourself that doesn’t need to allow for additions or changes in appearance by yet another person.
How ever nice and usefull to something like Formicary EPiX SiteMesh is, if I didn’t know how to use it already at the start of a project, it would be far quicker for me to write my own formatting layer than it would be to learn (and teach the rest of the team) how to implement SiteMesh. The same goes for Webwork. What is the point of moving a simple switch statement that, at the top of a JSP or servlet, checks to see what action need to be performed and calls the appropriate code followed by a forward to the display JSP with an XML config file that makes it a pain in the butt to find the actual code?
I can see the usefullness of it for a portal product that the client is supposed to be able to customize into oblivion without needing the source for the product in the first place. But for your friend’s website?
Comming back to that, nothing in your story suggest bad coding on his part. Apart from the design issue of the database layer, it sounds to me like it is a website built on many different coding conventions and independent modules. Kinda like building a site around many different buzzword complient 3rd part frameworks and modules would look like.
March 9th, 2004 at 4:51 am
Good code matters when the business says it matters. If the business has goals like “extend functionality of website every 3 months”, or “allow large numbers of developers to work on the same project to deliver faster”, or “allow new team members to get up to speed quickly”, using a framework-y approach is, on balance, going to suit the business goals.
If the business goals are “deliver current phase as soon as humanly possible” (and I can think of no real other business cases for this…), using a framework will slow you down - frameworks require time to learn, often involve lots of little configuration files all over the show rather than nice simple hard-coded switch statements, etc.
I have taken ownership of the codebase for a website similar to the one described - it all works, it supports a large number of users on minimal hardware, and it was developed very quickly. And now, it takes us weeks to do even simple things - because the code contains lots of “nice, simple, hard-coded switch statements”, has no coherent overall design or consistent way of achieving common goals, and adheres to no coding style. Nevertheless, from a business point of view the codebase is a succes, because it allowed the company to get through its start-up phase with a working solution.
So, good code matters to organisations that have a longer-term horizon for the code base. Simple. Next : Nev solves the mystery of how to divide by zero.
March 9th, 2004 at 5:12 am
Bas, funny thing is that if you rewrote sitemesh you’d end up literally rewriting sitemesh - it works almost exactly as you’d expect it did. :)
March 9th, 2004 at 5:43 am
I agree to 90 percent of writen. You should not avoid to writing framework if it perfectly fits in design and use case, but you should weigth the fit of it when you move to next project/server, even when it is something like previous project. Any framework should be considered only once user interface(and other interface) shemes are defined. No framework should be used when your site just needs one administrator page. Framework should be used when there are more specialised developers for tasks, e.g. server, application developers, business specialists, you need built in reporting capbilities. Maintaning these from java without business oriented framework is nearly impossible. It can be done, but it will require much more developement resources.
Dont take my words as truth, be sceptic when some one will try sell his framework or servers.
March 9th, 2004 at 6:04 am
Nev, “coherent overall design or consistent way of achieving common goals” has nothing to do with using a 3rd party framework. Or your own for that matter. It only requires what it says in the sentence.
Many Java developers seem to have forgotten that they have a brain of their own and are capable of comming up with a way writing good code their own way, instead of following someone else’s methods.
Anonymous, I am not talking about re-writing SiteMesh at all. SiteMesh offers many features a one-off website does not need. So obviously I’d leave those out. Besides, SiteMesh is a wrapper to work with abused JSPs (ie: mixing too much html with too much code). If you don’t do that in the first place, there is no need for something that parses html and grabs different parts out of it to be used in yet another JSP.
March 9th, 2004 at 7:01 am
People who use XML files to configure their apps/frameworks should all die. XML was a great idea when it first appeared. Use it for marking up data and it’s great. Use it for providing some “intelligence” in web pages, fine (I’m not talking the laughable semantic web here). But use it to configure apps and you are being a useless lazy bastard. You are taking the complexity out of your coding but shoving it on the user.
Anyone can read key/value pairs and modify them. But who wants to learn every dork’s new schema for every app/framework you install? Not me. I don’t care how easy developers make it for themselves as long as they don’t expect the rest of is to suffer through their shitbag schemas just to do something minor in an app. Kill XML configuration programmers.
March 9th, 2004 at 7:11 am
“Formicary EPiX SiteMesh”? What is that supposed to mean? SiteMesh is an OpenSymphony product afaik.
Anyhow, it all comes down to BALANCE. A good developer knows when to use someones elses code and when not too. It’s the extremes that are bad: Always adding dependancies to some new cool lib will hopelessly fuck your project over, and always writing your own will waste huge amounts of time debugging stuff someone already debugged.
I use WebWork because it helps me speed up development. I use Quartz because I could fool it into plug directly into WebWork so I don’t need to learn anything except WebWork.
March 9th, 2004 at 7:38 am
While not explicitly about “bad code”, extreme programming does espouse the idea of “only doing enough to get it to work”. adding things like tests and refactoring sometimes means you can get both.
as an aside, it is often the case that the worst code becomes the most used code. the reasons being:
- it takes less time to produce bad code (you don’t need to do any requirements gathering, up front design, thinking, discussing etc… all the stuff that slows regular projects down)
- required features that don’t match the design being bunged in produce bad code
when the bad code then becomes the basis for how a company does business it’s often hard to shift… and as long as some competitor doesn’t arrive with better software underneath microsoft sells more copies of microsoft excel as logistics system.
March 9th, 2004 at 7:55 am
Nothing succeeds like success.
These people are doing something right. They are doing the simplest thing that will work, for them.
March 9th, 2004 at 8:50 am
Boxed, “How ever nice and usefull to something like Formicary EPiX SiteMesh is” as in: “How ever usefull to ‘boxed’ coffee is before writing replies”.
In case you still didn’t have any and need more spelling out, the latter does not imply you invented coffee, just that it would be good for you to use.
March 9th, 2004 at 10:48 am
I agree whole-heartedly with the rant on XML configuration nuts. Let me just add “Human readable my ass!”. XML configs are for that d00d who wants to show what a lockstepper he is for “declarative” programming and so-called “easy configuration”. “Just a few XML files…” yah right! XML is there because the programmer was too stuped to create a table in the database. Property files were bordering on hideous…XML took it to a whole new level. One easy way for users to configure software….provide this neat new invention called a (drum roll) U I!
March 9th, 2004 at 10:51 am
I agree completely. I’ve seen it myself, and have learned the hard way from others - simple code and design relying at-most on simple frameworks are simple to develop and maintain.
I’m not against frameworks per say, but most frameworks out there are crap - and exists merely because poeple pimp the hype - especially, the web MVC frameworks out there (I agree with the guy that hates the XML configuration monkeys).
March 9th, 2004 at 11:11 am
Opensource frameworks do have their place in development though. I can go out and hire someone who has worked with an opensource framework to help with a project. Finding someone who knows the bizzaro syntax used by the in house constructed bullshit framework, is much harder to do…
March 9th, 2004 at 11:20 am
Jesus,
Who do you think you are? Every damn piece of our application you write, you make it read from an XML config file? What are you, schizophrenic?
March 9th, 2004 at 11:31 am
Dildo,
What the fuck are u on about ? Are u on dope ? Please try to take ur head out of ur a-hole for a minute and think before u write something.
March 9th, 2004 at 11:35 am
Jesus,
Do not hide our love any longer, sure your married, and so am I, but our love is one that dare not speak it name!
Jesus, let’s get married in Oregon, or San Fran, or New York, or…
Diablo
March 9th, 2004 at 11:54 am
Sorry Dildo, my 12-inch dick as big as it is, is not as big as ur Head, i cannot fill ur a-hole, u need to find another dildo like ur-self, or just shove ur dildo-face back up ur a-hole.
March 9th, 2004 at 12:56 pm
HEY KIDS! Cut it out!
March 9th, 2004 at 1:02 pm
Am I the only one who works at a company where there’s absolutely no correlation between the developers skills, and their title/salary?
On so many levels, good architecture/design/code means nothing.
March 9th, 2004 at 1:06 pm
Hani, you’re totally right. I wish I were able to describe the matter in such a poetical way.
March 9th, 2004 at 1:25 pm
A company can get away with poor coding standards for years if the same developers stay with the project. I’ve been with a company for a year, trying to maintain the code and it has NO comments. I’m not kiddding. This is a very large system with many thousands of lines of codes, but the developers have not changed their jobs in years. Two of the developers have worked with this system for a decade. So to them the code is very familiar.
The implication around here is if you can’t understand the code you’re stupid. Now I’ve been doing software development for ten years and this has got to be one of the most depressing places I’ve worked.
It takes a long time to figure out how to make the most minimal changes, and making changes can cause bugs in other areas of the system that you would think are not related.
March 9th, 2004 at 2:11 pm
Easy on the XML config. If it’s appropriate, it’s a good idea. If it’s not, then it’s not. Just like anything else. There are certain situations where it is extremely helpful to move configuration information outside of the context of a Java class. In those situations, properties configuration can work for simple configuration and xml can work for more complex configuration. There’s no getting around the fact that there are certain things that can’t be hard-coded because they are deployment-specific. The argument that “devs were too lazy to use a database” is just stupid. You can’t use a database everywhere and it’s a pain in the ass to test with one.
Of course, the flip side is true as well. XML config files shouldn’t contain the core logic of your code; in fact, it’s doubtful that they should contain any logic at all. The idea of executable XML is kind of silly.
The bottom line is that not all solutions are appropriate in all cases. The developer who says “XML configuration must die!” is just as moronic as the developer who sees the need to do everything in an XML config file. The circumstances of your project will determine what is best and in most cases, that means an intelligent combination of a number of practices.
March 9th, 2004 at 2:17 pm
All other things being equal a framework does provide one key aspect. It keeps the imagination, ego, and stupidity of individual developers in check by providing them with a connect-the-dots type of development environment. As any neophite webmonkey turned experienced hack will tell you. They probably at one point of time viewed frameworks as a boring and unexciting leaving little room for creativity (or whatever makes you feel good) and now view them as essential and ‘enabling’. Enabling them to get on with other things like surfing the net while keeping the new neophites in check. It only takes one idiot feeling creative and with too much freedom to snatch defeat from the jaws of victory.
March 9th, 2004 at 2:23 pm
>Am I the only one who works at a company where >there’s absolutely no correlation between the >developers skills, and their title/salary?
You are so naive to think there should be a link?
It isn’t who is the best, its who can we sell the best. Sure Bob sucks at coding/management/etc but his resume rocks!
March 9th, 2004 at 3:07 pm
who fucking cares about the web tier. it’s for monkeys. the monkeys need a framework to climb on otherwise they get bored and start throwing their own shit around the cage.
March 9th, 2004 at 3:51 pm
Microsoft Visual Basic
March 9th, 2004 at 6:35 pm
Hani - did the site you mentioned mostly serve pages or did it do a significant of handling user input? That’s where frameworks appeal to me … handling form submits.
March 9th, 2004 at 7:19 pm
Frameworks appeal not only in handling form submissions, but handling a form is not a difficult task, it’s just a boring one. And this is one of the main points of this bile, the other one being that software quality is not the same as “using as many frameworks as you see fit”, or even “using frameworks”, for that matter.
Although I’d be certainly guilty of using the framework trigger too much. Lesson learned, Hani. Thanks.
March 9th, 2004 at 9:50 pm
worst xml config : ANT
March 9th, 2004 at 10:24 pm
You can find an answer to your question from Edsger Dijkstra(+), Donald E. Knuth or C.A.R Hoare, with some reasons of why good code matters.
IMO, I don’t see why the business software world should not benefit from that, it will have an impact on people’s live, like other good designs.
March 9th, 2004 at 11:33 pm
Christopher Alexander’s book “Notes on the Synthesis of Form” is a great thought-provoking look at the design process and why it breaks down.
It talks about why “primitive” construction produces forms which are such excellent fits for their environments — the forces that apply there would seem to apply for a site such as the one Hani talks about.
It then goes on to say why the ’self-concious’ designer (the one aware that they’re doing design) trys to abstract too much, which results in forms which are not adapted to their contexts. That fact is part of why I like the Bile blog — it calls a pile of sh** a pile of sh**. The other reason is that it’s funny as sh**
You have to use your brain in your circumstance to figure out what is a good fit and what is just fodder for wank-o-th’-week
March 10th, 2004 at 12:30 am
Die Struts Die !
Die JSP Die !
Die XML Lovers Die !
Die Castor Die !
Long live Webwork ! Long live Velocity ! Long Live Hibernate !
March 10th, 2004 at 3:19 am
VELOCITY? You Praise Velocity??! Come here and let me rub my sexual organ over your lip. VELOCITY my ASS!
March 10th, 2004 at 3:58 am
It’s part of the fabric of our deranged world and markets - go read http://www.dreamsongs.com/WorseIsBetter.html
March 10th, 2004 at 7:27 am
Ah wav’ ma willy at your framey-works you silly programmer persons.
March 10th, 2004 at 9:06 am
I think it all comes down to the number of developers working on said project.
In your example, the scenario is fine for a project with a single developer owning the project and being the project expert. Unless that developer is the company itself, at some point they’ll add other developers. As more and more developers are added and expected to support it, frameworks and standardised usage of frameworks pay off more and more.
This is why any framework or new buzzword which adds difficulty to the team should be rejected.
March 10th, 2004 at 9:55 am
I think that the owner of the site will find it impossible to change. Thats the biggest fact, it might work today, but its very hard to change in the future.
March 10th, 2004 at 11:08 am
More on XML Configs. There are a few rare cases in most programs where you want to change something outside the runtime of your program.
Database driver or JNDI names could be one of those things. I would add that if changing something during the runtime of your program would crash it…then and only then put it in the config. In design though, try to consider changes of most things during runtime.
Put *that* in the property/xml(if you must). XML can have other uses…hell, I used to use it myself for years as a neutral data format. I have also feel into that abyss of overdoing configuration until it started to feel like a favorite lonely-time activity.
March 10th, 2004 at 11:19 am
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. This allows you to keep mostly-unchanging stuff “high up” in the hierarchy, and keep the most changable parameters in a small config file containing only those changes bits.
Think of VendorDefaultConfig.xml –> CompanyDefault.xml –> ProjectConfig.xml –> DeveloperConfig.xml.
The problem this addresses is that fact that some parameters seem to almost never change - but 1 out of a 1,000 people _do_ need to change it. There’s a difference between “almost never” changes and never changes. Sadly, many people seem to only support a single config, which ends up being a giant morass of junk that is 99% unchangable (and inscruitable if you’re not the original developer), with maybe 3 lines that are actually needed by the developer/deployer.
March 10th, 2004 at 2:08 pm
Multiple config files. Nice. Unless I designed that system, I’ll barely have a clue where to find what I’m looking for. Which means I’ll have to do a multi-file grep instead of a text search.
March 10th, 2004 at 3:07 pm
Oh, the pain, the horror, the humanity of it all - a multi-file grep!!!! Bring out the stretchers boys, that last multi-file grep finally killed her :-)
March 10th, 2004 at 3:28 pm
The issue of Project’s Risk is completely ignored in the post.
Developing without a connection pool highly increases the risk of project’s failure. But using a proper methodology leads to minimization of the risk. I am talking here about the risk of development related failures rather than just a bad business model.
Just recently attended a meeting where an middleware application which has been developing for 3 years was thrown away just because it was unable to scale due to some sort of a naive design. Two guys worked on it 3 years - and all is just waste of time and company’s money.
March 10th, 2004 at 5:16 pm
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.
March 10th, 2004 at 5:55 pm
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.
March 10th, 2004 at 6:37 pm
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.
March 10th, 2004 at 7:01 pm
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!
March 11th, 2004 at 2:29 am
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.
March 11th, 2004 at 7:44 am
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.
March 11th, 2004 at 10:59 am
Good programmers don’t foist XML on their customers! They build configuration tools.
March 12th, 2004 at 5:10 am
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.
March 12th, 2004 at 7:37 am
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.
March 12th, 2004 at 10:58 am
XML should die. It awkwardly and inefficiently solves problems that have been better solved before.
March 12th, 2004 at 11:00 am
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.
March 12th, 2004 at 12:21 pm
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
March 12th, 2004 at 2:48 pm
There is no good code. There is just code for a purpose.
March 12th, 2004 at 6:07 pm
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
March 14th, 2004 at 4:01 am
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!)
March 14th, 2004 at 5:28 am
This is quite the circle-jerk you started Mr Bile.
March 14th, 2004 at 8:29 pm
Deep insight, jwzrd! Got any more pearls of profound wisdom to share?
March 18th, 2004 at 2:09 pm
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*
March 18th, 2004 at 7:37 pm
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?
March 22nd, 2004 at 1:00 am
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.