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!"
I don't know how they can think it's done since they are the ones who told you to work the bugs out while it's in production. It went out the door buggy, and so it stays buggy, because some incompetent ass had no clue why you were begging him to wait to ship it.
Anyone else have problems with this?
/* oops I accidentally made a comment, sorry */
Each programmer should have a good grasp of their assigned duties/tasks. It doesn't matter whether the tasks are maintenance, new work, documentation, training, etc. It all boils down to time and task management. If you are stretched too thin maintaining previous projects such that it's impacting current work you need to re-prioritize, often with your superior.
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
People wonder why tech workers have a tradition of changing jobs. This is one reason. When you move to a new job, you rarely have any legacy projects to support in addition to the one you're assigned to.
All incoming stuff went into a queue (whether it was new or old), and the next available programmer that had the knowledge to deal with the reuirements got the project.
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.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Products have life-cycles. Work on a product does not stop on the day of release - a good manager knows that. But a good manager also knows that nobody lives forever and software doesn't either. So when the product has reached its end-of-life status, programmers should not devote more time to the "dead" project and instead devote their time to new projects. Programmers and managers alike sometimes need a nudge to recognize this essential fact.
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.
IP is just rude.
Is there any torture so subl
Fred lays out the data that was, even then, industry wisdom. According to the research IBM did, an average programmer can maintain 3 existing projects or work on 1 new one. But that's just an average. If the programmer is under 30 he can only maintain 1 (or be one of 3 junior programmers on a new project). If under 25 he is only fit to write documentation.
We don't have enough time to "maintain" or older code, and at the same time creat the next must-have version of our software. Our lame solution: Our customers get perpetual upgrades for free. As there is only one code base to be work on - it frees up time and resources.
I'm sure were losing money, and that were bone-headed. But, the payoff in simplicity is worth it - to us. YMMV.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
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:
"Provided by the management for your protection."
There is, of course, a "simple" business solution. Rule 1. The only things that get done here are the things that we have been paid to do. We only do things that will get us paid (X times) more than it costs to do. (or, at least, *think* we will get paid to do. If we think wrong, too big or too often, we go out of business.) :)
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...
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.
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
rage, rage against the dying of the light
Here is how it works in the REAL world...
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.
For external maintance or not is a choice way over your head. If the company should be charging for mainance and isn't there isn't much you can do about it.
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.
The solution to this sort of problem is easy to say:
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.
1) Don't work alone.
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.
Democracy. Whiskey. Sexy. Pick any two.
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?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
(* 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 *)
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.)
Table-ized A.I.
(for me).
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.
It's all very well in practice, but it will never work in theory.
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...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
'Force these guys to work together with somebody else'
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.
thank God the internet isn't a human right.