Java Forum / General / October 2005
the developer contradiction ?
nospawn - 29 Sep 2005 22:04 GMT The more high quality code you make i.e. easier to maintain extend and be taken over and the more documentation you write then, the easier for the employer to dump you and get cheap scamers to replace you and make money from what you developed ...
Isn't this the developer contradiction?
Dag Sunde - 29 Sep 2005 22:31 GMT > The more high quality code you make i.e. easier to maintain > extend and be taken over and the more documentation you [quoted text clipped - 3 lines] > > Isn't this the developer contradiction? No, because that would be very short-sigthed...
Software is seldom done when finished, but continuosly developed and maintained. And there is always new software to be written.
To fire that kind of developer would be like shooting one self in the foot. A one time sale, and the customer will never return when he see quality recline.
all that in addition to, of course, professionalism and pride in ones work.
 Signature Dag.
Roedy Green - 30 Sep 2005 04:44 GMT >Software is seldom done when finished, but continuosly >developed and maintained. And there is always new software >to be written. If you come back to software you wrote yourself years ago, often you don't recognise it at all. It is familiar in than it has your name on it, and some of your quirks, but it rings no bells.
Then you REALLY appreciate the documentation you left to yourself to explain the basic facts of how everything fits together, the tricky parts, what each of the classes is for in a line or two, the project glossary of precisely what you mean by each term. The docs on a class to tell what it does and does not do, rather than details of how it works are invaluable. You can pick up the detail easily. It is the big picture that is hard.
It is kind of like having some incredibly caring friend looking out for you trying to make your stay pleasant.
You know the code won't do anything crazy, so you don't even have to check. You can get in, make your modification and get out, only having to a minimal amount of work refreshing yourself.
When you work for yourself that is the only kind of code you can afford to write.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Again taking new Java programming contracts.
alex_us01 - 29 Sep 2005 22:37 GMT It looks like a challenge, but I thought I would give it a try (gosh, this is like a chess game). So, here is my 2 cents.
The reality may be that your employer likes you more if you write high quality code and keeps you on the job. If so, you continue to write high quality code and be happy. If not, maybe that employer is not good for you anyway, and you find an employer that is as above.
But suppose that the above is true and a good employer is more likely to dump you if you write high quality code. Then, it may still be good for yourself to write high quality code, add documentation, etc. because of your own sanity. As a programmer, you may have an easier time if you do that as the code is easier to develop, add features to, refactor, change, etc. You save yourself the stress and possible guilt for degrading your ability. If this is true and your employer, indeed, replaces you with cheap scamers, then, he will get into trouble because the code will decay over time and the cost of developing and maintaining will increase despite the cheapness of the scamers. Let alone effort, time is also important, which will tend to increase as new requests come.
Your employer will hopefully learn this. By the time, you will be off the job. But if this is true, you will hopefully find an employer that already has learned this in the past.
If so, then it is no real problem for you and there is no good reason for you to change your high quality style to a low one. (You may additionally learn how to find the job and environment you are more suited for.)
Continuing the analysis, if no employer can ever learn that from the experience alone, it may be worth finding ways communicating it. There, some skills of communication and assertiveness may be required. You will have the option to acquire such skills instead of changing your coding style. I'd do that because it is a motivation to improve yourself while the letter would feel bad.
hope you like my analysis...
alex
Oliver Wong - 29 Sep 2005 22:43 GMT > The more high quality code you make i.e. easier to maintain > extend and be taken over and the more documentation you [quoted text clipped - 3 lines] > > Isn't this the developer contradiction? The company I work for provides "IT solutions". We are called in, given code written by someone else, make modifications to it, and give them the new code.
Invariably, the code we're given is always total crap. Why is this?
Because if the code were good, they wouldn't have to have hired experts like us to go in and clean up the mess.
Firing your good coders in exchange for cheap scamers is a losing strategy in the long run because it means you'll eventually have to call in outside consultants like us, and we're very expensive.
- Oliver
Bruce Lee - 30 Sep 2005 02:02 GMT > > The more high quality code you make i.e. easier to maintain > > extend and be taken over and the more documentation you [quoted text clipped - 18 lines] > > - Oliver Firing good coders, hiring crap ones, .. erm hiring good coders to sort crap code out?
Mike Schilling - 01 Oct 2005 02:31 GMT >> The more high quality code you make i.e. easier to maintain >> extend and be taken over and the more documentation you [quoted text clipped - 16 lines] > strategy in the long run because it means you'll eventually have to call > in outside consultants like us, and we're very expensive. I'd guess (please tell me if I'm wrong) that the crap code was in most cases originally written by contractors hired just for that project, not by employees who'd have to live with it. In hiring programmers, I've observed huge difference in the ability to write clean, well-documented, well-encapsulated, maintainable code between people who've been in situations where they were maintaining their own code for extended periods and people who've never had to do that.
Kenneth P. Turvey - 01 Oct 2005 03:20 GMT > I'd guess (please tell me if I'm wrong) that the crap code was in most > cases originally written by contractors hired just for that project, > not by employees who'd have to live with it. I would guess this is probably true, but not for the reasons you would think. Contractors are usually held to higher performance expectations which many managers tend to interpret as simple throughput without regard to quality. I suspect if the manager is good (and able to tell the difference), contractors are probably as good at producing quality code as their permanent employee competitors.
> In hiring programmers, I've observed > huge difference in the ability to write clean, well-documented, > well-encapsulated, maintainable code between people who've been in > situations where they were maintaining their own code for extended > periods and people who've never had to do that. If this is used as a measure for performance of a contractor, you could probably expect roughly the same results as with an employee. I think the difference is that managers simply don't use code quality as a metric. They don't know how to measure it and it is more trouble than measuring throughput.
I know that has been my experience. My last manager measured things like the percentage of time sheets that were submitted on time and the percentage of staff meetings attended (everyone put in forty hours a week and attended all necessary meetings), but never had an metrics on code quality. He simply didn't understand what was important. That attitude went up the management chain at least a couple of levels.
Thinking about it they actually rewarded the production of quickly produced poor quality code in many ways. Strange place.
- -- Kenneth P. Turvey <kt-usenet@squeakydolphin.com> http://kt.squeakydolphin.com (not much there yet) Jabber IM: kpturvey@jabber.org Phone: (314) 255-2199
Oliver Wong - 03 Oct 2005 20:37 GMT > My last manager measured things > like the percentage of time sheets that were submitted on time and the [quoted text clipped - 5 lines] > Thinking about it they actually rewarded the production of quickly > produced poor quality code in many ways. Strange place. Alternatively, perhaps your manager acknowledge that code quality was a factor, but could not measure it in any simple way. Assuming that he wasn't a programmer himself, he couldn't look at the code and decide whether it were high quality or not. He didn't want to simply hire a programmer to read all your code and rate it on quality. He doesn't want to assign one of the existing programmers to rate the code, as that programmer will probably be biased and consider his/her own code to be the best, etc. There isn't any known way of automatically measuring code quality that can be taken seriously (ratio of comments to code? Number of statements in a method? Are the variable names 5 characters or longer?)
In other words, it's simply infeasible to measure code quality in a fair enough way that we can actually reward or punish programmers depending on the quality of their code, and do it cheaply.
- Oliver
Kenneth P. Turvey - 04 Oct 2005 02:21 GMT > In other words, it's simply infeasible to measure code quality in > a fair enough way that we can actually reward or punish programmers > depending on the quality of their code, and do it cheaply. I simply don't buy that. Measuring code quality can be done as well as any of the other measures used to measure the productivity of an employee. It can be done much better than many that are used to assess the quality of employees in industry today. Some measures are actually quite simple.
Many of the programs that I worked on at that job had multi-page main functions that called few or no other functions (in C). A simple measure to avoid this problem would be to measure the average length of a function excluding any switch statements. One could automate this measure and the programmers having their code assessed could collectively adjust and weight it as needed.
Now, I admit, if your programmers are going to game the system instead of working to improve it, it won't work. But, then again, if your programmers are going to do this maybe you should find some new ones.
I guess your measure of cheap and mine aren't the same. The reality is that poor code costs money. We can argue about how much, but the number is high. If you can get programmers to assess their own code you are really going to be ahead of the game.
- -- Kenneth P. Turvey <kt-usenet@squeakydolphin.com> http://kt.squeakydolphin.com (not much there yet) Jabber IM: kpturvey@jabber.org Phone: (314) 255-2199
Oliver Wong - 04 Oct 2005 13:52 GMT > Now, I admit, if your programmers are going to game the system instead > of working to improve it, it won't work. But, then again, if your > programmers are going to do this maybe you should find some new ones. This is basically the core of the problem. Assuming your boss is non-technical, he can't nescessarily detect when programmers are gaming the system, and then replace them. Programmers who were previously writing good code may be tempted, when confronted with a choice between getting a good score on the metrics and writing good code, choose to eschew the latter for the former, because it'd simply be too difficult to explain to the boss why the code is good even though the metrics software says it's bad.
I simply think the code metrics packages out there aren't mature enough to be used for evaluating employees.
- Oliver
Kenneth P. Turvey - 04 Oct 2005 16:00 GMT > This is basically the core of the problem. Assuming your boss is > non-technical, he can't necessarily detect when programmers are > gaming the system, and then replace them. You've got a point. This comes down to how one selects managers for technical positions. I don't have an answer for that. If your manager can't tell the difference between programmers who are gaming the system and those that aren't, or doesn't expend the effort to try and measure code quality in any reasonable way, you probably need a different manager.
This doesn't really solve the problem though. It is a cop out. How does one go about selecting a technical manager? Does this manager need to have experience in the technology being used to manage a project or team?
I honestly don't know the answer to this question. I've known people who could manage any task given to them and I've know people who had all the right skills that couldn't manage their way out of a paper bag. Being familiar with the technologies used is certainly helpful for a manager, but I have reason to believe that it isn't a necessity.
> Programmers who were previously writing good > code may be tempted, when confronted with a choice between getting a > good score on the metrics and writing good code, choose to eschew the > latter for the former, because it'd simply be too difficult to explain > to the boss why the code is good even though the metrics software says > it's bad. There needs to be some provision for handling this. I don't think many good programmers will do this unless they are completely demoralized already and convinced that the manager is a bean counter only interested in the output of a metrics program they have no control over. As long as they have input and a level of control, I don't think it will be a problem.
> I simply think the code metrics packages out there aren't mature > enough to be used for evaluating employees. It would have to be used as a fuzzy input, just like nearly all the inputs used for evaluating employees.
- -- Kenneth P. Turvey <kt-usenet@squeakydolphin.com> http://kt.squeakydolphin.com (not much there yet) Jabber IM: kpturvey@jabber.org Phone: (314) 255-2199
Giovanni Azua - 04 Oct 2005 09:49 GMT > Alternatively, perhaps your manager acknowledge that code quality was a > factor, but could not measure it in any simple way. Assuming that he > wasn't a programmer himself, he couldn't look at the code and decide > whether it were high quality or not. He didn't want to simply hire a > programmer to read all your code and rate it on quality. There are ways to do this automatically i.e. code metrics ... RFC (Response For a Call) determines a measure of overall complexity, Cyclomatic complexity
http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html
You indeed do not need to hire a very high-rate programmer to check someone else's code.
Regards, Giovanni
Oliver Wong - 04 Oct 2005 13:55 GMT >> Alternatively, perhaps your manager acknowledge that code quality was a >> factor, but could not measure it in any simple way. Assuming that he [quoted text clipped - 7 lines] > > http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html Yes, I hinted at code metrics in my post, right before the point you chose to cut off the quote. Here it is again:
<quote> There isn't any known way of automatically measuring code quality that can be taken seriously (ratio of comments to code? Number of statements in a method? Are the variable names 5 characters or longer?) </quote>
Note the "taken seriously" part. I believe that the code metrics packages out there simply aren't mature enough to be used for evaluating employee performance (as I mentioned in another branch of this thread).
> You indeed do not need to hire a very high-rate programmer to check > someone else's code. Actually, I argue that you do. The software metrics measure something; It might be lines of code, "cyclomatic complexity", number of interclass dependencies, etc. But whatever it is, it isn't quality.
- Oliver
Scott Ellsworth - 03 Oct 2005 22:18 GMT > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 [quoted text clipped - 9 lines] > the difference), contractors are probably as good at producing quality > code as their permanent employee competitors. In some cases, contractors are better than existing employees for certain tasks. They may bring specific skills, or a better training system to the party, for example. For this to happen, you have to have good contractors.
Alodar, for example, gives its employees a week of offsite training a year, and we are expected to also take on internal development projects to learn new technologies. Very few of our clients provide this level of training to their employees, which means that we may bring knowledge of three or four object relational mapping systems to a task, or three or four web application systems, while their own people have only used the one that the company has standardized on.
The flip side, of course, is that the employees know their own system better than we do. That is a appropriate - we are each providing something to the task. When implementation time comes, we each have a role, if we are doing our jobs right.
In addition, if we do our jobs right, we transfer that knowledge to the employees before the job is done. We trust that we will learn enough new on Alodar's nickel before the job ends to justify future work at the client - once they know what we know about Hibernate, for example, we have learned about Subversion, or Java 1.5 migration issues.
Since we would prefer to have multi-year contracts, we do try to write code we are willing to see again. Further, since we may be hired back to maintain an app we wrote years ago, we have a strong incentive to make it transparent.
I have had to repair code written by people like you describe. It is not fun. Potentially lucrative, but I would rather work on making the good into the great, rather than the awful into the acceptable.
Scott
 Signature Scott Ellsworth scott@alodar.nospam.com Java and database consulting for the life sciences
