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?"

Comments

It's a matter of brain mapping, really

[photon317]

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.

Re:It's a matter of brain mapping, really

[HeyLaughingBoy]

will look like unmaintainable trash to most other programmers

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 standards exist for a reason.

Re:It's a matter of brain mapping, really

[mooingyak]

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.

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

[photon317]

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 and be able to 'maintain' it (chances are if you do that, the new programmer just ends up gutting and refactoring the whole thing to fit his brain) - I did not mean that what I call a good programmer would introduce 'unneccesary complications' either - but invariably hard programming tasks do involve neccesary complications, and the solutions to these complications vary wildly between brains.

Re:It's a matter of brain mapping, really

[Foolhardy]

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.

Sometimes the problem itself is too complicated to write code that is both simple and correct. Here are a few ways to proceed from there:

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 :P

Re:It's a matter of brain mapping, really

[andy55]

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-quality piece of software when you're entering on the first stroke. As the saying goes, "expect to throw your first attempt away" (someone please correct me w/ the right quote if you know it).

IMHO, I'm a big fan of the "surgical strike team" approach to development, but then again, our software happens to be on the outer rim of typical software. Also, the "surgical strike team" approach is a more realistic one when you're talking about a small company that can't afford to have lots of devs (and only has one or two "think-tank" devs who wear a lot of hats and can't spend weeks writing specs on concepts that are only first or second generation).

Re:It's a matter of brain mapping, really

[photon317]

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 that one guy writes the database schema and a library of perl functions and/or objects for interfacing with the database, a second guy will be responsible for the actual application logic code which forms the heart of the CGIs, and a third guy is responsible for the HTML output code that's being templated into the CGIs, along with the requisite embedded javascript and what-have-you. The developers obviously have to co-ordinate and communicate, but they do so at an interface level. They don't neccesarily have to understand or be able to maintain each others' code all that well, they just have to communicate the interfaces they are presenting to each other. You can imagine conversations like:

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. ...

(Well, that sounded really contrived and fake, but you get the idea :)

Re:It's a matter of brain mapping, really

[Kalzus]

Dividing up a task into reasonably-sized pieces along *well-delineated* and *sensible* boundaries is usually important to a program of any size at all if is to be maintainable in the future. Option #1 looks suspiciously like this idea, and is probably fundamental to a project of any size that can afford the time this takes.

Re:It's a matter of brain mapping, really

[dubl-u]

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.

Agreed. For a personal project, that's fine. But in a business, you're hopefully creating code that will last a long time, longer than any single person would want to be responsible for maintaining it.

The reality is that people go on vacation, change projects, they leave jobs, they change careers, and they even die from time to time. If a body of code is so idiosyncratic that only the original programmer can deal with it, then that code will have to be thrown out sooner or later. Why would a business want to invest in a chunk of code when its lifespan will only be as long as one guy stays around?

As Martin Fowler says, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Re:It's a matter of brain mapping, really

[YankeeInExile]

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

[mrjohnson]

I think keeping code with one programmer would be a mistake. In my case, I've written a massive amount of code and I pioneer most of the new features, since it's my project. But I'm fortunate to have staff that'll take over when I've finished with a component, otherwise I'd never be able to get anything new done. The sheer weight of supporting all that old code would prevent me from working--or sleeping. It's not even bug reports, which I generally do handle, but new features, or, "We want to sort that column...."

My situation may be a little different, since programmers here are mostly still learning the language, but I doubt it's too different considering the case of the Really Good programmer vs. the masses. He'll write a massive amount of code (though clean will still need support) and he shouldn't be supporting an unequal percentage of the project.

Actually, I'd make the argument that a great programmer shouldn't support anything, their time is much better spent on new features and designs. Great programmers are not usually good at supporting things, anyhow. They lose interest in the drudgery of it all and eventually stop returning emails. That amounts to the abuse of extraordinary skill.

