Communication Within Programming Teams? 93
aldheorte asks: "If you are a developer you have probably, over your time on various development projects, seen lots of projects with really awful code and some projects with really good code. You may also have observed that sometimes the projects with really awful code have a few excellent developers involved, while projects with only intermediate or mediocre developers are able to maintain a pretty good quality of code overall. The lucky few may have even seen that legendary situation of great developers and great code. I have always been mystified by this apparent discrepancy and I think a recent article on CSS development in a team environment may hit the nail on the head: 'The quality of code generated by a team rarely owes as much to the skill of the individual members as it does to the level of communication between them.' I am interested in the experience of others here on Slashdot. Have you observed this discrepancy between individual talent and a project's quality of code as well? How much of the success or failure of communication is based on the members of the team themselves as opposed to the management of the team, especially with respect to allowed time and deadlines?"
It's a matter of brain mapping, really (Score:5, Insightful)
Almost invariably, unless the really good programmer puts an uncommonly high amount of effort into such things, the output of a single really good programmer will look like unmaintainable trash to most other programmers, especially mediocre ones, which are the norm in the industry.
This isn't because he writes bad code, it's because he naturally programs in a way that suits his brain, no tin a way that suits other peoples' brains. When code is written by a team collectively, they have three essential options:
1) They can make very hard, well-documented interface delineations between single-programmer-sized peices of the project and essentially have a bunch of subprojects run by individuals that again look like unmaintainable trash, and nobody can work on each others' code.
2) They can communicate effectively and code to a common standard of thinking and style. Essentially you're finding common ground between all the brains involved. This tends to need to be a lowest common denominator, and the code doesn't come out nearly as fast and isn't nearly as clever, but at least it is maintainable.
3) They can utterly fail to produce a quality product (I think this is the option usually chosen by default).
Personally, I vote for option 1, although option 2 is clearly what the industry shoots for, which usually ends up option 3 because option 2 is pretty hard to do right.
Have to agree (Score:3, Interesting)
Re:Have to disagree (Score:2)
Once the developers are senior enough, it is rarely a matter of good code vs. bad code - it is more a matter of good documentation vs. bad documentation.
I would much rather find some of the most freaky recursive, self modifying code with hard coded paths, in-line assembly, and assumed run-time conditions - if the entire thing is incredibly well documented
Re:It's a matter of brain mapping, really (Score:3, Interesting)
Unmaintainable trash is *not* good code. Not in a team environment anyway. Hell, even when I'm doing stuff only I will see, I write it in a maintainable fashion because I already know that I'm going to revisit it in a year (whether or not I plan to!) and I really won't want to spend half a day trying to figure out what I was thinking.
I agree with you on option 1 except as stated above and I'd loosen up the code ownership a bit.
Coding standard
Re:It's a matter of brain mapping, really (Score:5, Insightful)
We have very different definitions of what makes someone a very good programmer.
I know some programmers who have a decent amount of technical ability, but write such convoluted code that it's useless to others. This is worthless to me. They may as well not have coded anything, since it typically takes more time to figure out what's going on than it would to re-write from scratch. I don't consider such a person a good programmer, and I wouldn't hire any of them.
Paraphrasing Einstein, code should be as simple as possible, but not any simpler. Good programmers are ones who don't introduces unnecessary complications into code. Really good programmers are ones who can express something complicated very cleanly, or can lucidly document why they've done something strange.
Re:It's a matter of brain mapping, really (Score:2)
Where we differ is really in whether code should be maintainable by others very easily at all. In my (obivously minority) opinion, code should stick with who wrote it. Trying to pass off code from one guy to the next is a mistake. Of course, this implies radically different hiring practices than the way most of the industry operates.
Also, when I called my very good programmers' code 'unmaintainable trash' I merely meant that in the sense that it would be unlikely fo ra nother programmer to come along an
Re:It's a matter of brain mapping, really (Score:1)
Re:It's a matter of brain mapping, really (Score:2)
I a word: slavery.
Re:It's a matter of brain mapping, really (Score:2)
Re:It's a matter of brain mapping, really (Score:4, Insightful)
1. Oversimplify: A simple but wrong design is chosen. It is simple to understand so others can maintain it. It will do what it is supposed to but not without a mess of special case handling, which will bloat the project size. This will give some programmers headaches by knowing that the solution is incorrect by design.
2. Use a unique and complex solution: The first programmer comes up with a new solution. The solution is non-standard; other programmers are faced with a steep learning curve to understand how it works. The origninal programmer can maintain the code easily but anyone else has a hard time getting started.
3. Change the rules: Perhaps the reason that the solution needs to be so complicated is because the tools being used to implement it aren't well suited to this type of problem. Change the language or the environment; use something nonstandard that is good at solving the problem. It is hard to find the right one (if it even exists) and it will take a lot of research; you may not have the time or resources to risk finding nothing usable. Another problem is that your programmers need to be skilled in a wide range of languages or they won't be able to maintain the code. Outsiders may not like your code because it uses an obscure environment. Creating or extending the programming environment is difficult in Java or C# but it is trivial in LISP; LISP adapts itself to the problem. Writing a good operating system kernel in Visual Basic would be a nightmare but works well in C.
As for expressing something complicatd in a clear way, this is a measure of writing and communication skills. Unfortunately, many people are bad at that in general.
I see solution #1 used wayy too often; simplicity of design at the expense of bloat and elegance. XYZ corporation can assign huge teams of programmers and managers to these projects. My favorite solution is #2 but most of my projects are only maintained by myself, so I don't have to worry about explaining them. I like having control; I get complete control over things I make myself. #3 is nice, but it is so hard to find what you are looking for. You can't do web searches on concepts. I guess the best way to make this one work is to know about a diverse library of environments. Maybe I just need to get out more
Re:It's a matter of brain mapping, really (Score:2)
Agreed. For a personal project, that's fine. But in a business, you're hopefully creating code that will last a long time, lo
Re:It's a matter of brain mapping, really (Score:3, Interesting)
They can make very hard, well-documented interface delineations between single-programmer-sized pieces of the project and essentially have a bunch of subprojects run by individuals that again look like unmaintainable trash,
It depends on the rev of the code. If the team is entering serious uncharted waters (which is what I deal with regularly), the first draft is code is better to be running than intensely structured (and take twice the time). This is all to say that you can't make a long-term, top-qua
Re:It's a matter of brain mapping, really (Score:2)
I think we're on the same page here, I just suck at communication myself. When I say 'well-documented interface delineations', I'm not referring to heavily structured object models and crap like that. To give an example (a small one, but the concept scales), suppose the application in question is a web-based app with a persistent datastore in an rdbms.
The developers might gather around and discuss things and decide that Perl will be the only language they need to use, Then, they split the tasks such tha
Re:It's a matter of brain mapping, really (Score:2)
Hell, that is not contrived at all -- that is exactly the way we are working on a large project at my current prime client.
And, for the most part it works pretty well -- I happen to be one of the Object/DB abstraction layer guys.
The biggest problem we have had on this project is that the interface was not adequately defined before a lot of the CGI-layer stuff was written, so there is a lot of kludging and rewriting.
Re:It's a matter of brain mapping, really (Score:2)
CGI Guy: I'm not really happy with the interface you're currently putting on db_object_x, it doesn't fit well with my coding model
DB Guy: Ok, I'll re-work that to work better for your purposes.
HTML/JS Guy: CGI Guy, I need you to give me $value_x in a template variable on page_3.
HR Person: *blink* Should I buy caf or decaf for the coffee machine?
Sales Person: Right, right--blah, blah--so how much more can we charge people?
PHB: You people need to stop talking about the trees and build me
Re:It's a matter of brain mapping, really (Score:1)
You write for people, not computers! (Score:3, Insightful)
Re:You write for people, not computers! (Score:2)
As long as people like you keep thinking that way, we aren't going to make any progress. You write code for computers, not for people. It's kinda inherent in the definition. If you're working on a team and most programms can't understand the code you write, then either you suck, or they all suck. However, I didn't say "can't understand the code you write", I said "will look like unmaintainable trash", which is markedly different. I can understand the output of another good programmer, but if I were ask
Re:You write for people, not computers! (Score:2)
This indicates that either you or the other programmer (or both) do not deserve the appellation Good Programmer. Clean, maintainable code is important because it costs time and money to constantly rewrite unmaintanable code. A Good Programmer (tm) knows this and works in a professional manner, which includes neither wri
Re:You write for people, not computers! (Score:2)
You're confusing a Good Programmer, and a Programmer Well-Suited to Corporate Software Development. You do understand the difference right?
Group Dynamics (Score:1)
2) They can communicate effectively and code to a common standard of thinking and style. Essentially you're finding common ground between all the brains involved. This tends to need to be a lowest common denominator, and the code doesn't come out nearly as fast and isn't nearly as clever, but at least it is maintainable.
I've recently read a book entitled, "The Wisdom of Crowds", which I found very enlightening (I recommend it quite highly) as it challenged my belief that "the lowest common denominator"
My answer, based on my experiences (Score:1)
As I'm not exactly skilled at coding I tend to spend a lot of time going over things over and over again, to understand why it's doing what it is, and why it's not doing what I wanted.
To make that process easier, formatting "errors" get fixed too, making the code neater, so more understandable.
The only communication here is between neurons
I would hazzard a guess that really good developers spend more time writi
Re:My answer, based on my experiences (Score:2)
Mark
Re:My answer, based on my experiences (Score:3, Interesting)
One of the issues I think is that if you incorperate a certain level of sophistication into your code then people who can not program to that level think it is much too complex.
Take perl for example (mostly cuase you said ick ;-]). Perl is highly idomatic with "More Than One Right Way" to do things. Simple perl code is simple and easy to understand; however, the uninitiated will find it next to impossible to understand how the "magic" of some perl modules works. Modules that use things like glob refs, tied
Re:My answer, based on my experiences (Score:2, Insightful)
Take perl for example (mostly cuase you said ick
Re:My answer, based on my experiences (Score:2)
Hmm looking back at my post I realize that I didn't really state a position on the issue. I'm with you though. Things like IO::Handle couldn't have been mad without some of the techniques I mentioned above.
If you don't understand the code, perhaps it's you.
Re:My answer, based on my experiences (Score:1)
When I write code I put a lot of thought into the structure and logic flow before I write it. Along the way I try and comment that logic as I go. The problem is the big picture all makes sense to me and I am in a hurry to get all my ideas down.
I often find that when I go back and read my code, my comments are full of typos and often do not comment on the re
Re:My answer, based on my experiences (Score:3, Insightful)
Re:My answer, based on my experiences (Score:2)
Re:My answer, based on my experiences (Score:3, Interesting)
Until next year when programmer #2 who does know how to spell works on your project (or, in your case, you yourself learn to spell), and types make and hits return harder and harder and curses you out loud, because he has to remember to misspell caffeine precisely the same way you did in every place.
Then, one day, he will get tired of it, and S&R the misspelled version with the non-misspelled version, and blood pressure will be relieved.
One metric of a programmer is "how much time transpires betw
Re:My answer, based on my experiences (Score:2)
Re:My answer, based on my experiences (Score:1)
"Colour" every time... not only is it correct, but it's guaranteed to avoid reserved-words and functions from other peoples' APIs....
Re:My answer, based on my experiences (Score:5, Insightful)
develop a coding style and stick to it ruthlessly.
It doesn't matter whether you dooror whether you indent with tabs or spaces, or use $perl_style_names or $studlyCapsNames
just choose one and stick to it.
You'll find your code becomes much, much clearer.
This is particularly true when you are messing with PHP (ick
oh, and learn python cuz it kicks the ass of perl and PHP
dave
Re:My answer, based on my experiences (Score:3, Informative)
Always curly-bracketing your if statements will result in fewer bugs, statistically.
Why? Take this piece of code:
if (cond)
doThis()
now what's your first urge when you want to add something?
if (cond)
doThis()
doThat()
Works in Python and Ruby fine, but not in C. Hence always do things of the form
if (cond) {
doThis()
}
Re:My answer, based on my experiences (Score:2)
Personally, I
* think the tab key is there for a reason
* want to see "if" or "for" or whatever lined up directly above my end brace
* follow language conventions for variable names, but prefer Perl style: $var_name and ClassName
Re:My answer, based on my experiences (Score:1)
I personally do not curly brace until I have to, because I want my code to be compact. The more compact the code, the more I get into a screen, and thus the more context I can see when I make a change. Seeing more context decrease the chance of bugs.
When working on code that is properly indented (all mine is), I have not once made the mistake this defend against in over twenty years of
Re:My answer, based on my experiences (Score:2)
But I've had to debug code like this:
if(condition)
doSomething();
doSomethingElse();
Where you have no idea if the doSomethingElse(); line is just badly indented, or was intended to be a part of the condition block.
I like lots of context too, but assuming you put the opening bracket on the same line as the if, then you're only adding one extra line, but you're making it clear to others what yo
Re:My answer, based on my experiences (Score:1)
Summary: I've looked for this bug for ten years. In that time, I've seen it twice from other people, and have never made it myself. My personal conclusion is that the extra space consumed cost more than those errors.
As for the if (ptr) vs if (ptr != NULL) variant: I feel the extra space and "= NULL" decrease the signal/noise ratio of my code. The significant part, the stuff I need to keep attention on, is the !
Re:My answer, based on my experiences (Score:1)
Well, you learn something new every day
The other points were of course personal preference. Adding the {} works for me, leaving them out works for you, they're both valid so we're all happy
Re:My answer, based on my experiences (Score:2)
Using the wrong curly brace style (your first example) will likely get you stabbed in the throat by the hardcore programmers on your team.
Or at least a stern talking to
Just watch the egos (Score:4, Insightful)
The big difference between less skilled developers and skilled ones is usually flexibility in how there code is written. Skilled developers know the best way, whereas less skilled are willing to learn.
BTW in case you can't tell I feel people who "know the best way" generally don't!
Exactly my experience (Score:4, Interesting)
Now he is gone, and when we detect a bug in one of the old programs (that some of us still have to use) we usually start to refactor the whole thing, only to understand how it is working.
Writing new software now follows strict rules, and we talk a lot about how to do things. All team members are able to understand the code base (or so it seems) - unless maybe a very sophisticated template based compile time decisions shows up (then some brains just snap *grin*).
Since we are at an scientific institute where team members change quite regulary, transparent code is the only way to survive in the long run.
Re:Exactly my experience (Score:2)
Good god, he removed the comments? Why on earth... "This looks like pretty good code you've got here, but these pesky comments are just taking up too much disk space and don't actually do anything. Better remove them... there."
Tech Leads as information conduits (Score:5, Interesting)
Part of this is being the listening board for other members of the team, which comes naturally as a result of being a senior member. But it also comes from always having one's ears open, without having to force your way into every conversation and say "What's this? What are we talking about?"
You'll know if you're doing it right because the world around you ends up feeling like you're in the middle of a giant coincidence. You hear two people talking about something and you say "Hey, I just saw a tutorial on that in so-n-so's blog" or the guy in the cube next to you says to anybody that's listening about a problem he's having with JSP and you shout back "Check with Ashish, he told me he was looking into something similar a couple weeks ago..."
Let stuff arrange itself in the background of your brain so that you can call it back when you need it. And then bring it up as needed, don't shove it down anybody's throats. You see an article that says Struts is out and Tapestry is in, you don't walk to everybody's cube and say "Hey, did you hear that Tapestry is the new thing?" Forward a link to the article to the team. The ones that want to read it, will. But then a month or two later when the boss asks whether you should go to Struts, then is the time to say "I hear Tapestry might be the better choice..."
Once upon a time I used to argue that hacking is understanding of the resources available to you, and creative application of those resources toward problem solving. Everything that you take in, be it what you did, read or heard, counts as "resources available to you."
completely OT (Score:1)
Re:completely OT (Score:2)
isn't it Janis not Jamis?
Not the way my 2yr old pronounces it, you see. :) She also thinks the words to HAIR include "tangle tangle tangle my spaghetti".
Re:Tech Leads as information conduits (Score:2)
'Proper Management' ... (Score:4, Insightful)
You can't put stuff in the hands of your customer without communication. Good companies do it well, poor companies, well
So, yeah. Software teams who just really communicate well, do better together. Its kind of obvious, duh
But the thing is, the general 'ideal' that "Management = Bad" can be traced as a meme back to failures of Management to keep people talking to each other, well, and
code monkeys vs. software engineers (Score:5, Insightful)
The best code I've ever seen did come from a team that got along and communicated very well. And yes, that excellence was a direct result of the developers' communciation skills much more than coding skills. However, an external factor that made a big difference was our methodology. We adhered pretty strictly to a very formal OO methodology. That methodology essentially forced us to communicate well. It forced things that previous posters mentioned, like coding standards. But, it definitely went beyond that.
One of the big lessons I walked away from that project with was the value of design reviews. We'd each design our assigned pieces, but then we'd come together as a development team to review the designs. We would go through everything starting with the interface and getting down to the design of individual classes. Developers were forced to hear others' ideas. A key to success was that the developers weren't so defensive as to ignore all feedback - a lot of feedback from those design reviews ended up in the design and consequently the code. That code turned out (IMO) great because everyone was able to understand it - it was well engineered, coded to standard, commented well. But these were properties we *expected* of our code.
To make a long story short, I think the ability to incorporate feedback into one's design and implementation is a critical skill for a software engineer. I think that adhering to a strong methodology establishes a framework to enable communication among developers. Being a "l33t" coder is further down on the list of required skills than the ability to solve problems, communicate solutions, and accept criticism.
Re:code monkeys vs. software engineers (Score:1)
IMHO, the group needs to work together so they don't work on something they shouldnt have, and so when the team lead gives them their assignemnts for the night or week (I was the lead. Gave them lots, gave me lots... big project... ugh) they know what they are doing and
What is a "good" programmer? (Score:4, Interesting)
How are "good" and "bad" programmers measured? Whether I'm doing paid-for commercial development or working with a team for free, my criteria for a "good" programmer is the same: produce code that performs its intended purpose, is reliable, and is maintainable. The question of maintainability includes considerations such as design (in the small), style, and documentation.
The idea that deadlines lead to bad code is a fallacy, and a self fulfilling prophecy. Code that is written well the first time has less bugs, which are more easily tracked down, and is easier to integrate with. Unfortunately those that cling to this mantra tend to believe that the only way to meet a tight deadline is a hack job.
Communication is important in code quality and in meeting deadlines. Communication provides a way to learn -- about better ways to do things, about how the program flows, about what utility functions are available, about how not to reinvent the wheel, and about who can give you a quick answer to a problem that may require half an hour of searching through a large code base. All of which contribute to better code and greater productivity.
Most important, communication allows a team to inform a member who thinks (s)he is somehow special or better, that "programming" and "software engineering" are different disciplines, and that the latter is required for long-term success.
Re:What is a "good" programmer? (Score:2, Insightful)
Twylite (234238) [slashdot.org] wrote: The idea that deadlines lead to bad code is a fallacy, and a self fulfilling prophecy. Code that is written well the first time has less bugs, which are more easily tracked down, and is easier to integrate with. Unfortunately those that cling to this mantra tend to believe that the only way to meet a tight deadline is a hack job.
The problem isn't so much deadlines as it is unexpected additions to a project without a corresponding change in deadline. You're saying that it's not t
Re:What is a "good" programmer? (Score:2)
You missed my point. I regularly work on insufficient information to deliver a completed product that was ordered today and wanted yesterday.
My point is that in any non-trivial implementation, it is faster - from a purely getting-the-code-working viewpoint and and whether the requirements or design change or not - to approach programming in a methodical way with forethought, consideration, and proper documentation.
A program you write in this way has an excellent chance of working correctly with little
Re:What is a "good" programmer? (Score:2)
Re:What is a "good" programmer? (Score:2)
The idea that deadlines lead to bad code is a fallacy,
That depends on the way the deadlines are determined, and how fixed the requirements are.
Too often, the archetect is given an amorphous blob of needs, wants, hopes, and fears, then immediately asked for a timeline, before being given a chance to read the paper documents that go with all of that. If he DARES to use any time related words besides 'heat death of the universe', that will magically transform into a promised deadline.
In that moment of
Re:What is a "good" programmer? (Score:2)
You're basing your entire argument on the assumption that bad code is a faster route to a deliverable project. See my other responses in the thread for why this assumption is not true.
Re:What is a "good" programmer? (Score:2)
You're basing your entire argument on the assumption that bad code is a faster route to a deliverable project. See my other responses in the thread for why this assumption is not true.
Actually, I'm not claiming that at all. Bad code is NOT faster. Unfortunatly, it tends to LOOK faster at the time when faced with an unreasonable deadline. It's unfortunate that to a customer or PHB , doing it right LOOKS like you're making little progress with a deadline looming. A bunch of crap code LOOKS like real progr
It's all about people... (Score:5, Insightful)
To laypeople, this is so counterintutive as to be absurd, especially considering that you can't measure productivity [martinfowler.com], but it is nonetheless true. While picking the right development process, management team, tools, etc. are important, nothing is as important as getting the best people that you can find. Although you have to pay them twice as much sometimes, the ROI on a good developer is going to be 200%-500% higher than a bad one.
Yes (Score:4, Interesting)
Re:It's all about people... (Score:3, Interesting)
Alot of brilliant engineers and programmers are brilliant for a good reason: their brains are wired to intuitively grasp what mediocre programmers need to explicitly think about.
There's a downside to that as well; namely that those individuals do not have the best communications and personal skills.
Re:It's all about people... (Score:3, Insightful)
Alot of brilliant engineers and programmers are brilliant for a good reason: their brains are wired to intuitively grasp what mediocre programmers need to explicitly think about.
There's a downside to that as well; namely that those individuals do not have the best communications and personal skills.
That doesn't follow. One can find complex things intuitive and have good communication skills. Many people can explain their "intuitive" ideas. Those
Re:It's all about people... (Score:3, Interesting)
That's really what the question's about. I think everybody wants the best people on their team. There are even best managers, because managers do actually add value (normally as gatekeepers to keep ec
Re:It's all about people... (Score:2)
As developers, we all know some developers who are 'better' than others... What measurement are we using when we say that? Is it ineffable?
I would refine his argument to say the is not an 'objective' measurement of productivity... there isn't anything I can put on a scale and say "programmer A is better than programmer B because of X",
BUT, I think there is a 'subjective' measurement that is my opinion, based on work
Re:It's all about people... (Score:2)
BUT, I think there is a 'subjective' measurement that is my opinion, based on working with programmers A and B. These are things like "Job knowledge and versatility", "communication", "Quality of Work", "Quantity of Work", "Teamwork", etc. There are no units by which to measure these things, but I can tell you if one person has more of it than another if I have been working with them for any length of time.
By acknowledging that there is a quality related to productivity that varies between programmers,
Style doesn't solve everything (Score:5, Insightful)
The case study in the article makes the point of how difficult it is to search and replace when there are different representations for color. Nice example, but coding style is the wrong approach to solve this.
Firstly, if you really have 3000 lines of style sheets (oh dear, a whole 3000) and you're using a consistent color scheme (which you must be if you're replacing the same color all over the place) then you really want to define your color scheme (usually primary, secondary and tertiary foreground and background colors, plus "white" and "black") and preprocess the stylesheets.
Second, "search and replace" and "cut and paste" should only be used by a miniscule number of ridiculously competent developers who fully understand the risks and have the patience and account-type mentality to use them properly. Unfortunately this functionality is usually used by less experienced developers looking for a shortcut.
I can't count the number of times that I've seen a search-and-replace destroy fragments of unrelated code, or a cut-and-paste has led to weird shit happening. Unless you check what is being changed with a fine tooth comb, you're leaving the results to assumption. And there is much to be said about assumption ... none of it good.
Fortunately the rest of the article is right on target with its approach to quality and productivity.
Define good code (Score:4, Insightful)
Re:Define good code (Score:3, Insightful)
Typically that's all it really takes and it still astounds me how so many college-educated programmers can't even keep up this level of good code.
Re:Define good code (Score:5, Interesting)
Fulfills the specs, no crashes, leaks, etc etc etc, obviously.
Reuses, and is reusable, where sensible (making a religion out of reuse is as bad as no reuse IMHO)
Is comprehensible to the rest of the team (but maybe not on first inspection)
Is documented (Javadoc stylee, for preference!)
Sparse, to the point where nothing can be taken out (without deteriorating into an obfuscated C entry. The rest of the team still have to understand it)
Just one man's opinion.
T&K.
Re:Define good code (Score:2)
I just finished a 3000 line addition to our product, about 1 week early. Is the code good? I saw a lot less bugs than I expected. (though by finished I mean ready for alpha test, I don't know if it is bug free) What does that mean though? Is it good or garbage and I'm lucky. I'd like to think the former, but I know of no honest way to evaluate it.
Sure other coders could look at it, but they have their own deadlines to meet. Even if they did, does the fact that they find it hard to understand (if
Re:Define good code (Score:4, Informative)
I agree with all of these. A couple of notes:
Reuses, and is reusable, where sensible
Yes, especially that last part. A lot of developers talk about reusability, when what they're really doing is gold-plating, adding unused library features.
Is documented (Javadoc stylee, for preference!)
Maybe. I used to write a lot of documentation, but since I've started doing test-first development, I don't really much of it anymore. Why? Because A) I have a good suite of unit tests that document the functionality in a way that can be automatically verified, and B) doing good unit tests encourages you to break things down into small, testable chunks, which are easier to understand.
Re:Define good code (Score:1)
This is a very good point. Here's my opinion, for what it's worth. "Good" code depends a lot on the following:
1. Knowing who the customer is
Much code that ends up labeled as "bad" tends to have been written almost in a vacuum, without the real involvement of the people who end up using
not their main job (Score:1)
Critizing people's code will make you look great! (Score:5, Insightful)
I also think people make a big scene to managers that the previous developer's code was bad simply to make themselves look good. The manager who usually doesn't code says to themselves "Well he must be a great coder if he thinks the previous developer didn't know what he/she was doing."
Another developer cliché is to complain about documentation. Doesn't matter if you write a war and peace size document to explian everything, the next developer is totally not going to read it. The next developer if he/she doesn't understand it simply says "This code is crap". This buys more time to become competent at programming changes and makes them look like a top coder to the credulous manager.
Re:Critizing people's code will make you look grea (Score:4, Funny)
Another developer cliché is to complain about documentation. Doesn't matter if you write a war and peace size document to explian everything, the next developer is totally not going to read it. The next developer if he/she doesn't understand it simply says "This code is crap". This buys more time to become competent at programming changes and makes them look like a top coder to the credulous manager.
Where in the hell did you learn to write, anyway? How on earth do you expect someone to understand that incomprehensible mess? Your writing style is absolutely atrocious. Are you a native English speaker? I've met two-year-olds with better communication skills. The simple fact that you started a sentence with "Doesn't matter" instead of "It doesn't matter" means that your entire comment is garbage and should be rewritten. Oh, and it's explain, for God's sake. I won't even bother to comment on the lack of commas.
It works at different levels (Score:2, Interesting)
Professional versus Script Kiddie vs Software Eng. (Score:2, Insightful)
The "programmer" role I'm talking about is usually in a small team setting to do simple tasks. From what I've seen (and I used to be one) is that these coders take what they do seriously and actually produce elegant code because they have coding "style". Not just simple formatting and tabs,
Source is similar to airplanes? (Score:1)
Keep developers apart (Score:2, Interesting)
What we did do was communicate entirely by email, knowing that any questions would take a day to get answered.
"Poor Code" == Shipping Product (Score:1, Insightful)
The lower quality of code, the more likely the product will ship and sell.
The higher quality of code, the more likely the product will never get done, and will never sell.
When I say low quality code I don't mean some monkeys slapping away at a keyboard, not knowing the slightest thing about programming. I mean smart programmers who know there shit, but they are
Re:"Poor Code" == Shipping Product (Score:1)
This is fine until you start adding the cost of maintainability in. Say you need to ship a version 2.0 out of the door, under the same strict deadline, and that smart hacker guy who wrote a bulk of version 1.0 is no longer with your group. You may end up extending the deadline, and/or needing to hire more capable programmers. You may even have to
Communicate more, code less. (Score:2)
In essence, you must dedicate a portion of a team's tim
performance (Score:1)
No wasted CPU's!
No wasted RAM!
I didn't see any concern about
using resource properly.
On servers running hundreds, thousands of clients
this can quicly becomes a problem.