Slashdot Mirror
Communication Within Programming Teams?
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?"
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.
11*43+456^2
I am currently working at home for a company where everyone does the same. Just keep your ego in check and expect to learn something in every communication you have (including any code dumps). I find that no single person always has the best ideas. Also if there is a standard just adhere to it until you know why it was done that way, then feel free to break it if you must but you at least know the context.
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!
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."
www.HearMySoulSpeak.com
... as opposed to the 'Dilbert' kind, exists only to keep the rest of the company communicating well with each other.
... poorly ...
...
... happily ... while they work.
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
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
This to me is a good example of the difference between code monkeys and software engineers.
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.
If you listen to people like Martin Fowler (and I do, because he's a smart guy). You start to believe that the first and most significant factor in the success of a software project is getting the best people. Most experinced software managers know what Fredrick Brooks figured out in the 1970's, which is that a good programmer can be 10 times more productive than a bad one.
To laypeople, this is so counterintutive as to be absurd, especially considering that you can't measure productivity, 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.
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
I had the pleasure of working under a truly stellar programmer. Through braindead bosses and vauge requirements he built a system that worked *and* scaled 100:1. Comments were rare but almost unecessary, because all of it was astonishingly consistent. Many a time I was working on the code, wishing for a lib that would... oh, wait! It's already written. 500%? absolutely. He had to be replaced by 5, count 'em FIVE people.
Sometimes seventeen/Syllables aren't enough to/Express a complete
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
Generally what is good code and what is bad code is all subjective. Yeah I know there are instances of really bad code but I see a lot of developer's criticize other's code simply because it is different. If it fulfills the requirements and can be maintained it is usually good code.
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.
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.
Political language
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.
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.