Slashdot Mirror
When Smart Developers Generate Crappy Code
itwbennett writes "If you've ever worked on a team you can probably recall a time when, as a group, you produced work that was not as good as any one of you could have done on your own. Sarah Mei had this sort of sub-par teamwork experience, which she shared in her session at the O'Reilly Fluent Conference this week. Mei 'spoke about a time she worked on a team with really expert developers. Every one of them was someone whom you'd admire, who had previous written code that you and I would boast to have created. Yet, these smart people created modules that didn't talk to each other. And its quality was, to be kind, on the rotten side.' It's not an uncommon story, but why and how does it happen? The answer, says Mei, is that code quality 'is defined by its patterns of dependencies,' not all of which have equal weight. And, as it turns out, team communication is the heaviest dependency of all."
people over processes; how deep.
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
Isn't this exactly what MVP, MVC, etc... are meant for?
At that point it doesn't matter how crappy your code is, all it is is isolated to a single portion of a layer with inputs and outputs and relatively modularized as a result in regards to similar models.
if it were then projects like Linux would have collapsed a very long time ago.
My karma is not a Chameleon.
they want to sit in a corner far from other people coding in silence
they hate meetings and talking to people
so what you get is code that only talks to itself
My team did not talk to each other and everyone went off and did their own thing. Then when it came time for integration it all went to hell...
Just because they name drop does mean they are great coders, only that they are great at self promotion. Who's to say that some silent but really competent coder wasn't responsible for the code they take credit for? I think what you saw was not "great coders can't work together," but instead, "great projects have many unsung heroes."
The only thing worse than a Democrat is a Republican.
Good code, it seems to me, isn't so much a reflection of someone's skill level as a developer in-so-much as it is a reflection of how much they cared about that particular project. Designing and architecting takes time. If you're a good dev but all you're aiming to do is write something that gets the job done here and now without regard for maintainability or scalability or anything... well that's how you get bad code. It seems to me.
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''
``It will take one year,'' said the master promptly.
``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''
The master programmer frowned. ``In that case, it will take two years.''
``And what if I assign a hundred programmers to it?''
The master programmer shrugged. ``Then the design will never be completed,'' he said.
-The Tao of Programming
While those things she list are important, it sounds like this woman actually worked in an environment where the low level architecture wasn't controlled or defined by someone with any experience with long term maintenance.
There are a lot of really good coders, but the skills required to properly define high level interfaces between subsystems is _NOT_ something all of them posses, even though the vast majority either think they do, or fail to understand the importance of defining project API's for isolation.
This isn't to say that people with the term "architect" in their titles get it any better. In many cases they tend to get it wrong because they are too decoupled from the actual coding portions.
Its also something that is nearly impossible to bolt on after the fact. The last thing your project manager wants to hear, is that 3/4 of the project needs to be rewritten (or refactored to the point its not recognizable) because of some stupid problem with component isolation.
So, how to you identify bad architecture?
If your team can't isolate and troubleshoot the vast majority of bugs quickly (less than a hour).
If the common answer to features, is that some large portion of the system needs to be rewritten or refactored.
If the system is brittle, and errors aren't contained to smaller subsystems.
If requirements changes tend to touch a lot of different system components.
The list goes on, but I firmly believe that bad architecture is the problem in a lot of cases where people claim crappy code, or failures because the product is buggy or is not agile enough to respond to market needs.
One of the most important things when it comes to avoiding a group creating a mess is to have collective agreement on the architecture and design and the divisions and interfaces between components. Everybody doesn't have to agree that this way's the best way, but they have to agree that it's acceptable and they'll write to it. This goes both ways: you have to acknowledge that you'll follow the design even when you don't agree with it, and you also have to acknowledge that the other guy (who isn't getting his way) has valid points even though you're doing it your way instead of his.
NB: the above is why my mantra is "I am not a rock star. I am a professional.". I'll argue vehemently for what I think is the best way to do things, but in the end I need to write code that fits well with the rest of the system even if that code isn't technically "the best way".
But WHY does it take longer when you add more people? The answer is "communication channels".
And they follow the formula of (n*(n-1))/2
So 1 person has 0 communication channels to maintain.
3 people have 3 channels.
5 people have 10 channels.
And if the EXACT same message is not present upon every one of those channels then problems start.
So the key is NOT to focus on 10 communication channels between 5 people but to focus on reducing the scope as quickly as possible so that fewer people are needed. And the means that your best programmers can spend more of their time programming and less on maintaining communication channels.
No, you are totally wrong, usually people don't bother communicating, so you don't lose a lot of time on communication.
It takes longer because of Ringelmann's effect, and this had been measured in 1914, by measuring efforts.
Here is the original article in french: http://gallica.bnf.fr/ark:/12148/bpt6k54409695.image.f14
When you have 1 guy, he works at 100%, but when you add 1 guy, you get 93% of their combined force.
Here is the table from 1 to 8:
1 => 100%
2 => 93%
3 => 85%
4 => 77%
5 => 70%
6 => 63%
7 => 56%
8 => 49%
With 8 people, you get the results of 4 people !
In fact, when you add people in a team, everybody reduces his level to the supposed level of the group.
If I'm alone, I think I'm the best, so I'll work at my best level.
If there is another guy, I'll work according to our common level, so I'll reduce my effort.
When you have a team, the team works at the lowest common level.
You can also see that when people walk in groups, they walk together at the slowest speed.