If your other programmers can't understand good code, they either a) don't know the language well enough, or b) just haven't spent enough time reading it. While even a great programmer writes a certain way, as you realize, it just takes time for people to acclimate. It can be a slow process initially, but that's one reason you have the great programmer in the first place, it'll take much less time than otherwise. It takes a good technical manager to insist there are no unnecessary rewrites of the great programmer's code (sacrilege!), but instead only small changes.

Failing that, you may have to reconsider whether you have a great programmer or if he's merely prolific.

Re:It's a matter of brain mapping, really

[andy55]

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 my damn forest!

Re:It's a matter of brain mapping, really

[Anonymous Coward]

You are what we at Red Hat call a KDE luser.

// call start function
start();

// set i to 0
int i = 0;

// call function foo, with argument i, which is 0
foo(i);

// end the program
end();

Re:It's a matter of brain mapping, really

[ebbe11]

Of course, this implies radically different hiring practices than the way most of the industry operates.

I a word: slavery.

Re:It's a matter of brain mapping, really

[Glonoinha]

If you can't be replaced, you can't be promoted.

My answer, based on my experiences

[Gaima]

I write a bit of PHP, bash, and (ick) perl as part of sys admining, and free time messing.
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 writing code, than fixing the formatting, or rewriting bits several times.

Re:My answer, based on my experiences

[Anonymous Coward]

You say you "write a bit of PHP", and go on to "ick" perl?! The mind boggles.

Re:My answer, based on my experiences

[Mark Hood]

I do much the same, to make my code as clear as possible. The only communication is between myself here and now, with the code in my head and all the various functions clearly understood, and myself in 6 months, with no clear recollection of writing the damn code at all...

Mark

Re:My answer, based on my experiences

[fiftyvolts]

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.

Re:My answer, based on my experiences

[drlock]

When I first read the parent post I didn't think much of it, but the more I thought about it the more I realized the benefits of re-reading your code.

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 really important things.

Perhaps it would be a lot more beneficial for coders (at least me) to go back and read their own code after a few days. When we write it, the logic all seems obvious, but when we go back and review it after forgetting the whole process we can better comment on it.

Re:My answer, based on my experiences

[dash2]

A hint (I taught myself, like you I guess?):

develop a coding style and stick to it ruthlessly.

It doesn't matter whether you do

if (blah) {
...
}
else {
...
}

or

if (blah)
{
...
}
else
{
...
}

or 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 ;-]) which mixes HTML and code. You need to have the separation between the two as clear as possible.

oh, and learn python cuz it kicks the ass of perl and PHP :-)

dave

Re:My answer, based on my experiences

[gi-tux]

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.

Re:My answer, based on my experiences

[cmowire]

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()
}

Re:My answer, based on my experiences

[Anonymous Coward]

I sometimes think about making or buying a code editor that had the feature of spell checking comments. I think it would even be possible to correct variable and function names in the comments. Do you know of any code editors with these features? Bad comments are worse than no comments at all.

Re:My answer, based on my experiences

[dash2]

oh yeah, I'm not saying there aren't good reasons to do things in different ways. But doing it _some_ way is more important.

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

[AuMatar]

Bah, spelling doesn't matter, so long as you misspell consistently. I once wrote a game for school where I misspelled the word caffeine in every variable name (I put i before the e). It was wrong, but I did it the same wrong way every time. Compiled just fine :)

Re:My answer, based on my experiences

[e-Motion]

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.

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.

Re:My answer, based on my experiences

[YankeeInExile]

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:

• me:...I kind of regret that inteface - I was not sure it was the right thing when I wrote it, but now it is too entrenched to rip out, but it defintiely is not the right thing
• him:Don't sweat it too much. Great programmers are always wracked with regret. It is the crappy ones who never look back.

Re:My answer, based on my experiences

[AuMatar]

Actually, programmers 2,3 and 4 got theirs s and red, since I was integrating their work into the main codebase :)

Re:My answer, based on my experiences

[gnu-generation-one]

"Feel free now, to include by reference the entire "color" vs. "colour" flamefest from lkml."

