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."
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
You also need a lead developer who has the last word. Otherwise, forget about it.
Everything I write is lies, read between the lines.
I do not disagree. But when processes are so amateurish, as in the anecdotes provided in the fine article, then it always will devolve to people over processes in a way that is not enlightening. One of the main purposes of every flavor of formalized process is to enforce some minimum level of communication.
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
Is it just me, or is the interface the job of the architect, not the code monkey?
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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.