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!"
Honestly - I've NEVER seen a manager take that approach. Amazes me that any engineering manager (software or otherwise) would be like that. Or maybe I've been fortunate to have a management well-grounded in software development practices.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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."
Where I work, the maintainance of existing products is typically transitioned (slowly) to the more junior members of the team. This allows them to aclimate to the way things are done around here and, hopefully, learn from the way the more experienced coders work. As they grow in skill, the ration of new product work to maintainance work grows with them.
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.
Mine actually has a Solutions and Services department for each large scale application. So teams are formed to build new solutions for the application and to maintains the current code-base. Services does all "non-project" length work also, so we keep our minds and fingers busy with coding from time to time so it is not just one liners and/or debugging all the time.
Real democracy is not representative, it lives in each of us
Code Complete -- Steve McConnell, Microsoft Press ISBN# 1-55615-484-4 Great book on the programming aspects of the development process. This book is NOT about writing code, it is about managing and programming within large software projects.
Fact 1: Software requires maintenance. A sane management team plans for this. Your project plan for "the next release" should account for time that may have to be spent on debugging, patches, or maintenance releases for "the current release" and any previous release that is still supported.
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).
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.
...is to only accept the projects you know are going down in flames long before 1.0 release! :-)
.
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.
No sig to see here. Move along.
And you've got more chance of a muslim showing remorse for September 11th than you have of getting a Lunix weenie to pay attention to the management practises of one of the most successful companies in the world.
switch jobs every 3 projects or become a consultant and enjoy the revenue!
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.
The management at my company always want quick fix solutions and don't seam to respect the development cycle.
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!
"If a show of teeth is not enough, bite
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.
Guys, in the world I live in - mission-critical applications - there's more software change as a result of evolving user's needs and environment factors than as a result of bad code.
But software maintenance has gotten a bad rap, to the point where - as example - Air Force officers weren't allowed to do maintenance work; that was only for the enlisted grunts.
Ignore the need for some level of maintenance - and go directly to software obsolescence. Not what you want to do for mission-critical software.
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.
I've seen this problem happen. Typically when people start to assume that "old" code requires increasingly less maintenance. My experience is that code tends to follow a bathtub curve for maintenance effort. Initally it has a high level of maintenance required, then this drops off to a low level, then at some point in the future it requires a high level of maintenance again. (look at all those late peaks around y2k for an example!) This leads me to think that any released code should come with a "best before" date stamped on it. So if you have 100 people write code for a year, and it's all "best before" 5 years from that time - you _know_ that you are going to have more maintenance effort 5 years after release - even though in the 4th year there may be less. Of course in the real world individual components have different best before dates from each other - but at least it highlight's it's never over.....
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"
I had this problem at work until I learned to make it work for me...
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.
-1 Uncomfortable Truth
(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.
Do you have any suggestions as to lightweight relational tools (like keyed lists) (lightweight as in don't have to pay royalties for Oracle or whatever)? Are there collections in C++ STL that you like? Anything else?
of course - 80 percent of all developers consider themself as "above average" ;-)
True. And it's hard to have any kind of real metrics. For example someone who knows OpenGL would be 100x more productive/useful at a graphics problem than someone who was much better overall but had no graphics experience. So there is no real way to say for sure. I'm sure I'm well above average in Unix C programming, and crypto and security related stuff. I don't know crap about graphics or UIs. So am I above average or below?
People emphasize their strengths. That just makes sense. Probably 80% of people are above average programmers within some limited area.
That aside, I find the whole "You need to be N years to do X", for any N or X, absolutely stupid. What's required is experience. The experience level one person has at 30; another might reach at 20.
It is exactly the problem I'm facing right now !
In our company (we develop for internal customer) we have a strange tradition of assigning new people to new projects, while keeping the old guys on maintaining the old things.The implications are:
a) new guys don't get familiar with existing coding and design culture, they create new stupid code repeating the same mistakes already made by others
b) the old guys get buried into the legacy code, their abilities are underused and morale is low, because they do not receive attention and great bonuses that accompany new sexy projects
("Well, you're still dealing with X system ? I thought it was finished N years ago, you loser ?
Our managers are aware of the problem (I made it clear to them), but reluctant to make any steps because they are afraid to transfer maintenance of existing (very critical !) systems to newbies.
To make things worse, our company has recently frozen IT staff, so no new people can be hired.
For example, being the old guy, I have 3 or 4 systems to maintain, each existing in 3 branches. This is the top of my ability, I cannot afford new projects anymore.
There are two ways out:
1) get out of the company and return 1 or 2 years later. By this time, your current systems will be maintained by someone else, and you'll receive a new project.
2) try to refactor legacy code, reduce number of branches/variants, introduce automatic testing and make maintenance easier. Hopefully (in the long run) you can reduce amount of time spent on maintenance 2 or 3 times and get time for new projects.
But this is only a temporary solution.
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.
The first thing of course, is to spend as much time as possible on testing your stuff before its released, so that it doesn't have too many bugs in at that stage. Of course there will be some, but hopefully none that require a rushed out patch when discovered. Next, most software projects are ongoing, they mostly don't just have single release date and then that's it. So after the first release, you have two areas of work, bugfixes and new features. Then it's simply a matter of making sure all these are clearly prioritised by the marketing bods, so you know which ones to do first. Provided you can prevent your PHB from bumping everything up to priority 1 that is. A good issue tracking system is useful here. I've found this works really well in an iterative/incremental approach. One project I was on, we had increments of 1 month. At the start of each, we looked in the tracking system, looked at the top priority issues, estimated how many of these we could do in the next month, and that's what we did, whether they were bug-fixes or new features. We'd also usually do a bit of refactoring while we were at it, both to help integrate the new stuff, and to tidy up the old stuff. For assigning priorities, bug-fixes usually came in low, unless they were real howlers or specifically requested by a key customer. This is of course driven from a revenue point of view. You want to work on stuff that generates the most money: New features => new customers => lots of revenue from new orders. Bug-fixes => keeps old customers happy => some revenue from upgrades or expanded orders. I think this is the way most companies work, even if it's not actually the most convenient way for existing companies. Also I would say its probably counterproductive to assign developers to both maintain old projects and work on new ones. Especially if the old ones have unpredictable resource requirements, e.g. you have to be available immediately a bug report comes in. This can really hammer the planning on your new project! Also it may be harder for a developer to maintain two development environments, especially if they're largely different, e.g. compiler versions, different tools etc. It's better just to gradually reduce the workforce on the old project until eventually it gets dropped. This way also means that all developers work on both new features and on bugfixing, so nobody gets bored etc. So, as you can guess, mostly I've only ever been working on one project, with both bug-fixing and new features in the mix, and I'd say it works well for me.
Skiing? Check out The Independant Skiers Portal
My friend, you are on the first step to becoming a contractor! No point in hanging around once the development work is done.
'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.
I maintained about 6 projects (the ones everyone else buggered up an I was given to sort out) when I was about 22.... There's nothing like maintaining 6 projects, it's a great way to make you write nice code and get the projects as mature as possible as quickley as possible!
thank God the internet isn't a human right.
The best way to get good metrics is to have good project management software.
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.......
thank God the internet isn't a human right.