"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

[Anonymous Coward]

Emacs - I always spell check my comments.

I also believe that you can setup a spell checker for vim.

Re:My answer, based on my experiences

[fiftyvolts]

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

[Eivind Eklund]

That always bracketing statements leads to less bugs is definately not true for everybody, and it may be a pure myth.

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 programming.

Other common wisdom is to write C statements as if (CONSTANT == variable) ... instead of if (variable == CONSTANT) The latter form feel more natural to me, and I've been using it for ten years, while keeping a careful track of how many more bugs it leads to. I've had one (1) detected bug from using that form in ten years, and it was easy to diagnose and fix.

If you have the choice between two otherwise equivalent styles where one is safer than the other, by all means chose the safe one. However, there are usually other influences. I especially feel succintness often gets ignored.

Eivind.

Re:My answer, based on my experiences

[Glonoinha]

Actually it does matter.
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 ...

Re:My answer, based on my experiences

[mabinogi]

I agree on the if(variable == CONSTANT) one, especially as most compilers pick up the = vs == bugs anyway..

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 you intend.

Alternatively, if it's something really simple, I'll just put them on the same line - though usually only when it's something like the following -

if(ptr != NULL) free(ptr);

(yes, i could just do if(ptr) free(ptr), but again, I think the clarity of explicitly saying != NULL is important).

Re:My answer, based on my experiences

[Eivind Eklund]

Thanks for the answer. I had a long reply, but an ACPI crash took down my web browser :-/

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 ! (or lack of such) and which variable this is done to. Context will tell me if that variable is a pointer or not (if I need to care).

Oh, and BTW (please take this as friendly information): free() doesn't need that guard; it has one internally, specified by the ANSI89 standard (and all subsequent standards.) "Unwritten code has no bugs" (to quote Simon Shapiro). fclose() needs the guard, though.

Eivind.

Re:My answer, based on my experiences

[mabinogi]

> free() doesn't need that guard; it has one internally, specified by the ANSI89

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 :)

Just watch the egos

[StandSure]

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!

Re:Just watch the egos

[Anonymous Coward]

I completely agree with this comment. Some years ago I was involved with creating a set of coding standards for the team of ~15 programmerst that I was working with. Up until then, everyone had different styles for variable naming, function naming, indentation, comments etc etc. There were widely varying abilities from inexperienced graduates to people with many years experience (some of whom were fresh graduates.. :-). .).

The interesting thing was that the experienced programmers were all for the coding standards and happily agreed and discussed what the style should be, and were happy for the peer review process before files were committed to the archive. They understand that it was less important WHAT the standard actaully was (e.g. 2 spaces vs 4 spaces for a tab), but that it WAS important that anyone could read the code and see it in a conistent way.
The less experienced programmers put up the most resistance, arguing that "for a good programmer, all code styles should be equally easy to read", or "my code doesn't need reviewing" and similar such rubbish. When we implemented the system and after the first few weeks of aggravation and teething problems, the whole group setted down and got on with it. The result was that software quality immediately improved, and if someone was on vacation or out sick, there were always others who had reviewed the code and could pick it up with little or no delay to help resolve issues.
Many of these programmers have since moved on to other companies and have tried desperately to get similar systems in place but to no avail. They saw 1st hand how well it worked, but driving it past prima-donna egotistical wireheads just wasn't worth the effort for many of the software managers who couldn't see the almost immediate benefit that it would bring.

Exactly my experience

[gerddie]

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.

Re:Exactly my experience

[Anonymous Coward]

Handholding India workers because, to quote our Fortune 1000 CEO, 'writing software is just like laying bricks'.

Re:Exactly my experience

[bedessen]

nd when he got some code from me and my colleques to put it in his library, comments usually vanished.

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

[dmorin]

One thing I've noticed on successful teams is that the best senior technical people are not those that put their head down and code like maniacs, nor are they the ones who stand in front of the whiteboard with the circles and the arrows. They're the ones that display an almost mystical ability to simply know everything that is going on in the team, and be able to redirect at will in order to optimize what's going on.

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."

