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!
... 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
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
Twylite (234238) 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 true that the only way to meet a tight deadline is a hack job. Indeed, you're right if you live in the ideal world where you know that the following are set in stone:
Unfortunately, most of the time both of the above points are moving targets. There are many times when a customer (you know, those annoying people who pay the salary :-) will request a full implementation of something that's only so far in experimental stages. Did I mention that they also wanted it by yesterday? Other times, a due date will be pushed forward in order to meet some other milestone (for example, releasing something in December instead of January so that it's in Q4). At these times, a hack job is done with the good intention of "I'll fix it later". Of course, later may never actually come since another deadline will be pushed forward or another feature will be added last minute, causing yet even more hacks to be implemented.
Deadlines do cause hack jobs, well, moving deadlines do anyways. Unfortunately, these are a common occurence.
/<en
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.
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.
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.
I have worked on many projects over the years and I have discovered a relationship between the quality of the code and the success of the project.
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 not bothering to design the most readable, designed, code. They are simply working to build the product as fast as possible.
High quality code is where you have meetings about variable naming conventions, code having to pass review before being checked in, and mandatory unit tests for every function.
I believe the reason for this is that programmers often forget that the code is not the product. People will never see the code, and do not care about it. It is not what they buy.