Slashdot Mirror
Toss Me a Rope: Programming Yourself Into a Hole?
ksyrium queries: "Managers tend to think that once a project is out the door or 'live,' it's done and over with, and assigns developers new project. However, with each project, another portion of each developers' time becomes devoted to maintaining said project. I've seen co-workers reach thresholds where there can no longer take on new work for sake of maintaining existing code. How are Slashdotters (developers and managers alike!) approaching this problem? Obviously, well-written and documented code can allow for faster maintenance by both the original developer and others, but has there been any organizational research done in the area of managing this problem? While I code for a living, my degree is in business, and this was a question dodged in all of my Management of Information Systems and Project Management courses. Google and other search engines haven't turned up much in the way of research, so I'd like to know what Slashdot thinks!"
(* The solution to this sort of problem is easy to say: Refactor. *)
"Refactor" is simply a buzz-euphemism for "rework the code to make it cleaner". Many managers are not too fond of this because there is a risk that you will break something that used to work. The official solution is unit regression testing, however, that practice may not be approved.
Regarding GOF design patters, in my very humble opinion, GOF patterns are for people who don't know how to properly use a database, and would rather hand-knit nodes (classes) together the old fashioned way rathre than use relational commands/techiques to automate that process.
Table-ized A.I.
(* One of us is seriously wrong about GoF patterns, since IMHO, hardly any of them are better handled with databases. *)
Perhaps "better" is a subjective thing, barring some good metrics being put forth.
(* Most of the examples in the GoF book are of GUI systems and text editors, and these don't imply databases. *)
Well, GOF is repeatedly "sold" as the be-all-end-all of everything. If they are only meant for building text editors, then they should say so.
(* None of these seem to involve databases. *)
I have used databases for all kinds of (self-used) utilities, including editors. (Note that not all DB's are as bulky to use as Big Iron Oracle-like stuff.) I just find it easier to organize, find, view, filter, sort stuff when in relational databases.
Putting the "noun model" in code is a recipe for speggetti in my book.
oop.ismad.com
Table-ized A.I.
(* First of all, outside of IT departments and web development, most programs don't require a database at all, so your statement is completely bizarre from the get go. *)
Like I said nearby, the authors of GOF do not clarify their target scope/domain.
Besides, "require" makes it sound like a prison sentence. DB's are a *good* thing. (Some DB's are better for different situations than others, I would note.)
(* The GOF patterns try not to assume anything about the environment in which they're used *)
They assume that 1. you are using OOP, and 2. you want to put the noun model into code instead of databases.
(* Databases are just another way to represent information, *)
And so are OO classes.
(* You should, by now, realize that the concepts of "database" and "pattern" are entirely orthogonal. *)
That depends on one's usage of "pattern". The GOF philosophy is only one (narrow) approach IMO.
See: geocities.com/tablizer/whypr.htm
Table-ized A.I.
(* The fact that they use GUI systems and text editors as examples should show that databases aren't necessarily a 1:1 replacement for design patterns. *)
If I had my way, most of the GUI management would also be in databases. This could help make the GUI builder language-neutral.
(* Frankly, I don't see a lot of overlap here: design patterns are about how you structure your code, and databases are about how you manage your data. *)
Well, I see this as somewhat orthogonal. One can move a good portion of what GOF handles into the database tools. Thus, simpler code. It is more or less choosing to shift the complexity into the code structure, or into database structures. There are a lot of leeway for which way to go.
(* Hardly anything that's good in moderation is still good in excess. *)
Well, what sounds like more excess: A system that uses 50 percent code and 50 percent databases to manage complexity, or a system that uses 100% OOP to manage complexity?
Thanks for your feedback.
Table-ized A.I.