Re:Tech Leads as information conduits

[wik]

If you're learning from so-n-so's blog, you've got bigger problems than you think.

'Proper Management' ...

[torpor]

... as opposed to the 'Dilbert' kind, exists only to keep the rest of the company communicating well with each other.

You can't put stuff in the hands of your customer without communication. Good companies do it well, poor companies, well ... poorly ...

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 ... happily ... while they work.

code monkeys vs. software engineers

[ecklesweb]

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.

Re:code monkeys vs. software engineers

[Tr0mBoNe-]

I agree completly. Being a Computer Science student at a Canadian school , We are taught the OOA/D and have courses that are just one 4 month development project. These are all done in groups of 4 and are great fun putting them together.

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 come back with most if not all of their objectives taken care of. Our project was more succesful than other groups (my spelling aside) mainly because we were all friends and knew how to push each other to do our best. There were the groups of people the Prof stuck together because they didn't say that they had a group or didn't have anyone they could work with. Those people managed to complete the project but after reviewing our peers code, their work was bad. It lacked proper style in some cases and when a simple algorithm would have done the trick, they went nuts and did something totally in-efficient like using threads in Java... not smart.

So yes... a team's ability to interact with each other and their own mindsets on the team and the project being in sync do make for a better project. Now... if only those team building exersizes they put us through before the course worked...

What is a "good" programmer?

[Twylite]

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?

[Clipper]

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:

• what features need to be completed
• the project's exact due date

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.

Re:What is a "good" programmer?

[ooze]

Well, I had it more than once, that the engineer/coder simply doesn't get enough or accurate information, despite asking again and again. And after a few weeks, when slowly the information dripples in, the whole base design, implemented on insufficient information becomes unsuited and cripples the rest of the development. Yet, it is almost impossible to tell your "higher up" managers, that actually distribute the funds, to start over again. It's useless telling them it will be cheaper in the long run. It's useless to tell then, noone would be willing to take responsibility when you have to build on that flawed initial design. Well, projects lead by this kind of management deserve to fail.

Re:What is a "good" programmer?

[Twylite]

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 debugging, while hack jobs often contain logic and/or coding bugs, which can be extremely difficult to track down without source documentation (especially in a team environment). Writing unit tests as you go also speeds the development process, rather than slowing it down.

Let me provide a (partially) contrived example: while working in a team to create firmware for an embedded system, I need to retrieve some structured data from NVRAM. First, proper documentation and/or communication with team members quickly will tell me whether or not there are existing utility functions to access NVRAM and retrieve this particular structured data. Second, proper documentation will tell me exactly how to use functions (how to populate the parameters, how errors are returned, etc). This makes the difference between writing C using the standard headers for reference, or using man/MSDN for reference. Third, having a unit test for the utility functions tells me that they behave correctly within their described bounds, so when I am debugging my code I can (largely) trust that the utility functions work, or at least only check them as a last resort.

I also have experience in less mature teams. The first thing I see is duplicated code -- team members don't communicate or read documentation (if it exists) and simply write new functions to do what they need to get done. Second, programmers in such environments spend a lot of time figuring out the correct way to call a particular function, and (if they even understand the idea of checking for error returns) figuring out what is or isn't an error return. I have often seen snippets of prototype code (test_001.c with a main() method and little more) that are just used to figure out the correct way to call a function. Finally, when the program doesn't work (which is always), a huge amount of time is wasted stepping through every line of code, trying to determine where the fault lies. The worst part of this is that in this debugging process a lot of knowledge is gained by a single team member (such as that particular underlying functions appear to behave correctly) that is not properly shared (another member will have a problem and trace through the same code the next day).

Taking a pragmatic approach to coding may mean that you take longer to write the code, but it will be up and working (without memory leaks, overflows, logic bugs relating to error handling, etc) much more quickly than the hack and debug approach.

