Toss Me a Rope: Programming Yourself Into a Hole? 94
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!"
never been there.... (Score:1)
They think it's done (Score:2, Insightful)
Anyone else have problems with this?
Re:They think it's done (Score:2, Interesting)
My situation is a little different. I work on internal development, so "customers" means other employees of the same company. Anyway, our customers give completely inflexible deadlines: Deploy what you have done, period. They control IT's budget, so we have no real say-so. We allegedly have a maintenance team, but since they have zero understanding of the system, even from an end-user's perspective, all the bug-fixing, etc., invariably falls back on us. Since the customer doesn't understand the concept of maintenance, they can't figure out why we aren't spending 100% of our time on the new project.
An interesting corrolary (sp?) is that no money is allotted for maintenance, so all maintenance gets charged to the current project, which is already thread-bare as it is. In theory, if this keeps up long enough, we'll someday have a project whose budget is all spent on maintenance.
Re:They think it's done (Score:1)
On the other hand, software that it is written for a particular company has to be changed and upgraded as the company needs it. And sometimes when changes are made to software, it has effects that reach beyond what the change was, and they're not always "bugs" or "mistakes."
Also, even the most effective software testers are no match against users when it comes to discovering loopholes and sources of problems in software interfaces!
Re:They think it's done (Score:1)
Not for me to argue about users finding bugs and all, but I've taken all that I've learned about OS software development and applied it to my internal project, which I've been hacking away at for the last eight months.
Here's some things that'll help:
- Enforce a strict release schedule. If there's a bug, find a work-around. Because it's internal or small-scale software it's tempting to go ahead and fix the problem, but you'll only through yourself into more trouble by releasing essentially untested code out the door.
- Involve users at every stage of the development process you can. That way, there'll be no suprises when release time comes, and no manager/PHB saying, "Well, it doesn't cover X, so I'm not going to use it."
- Learn to say no, and get your boss to understand the importance. You're in charge of the project. Many times users ask for things that just don't make logical sense or are not feasable to do. You know better than they do, so... "No."
It all boils down to individual task management. (Score:3, Insightful)
The problem is that people don't leave time for these little tasks, and they accept them without rescheduling other (perhaps more pressing) tasks.
Eventually you'll have to drop maintenance for a project, or reassign that task to another programmer. But most important is to listen to the sales person describe the problem, then point out that they need to go to your superior to have the 'new' project approved and let him push other deadlines around to suit his schedule. If it's your responsability to juggle all these tasks then you'll spend more time doing management than programming eventually, but you'll have to weight and prioritize each task.
In other words, I suspect it's not discussed/researched because it's really a non-issue. The real problem is time and project management.
-Adam
Change jobs (Score:3, Insightful)
Re:Change jobs (Score:3, Insightful)
Just keep working at the problems in your current job. If you're good, maintenance on prior jobs will slowly decrease.
Re:Change jobs (Score:2, Funny)
Become a Contractor! (Score:1)
at one of my jobs (Score:2)
Sometimes I would be juggling 3 to 10 projects at once, but it wasn't a big problem. This method only works if some standards are agreed apon. When you have agreed apon standards, this method can be very good. Of course, it gets better when you have a couple of programmers who can get a lot of things done quickly.
Nah (Score:3, Insightful)
Re:Nah (Score:2)
I disagree somewhat with your saying that the managers and developers need a nudge, its more the users who don't see the big picture, all the pending and future projects, but only their little piece of the pie. Sometimes there whole existence seems to be rooted in this project, despite the fact it's time to bury it once and for all.
Another layer comes from people who don't understand the technology. I develop web apps and I have users who think its very easy to just add a chunck of funtionality in or change the way something works without giving any real though to how long it might actually take, or if it's even possible.
For example, I developed an application taking an address. The postal code field was supposed to take US Zips 5 and 5+4 and validate them, but it was also supposed to take non US postal codes as well "ZXC 123". It wasn't until I showed them on paper that I can verify that something is there, but I have no way of easily checking which country's format this is, or if it is valid in that country or not! They eventually got the idea, but it took a few hours of meetings and email to get there.
Adhering to specifications can be hard too when upper management changes them mid stream. Fortunately I have a boss who raises red flags and get's other projects pushed around, but are we all so lucky?
Development model (Score:4, Interesting)
First of all, the premise of the Waterfall Model is just wrong. Of course you go back. You'll always find a flaw in the req's in mid-spec, and a flaw in spec in mid-design (and a flaw in req when you go back to fix the spec) etc. There's an entire class of development models that are just fixes on the Waterfall Model. But the basis is flawed, and any model based on it is going to be flawed as well.
The solution to your specific problem is one that you've seen other companies use, possibly without knowing. Once a piece of software is feature complete and passes QA (so you release it), a certain number of developer hours need to be devoted to maintenance. Probably that means hiring a junior coder to maintain the well written code of more senior coders.
There comes a point, of course, where software is no longer paying for its maintenance. It's always legitimate to move an old version to a "mature" state, where it's no longer supported. If Microsoft can do that to Windows98, I don't see why any other company can't do that with (say) their Win98 software.
Re:Development model (Score:3, Insightful)
Hopefully that doesn't mean deprecated. Most projects I've been involved with (I'm talking internal projects here) start from scratch, have a heavy design, development, and testing phase, and then launch live. The first month or two sees heavy maintenance work, and then the code stabilizes and requires basically no hands-on work.
Obviously when new feature requests come in they destabilize the codebase for some time, but you can and usually do get equilibrium: projects that have no development going on generally need no maintenance after they've had a bit of time to mellow.
And that's what I see as a mature project. The ultimate goal of every project I'm on is to reach maturity and just run.
Sumner
Re:Development model (Score:1)
Re:Development model (Score:2, Interesting)
Proponents of the waterfall method reason that for such critical software systems the normal write/test/debug cycle is too dangerous.
To simply dismiss this methodology with such a blanket statement is irresponsible.
Re:Development model (Score:2)
Spiral or evolutionary is better -- relatively rapid reiterations of the waterfall cycle with feedback to the next iteration of the previous phase (i.e. requirements problems found during design are addressed during the next iteration of the requirements analysis phase, etc...).
All releases at the end of each iteration are internal, until the end.
Re:Development model (Score:2)
A short development cycle is probably much better, since the problem with a previous step can be quickly apprehended and dealt with.
Re:Development model (Score:1)
For example: There is a small window of time that will not allow for a debug. You only get one shot. There is no testing/try again.
Any errors at any stage may be unacceptable and/or costly. Human death or destruction of a system, etc.
You don't "assume" that step N is perfect. You ensure to the best of your ability to complete and verify step N as comprehensively as possible. You don't rapidly jump in and out expecting to catch errors later. It's a method, not an algorthm. You have a very distorted way of describing such methodolgies. (eg:"Waterfall says...")
if you are afraid of exponential complexity, you then reduce the scope of the project until you are comfortable. Of course, such an evaluation will depend on your ability and experience.
A short development cycle does not translate to a program that will not fail/blow up and kill people/destroy expensive equipment on it's first test.
Some projects dictate the method. And there are projects that will have zero tolerance for error at any stage. Therefore, you will not be given a chance to "test and see." So you will have no alternative.
Read "Mythical Man-Month" (Score:2, Informative)
Re:Read "Mythical Man-Month" (Score:2)
Is this the same IBM that periodically boots their "Geriatric Club" and replaces them with fresh meat?
The IT industry simply does not value experience for some odd reason. I think it is because it is hard to fake enthusiam forever for every buzz-concept that mamagement reads in the trade rags and believes all.
http://www.computerworld.com/careertopics/caree
<sigh> -- big corporation mentality :-) (Score:2)
Interesting. I've just turned 25, and modesty aside, I'm an above average developer. I consistently generate well over the "20 finished lines of code per day" metric, and I've been asked by senior developers to take on some of the more difficult development work, because they knew I'd make a decent job of it. But apparently, I'm only fit to write documentation? At least I do write documentation, which is often more than those 30+ guys who rate "principal engineer" titles do.
Mercifully, I now work for a company with a rather more enlightened approach. I guess the average developer is in his/her mid-late 20s, and the vast majority of the employees are development staff, not overheads. This development team manages to keep year-on-year growth at a level that would make most of the big corporations jealous, mostly by avoiding pretentious and ageist attitudes, playing to the strengths of each individual, and just getting on with it.
Re: -- big corporation mentality :-) (Score:1)
Interesting. I've just turned 25, and modesty aside, I'm an above average developer.
of course - 80 percent of all developers consider themself as "above average"
Re: -- big corporation mentality :-) (Score:2)
Fair point; I should have clarified that I'm only comparing myself to colleagues I've worked with in various places.
In that case, however, there's a very easy way of telling: look at how much useful work someone gets done over time. The "finished lines of code per day" metric (i.e., how many lines of code you produce on average per day, by the time you've allowed for all the testing, maintenance, documentation and such they need as well) is obviously flawed since just counting lines of code doesn't tell you that much, but it's not an absurd starting point for comparing developers on the same project. Better might be to just look at how many similarly-sized requirements are met by a particular developer's work over a period of time, for example.
I very much doubt that. The reason that 80% of programmers consider themselves "above average" is that most of them haven't worked with, or don't appreciate, really good people. IME, those people tend to congregate and form successful little groups, where even the weakest developer is well above the overall average. If you've never developed in such an environment, or met someone who is of that standard but for whatever reason chooses not to, then you won't know what you're missing. (Obviously, you might be that good, too; even in the 80%, 30-50% must really be above average. You wouldn't know it, though.)
I knew there was a risk of this sort of thread when I made the original comment. It wasn't my intention to show off; I was simply the first example I came up with of someone under 25 who much more experienced people seem to think is capable of more than writing docs. As you say, it's the experience and skill that counts, not the age. I worked darn hard for several years to learn my subject as well as I know it, and I still read more programming-related books in a year than most people I work with have read since graduation. I therefore find it intensely irritating to be told that I "obviously" can't do my job properly yet, because I've only been a pro for three years or so...
ooohhh metrics (Score:1)
The software should be able to handle full-cycle development.
You can work out who write the buggiest code, who the best at correcting/finding bugs, who get things done quickly. Who makes the best designs, and who jumps the gun.
Unfortunately I don't know of any project management software that integrates OO design, regression testing, code review, configuration management, bug tracking and correction, requirements and all that kinda stuff..
As an example stats for myclass might include
interface complexity
dependants
pendants
bugs found pre function
number of design changes
who's implemented each function
who's reviewed each function
links to requirements
lines of code*code complexity for each function/the class
regression tests
time taken for all of the above....
etc.......
cool (Score:1)
Re:Read "Mythical Man-Month" (Score:2)
I have read M3. Multiple times. In fact, I have a copy of the anniverary edition right here. I neither recall, nor can find, any such thing. Please tell me what chapter you found this in, if in fact it is in there. The most likely candidate would be chapter 8, but I just reread it, and there's no such data or discussion.
In my own experience, most (but not all) developers need a fair amount of hand-holding when they first enter the industry, no matter what their age. As the years go by, most of them eventually get up to speed, but many never do.
Our solution... (Score:2)
I'm sure were losing money, and that were bone-headed. But, the payoff in simplicity is worth it - to us. YMMV.
Re:Our solution... (Score:1)
Surely the 'next must-have version' is based on the old code? And if so, the bugs will be fixed (Hopefully!) and should be able to drop into the old/current version with out to much hassle?
I'd hate to even think about someone creating each new version from scratch..
Re:Our solution... (Score:2)
Minefields (Score:5, Interesting)
This issue has so many facets I don't know where to begin.
- Some people program conscientiously, with maintainability in mind, writing lucid code that is easy for them and others to understand. It is easy to change, to extend, and is less likely to need changes or fixes.
- Some coders have twisted minds unlike anyone else's. They code in a fashion they believe makes perfect sense, but heaven help the person appointed maintainer of the project. "Whaddya mean the codes broken and hard to fix? Fred's one of our sharpest programmers, as evidenced by him critiquing everyone else and no one able to understand his high level of intellect!"
- Some people hack in a straight line to the destination in the shortest amount of time. Then, they or their successors spend inordinate amounts of time patching leaky pipes with bubble gum, baling wire and duct tape.
- Some people delight in being indispensible for a project's existence. The code complexity becomes job security.
- Some managers err by seeking to fix the unfixable and appointing poor slobs to a task that really shouldn't be done. Scrap it and rewrite would be the better option.
- Some managers err by neglecting maintenance completely. If it's not a brand new shiny project, then they don't think they'll look sufficiently cool to the C level folks. The bread and butter applications are left to languish while the glittery new buzzword compliant project gets showcased up the wazoo.
and that's just for starters.All I can say is:
Re:Minefields (Score:5, Interesting)
And one goal of good management should be to encourage everyone to be in a useful category. So given the categories above, one might suggest the following approaches:
These are obviously just suggestions and ideas, but they get the general picture. Part of the job of a manager is to figure out how to use the strengths and weaknesses of his subordinates to best effect.
Smart but difficult programmers (Score:2)
Ok, You've identified them as 'Smart but difficult programmers'
I probably fall into that category from time to time. I certainly come up with, what at first seems off the wall to people 'inexperienced' in data systems, but obvious to them once they see how everything fits together.
I'm also a little difficult, in the "I'll do it, but with reservations" kinda way.
Well onto my point, these people are smart and possibly a little too abstract for a lot of people to cope with. There also 'difficult' so forcing them to do something is going to make them obstinate.
I suggest the best way to get 'Smart but difficult programmers' to write cleaner code with good explanations is to get them to cross train and give talks to people, that way they'll have to make them-self's at least a little more comprehensible and they'll certainly think about the way there code is presented. If not then there probably not that smart and just difficult.
I started to write nice, well designed, clean code because no-one in the company could be bothered, the managers were very for the moment, and I though I'd be difficult and make a point. A bit of cross training went on, people knew everyone elses strengths and weaknesses and the standard of code and management increased.
Re:Minefields (Score:1)
The problem later becomes a double edged sword, all the 'safety projects' become boring, they don't want to spend this time fixing them, and the code is so fragile that any changes risk causing more bugs because the coder cannt trace back
The biggest problem of all is, what to do when you wake up one morning and realise just how bad the situation is.
up-and-comers (Score:1)
Re:up-and-comers (Score:1)
I often end up writing documentation for some other components in the project, as if it's not documented when my code has to interface to it...I figure it out and document it.
Besides, it might be me who has to fix it in six months after several other projects...
simple, sorta (Score:2, Insightful)
Rule 2. The only things we pay to get done are those things that (we think) will get us more money than we spend to do it.
If you are a developer, see Rule 1.
Your customer should be using Rule 2, unless it is a public entity, where they use Rule 3: Is the action perceived as contributing to a final goal or thought to contribute to a realized goal (support) that still has money on the contract?
You may now shoot holes in my explanation...
Stabilization period (Score:4, Insightful)
That is a problem. You need to get managers to understand that once a project launches, there's going to be a stabilization period that's just as intense as the development period. It can be short or long depending on the project, but it needs to happen.
And you need to get programmers to believe that they _can_, in fact, get the code to a state where it just runs. That means having watchdogs to monitor it rather than people (sending email when it dies, and avoiding false positives). That means taking the 2-3 (or 20) hours to fix things that require "just 5 minutes" of attention every day. It also means isolating the system into as many independent parts as possible so that it's manageable and easy to work with.
As an example, I worked on developing a massive dynamic content system for a past job. It required a GUI for content authors to do input with, a way to schedule and deploy changes, a server to select content based on user parameters, a way to track content to see what was served where, inventory analysis of what web space would be available, etc. It took over a year to develop, had more than 15 seperate executables built from 75,000 lines of code, and was hell when it launched in terms of making sure it ran happily with all the other systems in place. One daemon needed to be restarted occasionally; sometimes unforeseen log data screwed up reports; etc. We could have just gone ahead and restarted that daemon when it needed it, fixed the logs by hand, and so forth--instead we put the up-front time into fixing the root causes of each of the tiny maintenance chores as we identified them.
Within 3 months it was pretty much hands off, and would send email alerts when something went wrong that the watchdogs couldn't handle. Moreover, because it was 15 seperate components, feature enhancements were generally easy: change one small program instead of a huge monolithic one. We went through several iterations of feature requests over the following year, each one followed by a stabilization period, and eventually got it to the point where it does everything we needed done and did it without needing handholding (and serves 6 billion requests per year).
That's what you need to aim for as a programmer--ongoing maintenance tasks when you don't have feature requests coming in is a sign that the code needs to be more robust.
Sumner
Re:Stabilization period (Score:2)
You must be new... (Score:4, Funny)
Developer is hired by the company.
Developer maintains legacy code left by previous employee.
Developer gets ancy and an opportunity to perform new development.
The new project is released.
Developer has to maintain "his" project while performing other duties and gets burned out.
Developer finds another company, and the whole cycle starts over again for both parties.
Re:You must be new... (Score:2)
Re:You must be new... (Score:1)
It's funny because it's true.
Not at all companies do without.... (Score:1)
A Book on this topic -- Code Complete (Score:1)
Not about writing code? (Score:3, Informative)
I coulda sworn Code Complete was one of the best books I'd ever read about good style in writing code. Were you perhaps thinking of Rapid Development by the same author?
It's the management, stupid (Score:1)
Fact 2: People leave. A sane management team avoids the "truck factor" by making sure, through cross-training and knowledge transfer, that there is more than one person around who can perform maintenance of legacy code. This is also a good thing because, if there is only one person doing all the maintenance, he/she may get tired of doing it and find another job.
Being put on maintenance is also a good way for a new or junior developer to learn the product and the code. Even if they sometimes have to call in the developer who wrote the code, they can often fix the simpler problems, which at least partially offloads the original developers, and it is a great learning experience. This is working well in my company. Of course if you leave someone on this for too long you run the risk that they get fed up and leave (see Fact 2).
internal or external (Score:2)
For internal you'll just need manager buy in. The best thing to do is during project budget to make sure that there is a reoccuring fee attached to the project. Something like $1m for development + $100k per year for maintance. The internal customer can increase this amount if they want more features or decrease it if they want no maintance. But make it clear that no maintance means no maintance, you groups doesn't work without an internal charge code. If it stops working either ask who to charge your time too before you fix.
If your company doesn't use internal charge codes then you can emulate the same situation by calling a meeting with customers and getting them to agree to timeframes on new projects with maintance requirements on old. It may be that they want more focus on new projects than they are getting, or it may be that they don't understand that your department is understaffed to handle the workload.
Refactor (Score:3, Insightful)
Refactor.
You will get feature requests, and sometimes you'll just have to bolt them on. But look for the general case that this new feature is a specific instance of. Sure the feature may be "change the text on the cover page", but the general case may be "make it easy to customize the text on the cover page".
Sometimes the generalizations aren't easy to find, even though you intuit a connection between things. Flip through Design Patterns, and see if anything sparks. You may have to just bolt it on for now, but keep thinking.
Refactoring will reduce the number of lines in your code. And it will make the code easier to understand and maintain.
Re:Refactor (Score:2, Troll)
"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.
Re:Refactor (Score:2)
One of us is seriously wrong about GoF patterns, since IMHO, hardly any of them are better handled with databases. Representing a resource as a single, constructed-when-needed object (Singleton)? Distributing functionality by method rather than subclass (Visitor)? Having a collection of objects expose the same interface as any one of those objects(Composite)? None of these seem to involve databases. Most of the examples in the GoF book are of GUI systems and text editors, and these don't imply databases.
Re:Refactor (Score:1, Troll)
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
Re:Refactor (Score:2)
It wouldn't say Gof is the answer to everything. I would say that it's a useful thing to add to your toolkit. 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. And they do use other examples, such as networking libraries. We're using some design patterns with our software which bears no resemblance to a text editor or GUI system. 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.
Anyhow, I wasn't pushing Design Patterns as some kind of holy writ, just a resource that might trigger inspiration.
(*I have used databases for all kinds of (self-used) utilities, including editors. I just find it easier to organize, find, view, filter, sort stuff when in relational databases.*)
More power to you. Sounds like you use databases the way they're meant to be used. And your familiarity with them helps you avoid reinventing the wheel.
(*Putting the "noun model" in code is a recipe for speggetti in my book.*)
Hardly anything that's good in moderation is still good in excess. Even vitamin C can kill you if you take enough of it.
Re:Refactor (Score:1, Troll)
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.
Re:Refactor (Score:2)
And using data to control behaviour is complementary to patterns like Factory Method, Interpreter, State, and Template Method.
Regarding excess, the tradeoff between pure code and data-based control has to be made based on the need for flexability versus the complexity of programming for data control.
Anyhow, interesting discussion.
Re:Refactor (Score:2)
I am not that up on those patterns, for they seemed paradigm-specific, but IIRC, they manage the *instantiating* of something. In table thinking you don't "instantiate" because the record is an instantiation itself. Instantiation is doing it the OO way instead of the DB-centric way. Instantiation means that you are moving (or duplicating) your noun modeling into the code realm.
(* the tradeoff between pure code and data-based control has to be made based on the need for flexability versus the complexity of programming for data control. *)
Complexity? Perhaps that is a subjective issue again. For the most part tablizing stuff *simplifies* it in my book. I agree that there is a point where one can go overboard with tablization, but the limits are usually due to vendor tools not geered well toward it or specific languages, and not the technique itself.
I suppose we would have to explore a specific example together.
Re:Refactor (Score:2)
No, there are "Structural" and "Behavioral" patterns as well as "Creational". It's only the Creational that focus on instantiation, though pretty well all of them are OO.
Re:Refactor (Score:1)
Re:Refactor (Score:2)
Yes, but when I do this I usually end up moving most of the equivalent into relational schemas. Any given schema deserves its own special name as much as any other schema. So why whould some schema layouts get GOF names and others don't? Who does the frequency surveys to decide what gets named?
It seems kind of arbitrary. I could take a bunch of random schemas that I encounter, give them names, and put them in a book and call them the "next big thing" also.
I don't get it. Seems like Yet Another Fad to me.
Lightweight relational tools (Score:1)
Re:Refactor (Score:1)
Re:Refactor (Score:1, Troll)
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
Re:Refactor (Score:1)
> properly use a database
It is difficult to imagine the narrowness of perspective that could result in such a statement.
There is more to software than business applications. There is a whole universe of application domains where relational database technology is not the solution to most design problems. Even in heavily database-oriented enterprise applications (I work on one) there are generally business object and user interface layers where OOP and design patterns can be essential tools.
Either you are confused about what design patterns are or you are confused about how to build complex systems.
Re:Refactor (Score:1)
> > GOF patterns are for people who don't know how to
> > properly use a database
> It is difficult to imagine the narrowness of
> perspective that could result in such a statement.
Then you've never seen Tablizer's web site.
He is a crank par-excellence. Or a troll with a level of committment that the world has seldom seen. Anyway, he firmly believes that every data structure in the world can be reduced to tables. Check out his web site sometime.
Re:Refactor (Score:2)
How is this more sinister than thinking everything should be reduced to OO classes?
Double standard.
(* He is a crank par-excellence. *)
Bullshit! I stand by my claims. OOP is the crank. OOP has no objective evidence that it is better for all or most domains. None. Only the claims that roll out of the mouths of OO fans. That is *all* you got. Even some diehard OO fans admit that individual authoritative evidence is all there is right now.
Trolling: making repeated claims without evidence.
Re:Refactor (Score:2)
Well in the entire GOF book, I never saw a disclaimer about when and where not to use GOF patterns.
Many OOP practicioners have horror stories about newbies who "over-GOF" designs because they don't know why and when, and there is very little info on why and when of GOF. There's even a 5-level joke about "hello world" GOF-style around on slashdot somewhere motivated by observing overzealous newbies.
There is too much "how" in this industry, and not enough "why".
(* or you are confused about how to build complex systems. *)
I have full confidence in my skill to build complex business systems.
I admit my claim about relational technology was a little flamey, but I simply substuted "relational" for "oop" based on some of the insults directed my way.
Re:Refactor (Score:2)
It's also much faster to say and write. :-)
That is a reasonable point; any time you touch code that was working, you risk breaking it. OTOH, if you adopt a policy of rigorously avoiding change wherever possible, you dig yourself a deeper and deeper hole, until one day you fall in. I've seen both camps; in the long run, those who maintain a design in small increments wind up with far fewer bugs and can adapt far more quickly to change.
history of "Refactoring" (Score:2)
Note that I did *not* complain about the practice of reworking code over time, so please don't go saying, "Tablizer is against refactoring". My complaint was mostly about misleading terminology and dealing with bosses who don't want code changes for the sake of internal cleaning alone.
Refactor used to mean to eliminate redundancy by centralizing repeating patterns or algorithms and then referencing that central copy instead of repeating it over and over.
However, "refactoring" has grown to mean *any* code rework. Thus, it has drifted away from its mathematical roots.
Also, my comment about some managers not liking rework of functioning code was hinting that perhaps alternatives to large-scale rework should be sought. If the boss does not want you do to X, then you have to find an alternative. That does not mean that *I* am against X.
(I still think that OOP requires more code rearrangment than p/r because p/r does not put the noun model into code, while OOP does.)
Re:history of "Refactoring" (Score:2)
Um... I didn't. :-)
I don't see how saying "refactor" rather than something like "making code changes to centralise common features and remove redundancy" is misleading... As for the bosses, I think they're quite right; you should never normally change code just to tidy it up, as it risks introducing unnecessary bugs. By all means do the job properly, but once something's done, tested and signed off, leave it until you need to do something with it.
It has? Perhaps it's overgeneralised on occasion, but by and large, I think refactoring still basically comes down to your "eliminating redundancy..." definition.
Re:history of "Refactoring" (Score:2)
Many tend not to agree with that.
(* It has? Perhaps it's overgeneralised on occasion, but by and large, I think refactoring still basically comes down to your "eliminating redundancy..." definition. *)
Well, it seems to have drifted in my observation.
Re:Refactor (Score:3, Insightful)
That statement, my dear sir, is a glowing example of a specific anti-pattern: Golden Hammer.
Yes, relational databases are one way of solving a problem. The instant you decide that it's the only way to solve the problem, you become part of the problem.
Re:Refactor (Score:2)
OOP and GOF patterns are often implied to be the only and "proper" solution to anything and everything if you read the trade rags.
I rarely see a disclaimer that describes the limitations of OO and GOF. Yet, when I appear to do something similar, I am royally chewed out. A double standard.
The industry is trolling, not me.
Re:Refactor (Score:2)
I disagree that there are no disclaimers that describe the limitations of OO and GOF. There are profuse apologies for the difficulty of persistent data in OO designs everywhere I see. Beautiful OO stuff becomes ugly the instance you add persistence. And databases are perhaps the other extreme - persistence comes naturally, but everything else is made ugly.
But clearly any real-world application has a little bit of beauty from both and a little bit of ugliness from both.
Re:Refactor (Score:2)
Well, show me an example of "ugly DB-centric" code, and perhaps I can help you clean it up.
Two things (Score:2)
The reason you're getting swamped is because _you_alone_ wrote and understand the code, so _you_alone_ are the sucker stuck maintaining it. Don't fall for this. Use the "buddy system". Involve a co-worker in every project you do, whether they're willing or not. You don't have to join the extreme programming fad. But just share what your working on with a co-worker, so they have more than a passing idea what you've done. Then return the favor. Take an interest in your co-workers' projects and learn how they work. Then when something breaks on your co-worker's project when he's out sick or on vacation, see if you can solve it without bothering him at home. Eventually, they may return the favor when you're trying to get some downtime. And if they don't reciprocate, then you've learned your co-worker is a worthless fool, if you didn't know that already. Find another buddy then. It's basically the same idea as what managers mean by "cross-training". But if your manager was doing any cross-training, you wouldn't have this problem. So don't wait for your manager -- ban together with your peers, and fix it among yourselves. If some of your co-workers also don't/can't pull their fair share of the workload, teaming up on projects will throw that into high relief. Not that I've ever seen anybody get fired from an I.T. job for being too dumb or unwilling to learn to read/write simple scripts, but you could get (un)lucky.
2) Automate every stage of your work with scripts.
Get a scriptable text editor. Write macros to generate comments, common loops, subroutines. Write scripts to version/revert files, run them in a debugger, build executables, make notes about progress or bugs, insert date/time stamps, call up the manual page, etc. Use script or templates to generate new source code files, so that 99% of what you need is there. Many IDEs do most of this already, but you may not be using all the features. Or if you notice a feature that you're IDE lacks, write a script to add it in yourself. And share your scripts with a co-worker who's likely to share his scripts with you. After a while you should be able to create and maintain project with a series of single keystrokes and copying/pasting. Adding and testing new features then becomes much less of a frantic typing exersize, letting you focus on getting the solution right.
The obvious solution... (Score:1)
Of course, this only works well for consultants
Seriously, though... This is not a problem that needs solving.
Maintaining code, my own and others, is a large part of my job. Code not having to be maintained is code not being used. If you're happy to write such code, you're just in it for the money, and would probably be happier working with something else.
Maintaining code is part of being a successful hacker. Take pride in doing it well
Otherwise, you'll do it left-handedly, always being tempted to do a "quick hack" and be done with it so you can do some "real programming" (which you have fooled yourself to believe is the only thing that justifies your position / makes you happy / whatever). Until next time you have to maintain the code, and have to reap the hacks (hm...) you've sown, etc.
Then you begin feeling like you're in that hole. And you dug it all by yourself.
two options... (Score:1)
My thoughts. (Score:1)
Do these programmers actually NOT take on additional work? In my experience, the current job is always put on the backburner when the job with the most revenue associated with it, needs to be maintained.
Probably because there is no real answer. It all depends on complexity of the end product and how much money said product generates directly or indirectly.
This is happenning at my company. (Score:1)
As a result the design ends up being awful by my standards, the code is not commented enough and documentation is either left out or incomplete. We end up spending more time maintaining and fixing the software down the road then if they just simply given us the proper time to design!
Sell by dates on code? (Score:1)
Make it work for you (Score:1)
1) Don't express launch dates as dates, no matter what. Express them as dedicated weeks of work.
2) When bug-fixes/feature creep occur, indicate that the work will take 3 times as long as it will actually take.
3) Require manager to sign off everything you do that distracts you from your current project before you touch it.
In this fashion, you can reach a point where as far as management is concerned, you have been making zero progress on your core project because they told you to do these other tasks, while in actuality, you're getting ahead of your "adjusted" schedule. And if it starts to get too much for you, you have some accounted for hours to look at porn on the company paycheck.
I am a "development manager" -here's what works (Score:2)
After a project has gone "live", we maintain a bug-fix team for a short while to do the hand-holding. Once this team starts to look bored, the people get assigned to new projects.
Any new work is carefully analyzed - only critical bugs are fixed without delay. All non-critical bugs, feature requests, and other bits'n'pieces (documentation, testing for new platforms, end-user support etc.) is put into the great big "new work" pot. It's then prioritized alongside all the other stuff.
This forces the business guys to consciously trade work on existing software against new projects, and it avoids the situation where a developer is inundated with trivial bugs and/or feature requests - we found that many "bugs" were actually new features that nobody had thought about during the main development cycle. This is not necessarily a bad thing - many of the features were terrific ideas which added a lot of value. However, by forcing the business to trade off between those features and all the other stuff they wanted, developers can concentrate on the areas business had explicitly stated were the most important.
We also introduced the concept of "ideal days" in our project planning. This comes from eXtreme Programming and basically requires you to measure roughly what proportion of your time you spend on your "main" project; projects are planned using this ratio, so if we know that Joe can only contribute 30% "ideal" time to the project, we can plan accordingly. It's not a reflection on Joe - it might mean he's stuck maintaining someone else's sucky code - but it avoids squeezing Joe like a lemon.
The book "Planning eXtreme Programming" is very useful in this respect - you may want to get your boss to read it.