Oliver Wong - 03 Oct 2005 20:33 GMT > "Oliver Wong" <owong@castortech.com> wrote in message >> The company I work for provides "IT solutions". We are called in, [quoted text clipped - 13 lines] > cases originally written by contractors hired just for that project, not > by employees who'd have to live with it. We don't ask, with disgusted faces, "Who the hell wrote this?" It simply wouldn't be professional. (In other words: I don't know).
> In hiring programmers, I've observed huge difference in the ability to > write clean, well-documented, well-encapsulated, maintainable code between > people who've been in situations where they were maintaining their own > code for extended periods and people who've never had to do that. Makes sense, and it's something that I've done myself in my own personal projects. When I'm writing a big project which I know will take me months if not years to complete, I make sure the code is clear and well documented; after all, I'm the poor sucker who's gonna have to look at it again tomorrow morning.
But if it's just 2 pages of code that'll just be run once (e.g. to programmatically generate a 2500 byte regular expression which I then just hardcode in my *REAL* project), then I won't bother making it pretty. I doubt I'll ever have to look at it again.
- Oliver
Mike Schilling - 04 Oct 2005 02:27 GMT >> I'd guess (please tell me if I'm wrong) that the crap code was in most >> cases originally written by contractors hired just for that project, not >> by employees who'd have to live with it. > > We don't ask, with disgusted faces, "Who the hell wrote this?" It > simply wouldn't be professional. "We'd like to understand the history of this project." is reasonable, I think.
> (In other words: I don't know). Fair enough.
Ray Brown - 01 Oct 2005 14:56 GMT > The more high quality code you make i.e. easier to maintain > extend and be taken over and the more documentation you [quoted text clipped - 3 lines] > > Isn't this the developer contradiction? To write working and maintainable applications with good documentation is our goal. Once we have delivered we are soon forgotten. If we are very good we are never remembered and the application continues to work until requirements change. We move on to other paths. That is our way.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|