This is precisely why the paired programming approach works: one brain writing the code and the other brain checking it provides a much greater degree of certainty that the initial quality of code is good, and obvious coding and logic bugs won't be present.

Re:What is a "good" programmer?

[sjames]

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 transformation, the project is doomed.

The problem is, hard deadlines can only be set when the true scope of the work is determined. That can only be determined by making many of the fundamental design decisions for the project.

If the project is yet another x that does y, the time between specification and development of a timeline may be short. If the project is genuinely innovative ( as opposed to innovative according to marketing), a timeline that is anything but a polite fiction may not be determinable until 90% of the project is complete (and NO, I can not provide a timeline for that 90% or swear that it won't turn out we need to do 90.001%)

So, while a deadline need not lead to bad code, the in majority case where the deadline is a work of fiction that is arbitrarily begged, pestered, badgered, and tortured from the archetect prematurely, it certainly WILL lead to bad code.

Re:What is a "good" programmer?

[Twylite]

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?

[sjames]

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 progress. Never mind that the crap code will never fulfill the requirements and will take 3 times as long to stabilize (if it's even poissible without doing a 'stealth rewrite').

Commonly, that leads to spewing some bad code to get people off of the dev team's ass long enough to do it right. Que the PHB that 'promotes' your pre-alpha to wide beta behind your back. So, you'll do a stealth rewrite for the first revision. Queue a massive list of questionable bells and whistles and another magical deadline.

It's a variant on the tragedy of the commons. At every point, a properly run project is the fastest way, but bad code LOOKS more like progress to the customer and the PHB.

It's all about people...

[Dr. Bent]

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.

Re:It's all about people...

[duffbeer703]

Super programmers often hurt a team more than they help.

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...

[dmorin]

But how do you define "best people"? That's sort of the question, isn't it? Where's the magic set of interview questions that finds these people? Back up one step -- instead of trying to find people with X skillset, what *is* X skillset? Just coding? Communication? Management? Personality? Intuition?

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 economics and politics away from the engineers).

Re:It's all about people...

[e-Motion]

Super programmers often hurt a team more than they help.

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 are the _real_ super programmers.

Re:It's all about people...

[bokmann]

Martin Fowler makes a good argument in that article, but that doesn't mean it is true...

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 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.

Re:It's all about people...

[sjames]

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, Fowler implicitly acknowledges your point, he just doesn't go as far as to call it a measurement since it is a reletive value with no units and no agreed on definition.

Have to agree

[notamac]

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!)

Style doesn't solve everything

[Twylite]

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.

completely OT

[norkakn]

isn't it Janis not Jamis?

Re:completely OT

[dmorin]

"Jamis Joplin! Won't you buy me a color tv!" "You sing her weird songs, you know that?" -- daughter, then wife

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:completely OT

[Anonymous Coward]

Would you please change your sig to put "daughter" next to the first part? Right now, it looks like you eventually married your daughter or something - "daughter, then wife" ?

Yes

[aristus]

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.

Define good code

[Chemisor]

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.

Re:Define good code

[maximilln]

Most people just assume that if it has no horrible hacks, is formatted ok, and has some documentation, then it is good code

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

[titzandkunt]

Good code, in no particular order:

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

[bluGill]

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 they do...) mean that it is bad code, or just that they didn't give it time to understand.

I only know of one measure, get 5 other programmers to start from scratch to do the same thing. Not going to happen. Any other measure is going to fail in some way.

Re:Define good code

[dubl-u]

Good code, in no particular order:

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

[jibarito]

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.

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 the system.

2. Defining what is being asked to be built
I think it is simplistic to assume that the key to programming is either technical skill or people skills But I think the saying "there is no silver bullet" is quite approrpiate in this context. It's nice if you happen to be mystically talented to the point of mind-reading in determining what users will need in a system, but for normal people it is more likely that better code will come only when the requirements for the project are better defined, which may take several rounds of going back and asking for clarification on things -- even things that may seem obvious to you. Sometimes, though, you will need to be sensitive to what the management is leaning toward in terms of whose requests (and what technologies or methodologies) are higher priority, i.e., how you should be spending your time, and hopefully you can be asked to work on those projects more often.

