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!
My former boss was quite good at writing his own programs. However, CVS was a no-no, design patterns never crossed his mind, and when he got some code from me and my colleques to put it in his library, comments usually vanished.
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.
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.
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.
I'd always thought that a number 2 would be for the best, however after working a few months in a number 1 for the first time... I have to say I'm liking it. So long as those interfaces are nice and narrow, and well defined (the code I inherited is like that now ;)), then everything just seems to work out for the best, and there's far less knocking of heads day in day out - and very little chance of producing a 3 (my previous employer!)
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
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 data structures, export, and eval to achieve great new additions to the language in ways that seem impossible.
To developers who are used to such things the code would look like an elegant, compact solution. To somone who doesn't it would (quite seriously) look like trash.
100% Crunchier
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
All this hand waving is completely worthless until you concretely define what "good code" is. Most people just assume that if it has no horrible hacks, is formatted ok, and has some documentation, then it is good code.
I had a teacher in college (any M.T.S.U. students or alumni will probably know who she is) that graded our assignments on spelling as well as did we do the programming in an appropriate way. I learned to re-read all code and comments while in her classes. I have maintained that through the years since I graduated and where possible I even run my code through a spell checker. Now, that doesn't mean that everything spell checks perfectly, but I at least try to make sure that the text of comments are correct and that other mis-spellings make sense.
It does make maintaining the code later easier. As I read through it, I make sure that I have followed all stylistic standards for the project properly and also verify logic where possible. I do all of this on a regular basis on small pieces of code as I go along.
If you wait until the end to do this, you probably won't get it done, as someone will be pushing you to release the code so that they can do something else with it. Once it is released, it is out of your control. This includes once the code is added to your source control system to some degree.
I have no sig, does anyone have one to spare?
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.
Ahh, but there is one real piece of evidence.
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()
}
Gentoo Sucks
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.
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. That's totally wrong, and as long as people keep thinking that way, we aren't going to make any progress. You write code for other programmers, for human beings, not for the computer. If you're working on a team and most programmers can't understand the code you write, then the code is garbage.
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.
;-]). 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 data structures, export, and eval to achieve great new additions to the language in ways that seem impossible.
Take perl for example (mostly cuase you said ick
Who is to blame for this? My instinct tells me that it is the novice that should learn the constructs used in the master's code, but I realize that there is a limit. If someone is using a highly advanced language feature to eliminate a few lines of code, then he is probably going overboard. However, if the code is more robust when the feature is used, then the advanced feature is probably warranted. After all, correctness is the #1 priority. Unfortunately, at first glance, the unfamiliar novice will probably not realize the benefits of the advanced feature and will assume it is unnecessary until it has been explained to him/her. This is especially problematic when the novice does not wish to learn the advanced features of a language.
- The first tier is functionality: does it do what it's supposed to do? - The second tier is reliability: does it perform its functionality in an efficient and foulproof way? - The third tier is maintainability: is it easy to modify for changing / new requirements? - The fourth one is adaptability: can it be reused in other projects that require the same functionality? Hotshot / smart programmers usually get the first one done quickly. Professionally-minded programmers usually get the second one right. At that point it usually feels that the job is accomplished. Experienced programmers can make the third and fourth happen. "Good programmers" (smart, experienced and with good attitude) can get 3 or all 4 done. "Newbie" programmers need guidance and double-checks in order to get any of them accomplished. When this happens under a good lead or with a process that ensures the output is truly the sum of the qualities of all team members, it is much more easy to happen at all levels. "Process" relates to communication (documentation, reviews, etc) as well as discipline (enforcing standards, etc). Boiling it all down to "communication" is both correct and woefully incomplete / imprecise.
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 between beginning modification and fixing some stupid little cosmetic problem that is driving him nuts." Feel free now, to include by reference the entire "color" vs. "colour" flamefest from lkml.
One habit I have had to force myself to break, is to re-idiom code to match my personal habits. Or, more accurately, refining the change it or leave it? decision process.
A little snippet of a conversation I had with one of the other guys I work with:
How does the Slashdot Effect happen given that no slashdotters ever RTFA?
I never learned this until I had my Software Engineering course in college; but there is a huge difference between a programmer and a software engineer, and also that script kiddie who you buy simple PHP scripts from.
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, but artistic style in what they do. To me a programmer is sort of an artist. Anybody can splash paint on a canvas, but few people in this world can really make art.
Script Kiddies usually have one single purpose: produce something that works. Regardless if it isn't portable or scalable, as long as it works during the demonstration to the buyer/manager/professor then thats all that matters. This was my first stage in computer science. My projects in school were simply to get them done to get an A on them. Thankfully I eventually developed some form of artistic style.
A software engineer to me is someone who works with a group of other software engineers who use methodical/repeatable methods to produce software. Because this is usually a big team effort, communication, documentation is very important here. From what I've noticed in school and industry is that most software engineers aren't some hot-shot coder who writes compilers on the weekend for thrills, but rather classically educated SCIENTISTS who work together with others well to produce great software and meet the goals of that project. The goal here isn't to make "elegant" code or have fancy formatting. The goal here is to be so close with your team that they should automagically know what your code does. That doesn't say your style can be crappy and hard to read.
What we did do was communicate entirely by email, knowing that any questions would take a day to get answered. The fact that everything was through email provided a wonderful audit trail for the entire project, and the fact that we couldn't get instant answers to questions encouraged us to "think through" our questions before sending off an email about them. Often, the process of writing up a lucid question would force us to figure out the answer (or at least understand the question better) on our own.
When I turned over the project to another developer for maintenance, I was able to give him the archived email messages as a complete history of how and why we developed the project the way we did.
Of course, this is the norm for open-source developers, but it was unique in the corporate environment in which I work.