3. Skill at modeling or abstracting
This may be considered a kind of technical skill, but in I think it is somewhat independent. People of all walks of life have the ability to distill things down to the important central core. I think this is indispensable in software development, especially the ability to do it quickly. There is just too much written information in the IT world to expect to read all the right books in order to learn everything. Don't get me wrong, there is a lot of reading involved, but you also have to be good at thinking on your feet.

4. Experience helps a lot
Being in the position to work on smaller projects, with a mentor, seems to me the ideal starting point, particularly if one can get into good habits quickly and learn a little about why they are good. Failing that, you have to make the best of what you learn, including trial and error. Again, the books have some of the information but they can't give you every answer. For better or worse, software development is the hardest of all worlds -- it demands high technical skills, high creative skills, high people skills, and high political skills. But it can help to learn as much as you can from each problem or project, and record what you learned so you can refer back to it later.

not their main job

[fred fleenblat]

It's probably more that the CSS stuff is just an annoyance to the developers and they just get enough CSS together to make their pages look halfway decent so they can get back to work on important stuff in Perl or C++ or something.

Critizing people's code will make you look great!

[FriedTurkey]

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.

Modern communication

[Brandybuck]

When I have to communicate with the rest of my programming team, I have to stay up late at night so I can catch them eating their morning breakfast in Bangalore.

Re:Critizing people's code will make you look grea

[e-Motion]

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.

You write for people, not computers!

[llopis]

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.

Re:You write for people, not computers!

[photon317]

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 asked to take over his code and maintain it, 9/10 times I would refactor and re-write large parts of it to suit me, because his code looks like unmaintainable trash to my brain. Same would be true if our roles were reversed.

Re:You write for people, not computers!

[Patrick May]

I can understand the output of another good programmer, but if I were asked to take over his code and maintain it, 9/10 times I would refactor and re-write large parts of it to suit me,

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 writing unmaintainable code nor rewriting working, tested code.

Patrick

Re:You write for people, not computers!

[photon317]

You're confusing a Good Programmer, and a Programmer Well-Suited to Corporate Software Development. You do understand the difference right?

It works at different levels

[Jare]

- 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.

Professional versus Script Kiddie vs Software Eng.

[TPoise]

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.

Keep developers apart

[Anonymous Coward]

One of the most productive and successful projects I've worked on was an embedded system where I was doing (mostly) software, and another engineer was doing (mostly) hardware. I worked "normal" business hours, in my office on the 23rd floor. He liked to work "night shift" in his hardware lab in the basement. Thus, we almost never saw each other, or had the opportunity to communicate directly.

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.

Group Dynamics

[Auxon]

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" results from group collaboration. This turns out not to be the case in many situations. Groups are often able to collectively come up with solutions to problems that are far better (or more accurate if there is an exact answer) than the best individual in the group.

The key ingredient seems to be (as analysis of research suggests) information diversity (as you find in a group that does not get its knowledge from many different sources, and limits the sharing of knowledge to the extent that everyone doesn't end up with the exact same information), and proper aggregation of solutions from the members of the group (i.e. a vote, or some other method of aggregation).

It is important, apparently, to ensure that all members of the group have input into discussions and debates, that polarization is avoided, dissention is never discouraged, and that decisions not be made in advance of discussion by leaders of the group.

It seems to me that teams that have one or two great developers end up deferring to the judgement of the "great" ones, to such a degree that such group dynamics as described above are not able to operate.

In a scenario where developers feel as if they are on equal footing, at least from the point of view of having a valid opinion, they are more likely to be able to discuss and dissent among themselves, encouraging a greater diversity of information.

So, often the aggregation of all information, including wrong information mixed in with correct information - which often balances the solution, by cancelling out error - ends up superior to any other individual solution.

"Poor Code" == Shipping Product

[coldtone]

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.

Re:"Poor Code" == Shipping Product

[kuom]

This is true, from a business point of view, building a working product quickly is much more profitable than building a maintainable, well designed product slowly.

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 throw out some old code and start from scratch.

All of these will cost you quite a bit of money.

On the other hand, if version 1.0 was well thought out, well documented and designed, you'll be able to crank out many many new versions quickly (profit!)

In the long run, it is probably better technologically and economically to design something good from the start.

Re:"Poor Code" == Shipping Product

[Anonymous Coward]

There is an unwritten rule that the naming of variables in code need to 'look professional', so they are made as small and undescriptive as possible.

A lot of traditional unix code has cryptic names for variables as if humans didnt need vowels, perhaps it suited the 80 column printer better.

Communicate more, code less.

[pragma_x]

If you were to write a large-scale system, you wouldn't be that suprised to find that a significant portion of time and space is dedicated to allowing various components to communicate. The same applies to organizations of people, not just machines and software objects. Software teams themselves must be as oriented toward conveying information horizontally (between one another) as they are vertically (between the mind and the software being created).

In essence, you must dedicate a portion of a team's time to communication so they may coordinate and accomplish the same task under the same guidelines and goals. The tricky part is knowing how much is enough and how much is too little. Its more complicated than abolishing weekly status meetings in favor of more brainstorming sessions, or requiring x% of code to be comments and documentation.

Quite possibly the best example of what is required of a quality team, and how communication needs scale along with team sizes, is the Capability Maturity Model.

http://www.sei.cmu.edu/cmm/cmm.html

The CMM attempts to cover the spectrum of software team types (level 1 to 5) as a sliding scale from start-up to an "ideal" controlled process environment. This is not for everybody, and is certainly not a quick-fix for any company. Instead it drives home the concept of strong communication first, with the end product being software. It's also not without its critics.

http://www.satisfice.com/articles/cmm.htm

Another decent process, that has been getting a lot less press lately is the Rational Unified Process. RUP, at its core, attempts to establish a well defined communication pipeline for creating software from start to finish. It also attempts to create well defined roles in that process that map easily onto existing roles in most software shops. Ultimately, using RUP feels a lot like 'programming the workplace' itself which can make it a cinch to grasp for developers.

http://ootips.org/rup.html

RUP too, has some flaws. It foists UML down the reader's throat, as virtually every aspect of the process is documented in UML as well as plain text. This is great for developers and PM's but tends to fall apart once other non-developers are given raw RUP documentation (QA staff, PHB's etc). One needs to be aware that RUP is an abstraction of a process, not the actual process you define and use.

Regardless of what methodology you use, be it a pre-packaged one or something home-grown, your software team must learn to communicate everything project related so they behave as a single cohesive system.

Re:Critizing people's code will make you look grea

[Anonymous Coward]

i've seen this move before, and there really is no defense...

either you can come back on the offensive and explain the poor buisness rules that led to 10 special cases of spaghetti code, and come off like an ass. OR you can just ignore it and more often than not the manager will believe anything they are told.

lose:lose situation.

performance

[jeisc]

Good code runs fast.
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.

Source is similar to airplanes?

[Branko]

Airplane designers say that airplane should be beautiful in order to fly well. The same holds for source code: it must be beautiful to run well. Of course, "beauty" does not only mean "nice formatting". This is the consequence of programming still being largely an art, instead of strictly defined engineering discipline.

Re:Have to disagree

[Glonoinha]

I have to disagree.
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 ... than polite code using proper naming conventions, an xml driven configuration, following proper OO techniques - but didn't write a single line of in-code documentation.

My reasoning is, of course, that someone that has to accurately describe what his code does has to write code that he can accurately describe, and when the next guy goes to tweak it at least he can read an English description of intent, design, assumptions, and expectations - and also the original guy's name if he included it in the dox.

Bad code with good documentation becomes good code, and undocumented good code is effectively bad code.

Poor code

[Anonymous Coward]

Indian developers write the sloppiest code.