Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

When Smart Developers Generate Crappy Code

Soulskill posted about a year ago | from the my-code-works-fine-so-it-must-be-your-fault dept.

Programming 195

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

Sorry! There are no comments related to the filter you selected.

oh jeez; let's all discover agile again (4, Funny)

rtfa-troll (1340807) | about a year ago | (#43876995)

people over processes; how deep.

Re:oh jeez; let's all discover agile again (1, Troll)

sycodon (149926) | about a year ago | (#43877085)

Or maybe Sarah isn't as smart as she thinks she is.

Re:oh jeez; let's all discover agile again (-1, Troll)

Anonymous Coward | about a year ago | (#43877305)

She's a female software dev. Nuff said in my experience.

Re:oh jeez; let's all discover agile again (-1)

Anonymous Coward | about a year ago | (#43877597)

Fuck off.

Re:oh jeez; let's all discover agile again (-1)

Anonymous Coward | about a year ago | (#43877601)

Probably a chinger too.

Re:oh jeez; let's all discover agile again (0)

Anonymous Coward | about a year ago | (#43878265)

You should do well on this test [funny.co.uk] .

Re:oh jeez; let's all discover agile again (1)

Esther Schindler (16185) | about a year ago | (#43878829)

I hate to think that other developers have to work with you.

Re:oh jeez; let's all discover agile again (0)

Anonymous Coward | about a year ago | (#43877361)

Yet, these smart people created modules that didn't talk to each other.

The less able programmers were creating programs that would try to talk to each other and discovering that they could not. The smart people people are smart for getting the modules they are asked to do done.

Re:oh jeez; let's all discover agile again (3, Insightful)

Marxist Hacker 42 (638312) | about a year ago | (#43877883)

Is it just me, or is the interface the job of the architect, not the code monkey?

Re:oh jeez; let's all discover agile again (1)

Penguinisto (415985) | about a year ago | (#43878225)

You're both right.

It's one thing to have a group of top-end devs in one room. It's another to get them to play nice with each other. Not even talking about egos, per se... the ability to drop assumptions and actually start asking the other devs what they're up to is something that requires more than just knowing syntax and process to the nth degree.

Re:oh jeez; let's all discover agile again (4, Funny)

Anonymous Coward | about a year ago | (#43877147)

Fix everything by having a 5 minute standup meeting for two hours every morning and then every two weeks drop everything and build a deliverable that isn't finished yet.

Re:oh jeez; let's all discover agile again (4, Insightful)

ls671 (1122017) | about a year ago | (#43877341)

You also need a lead developer who has the last word. Otherwise, forget about it.

Re:oh jeez; let's all discover agile again (1)

Anonymous Coward | about a year ago | (#43877831)

Don't forget the project manager to build the spreadsheets that everyone has to update hourly.

Re:oh jeez; let's all discover agile again (1)

Penguinisto (415985) | about a year ago | (#43878245)

Top it off with giving marketing the ability to speak in those standup meetings, and you have one hell of a recipe for fail...

Re:oh jeez; let's all discover agile again (1)

Anonymous Coward | about a year ago | (#43878083)

...while attempting to simultaneously stay CMMI Level 5 complaint, so you have day-long Process Improvement Process Improvement Process meetings every month, too...

Re:oh jeez; let's all discover agile again (4, Funny)

0racle (667029) | about a year ago | (#43877157)

I wonder how many meetings we'll have this time around.

Re:oh jeez; let's all discover agile again (5, Funny)

Darinbob (1142669) | about a year ago | (#43877771)

8am daily standup meetings to discuss what you did the day before and what your obstructions are to prevent work getting done.
12pm daily meetings to discuss what you've accomplished in the last 4 hours.
2pm daily meetings with project owners to explaining that you're following industry standard processes so just remain patient.
5pm daily meetings to plan what work you will get accomplished overnight before the 8am meeting.

Meetings will continue until morale improves.

Re:oh jeez; let's all discover agile again (3, Insightful)

Comrade Ogilvy (1719488) | about a year ago | (#43877373)

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.

Re:oh jeez; let's all discover agile again (2)

khasim (1285) | about a year ago | (#43877877)

But when processes are so amateurish, as in the anecdotes provided in the fine article, ...

Emphasis on that. Crappy data leads to crappy conclusions. And her "data" is extremely crappy.

From TFA:

In another team of seven or eight people, developers were encouraged to do whatever they felt like ... which turned out to include, "Have every developer write code in a different language."

I count at least two WTF's in there. You wouldn't build cars engineered around blind people would you?

Also from TFA:

The best of those indicators? The one that most commonly predicts quality results? Good team communication.

So a baseball team or a football team with good communication should be able to crank out "quality" code. Wrong. And that gets back to the crappy examples she uses. Just because communication CAN be the biggest problem in a given situation does not mean that communication IS the biggest problem for all situations.

Seriously, what programmer would not ask which language was being used? Or not have MORE questions when the answer was "everyone uses whatever they want to".

Oh oh, Cumbaya coming... (0)

Tablizer (95088) | about a year ago | (#43877015)

Just don't force me to hug the other coders. I will NOT hug coders!

Re:Oh oh, Cumbaya coming... (0)

Anonymous Coward | about a year ago | (#43878041)

I've met a couple of coders I'd like to hug (I married one of them) - but they are few and far between.

Duh (1)

Sparticus789 (2625955) | about a year ago | (#43877017)

I learned this from Captain Planet as a kid. Why does Sarah Mei just have to repeat the lessons of Earth, Fire, Wind, Water, and Heart?

Coding Architecture Models (4, Insightful)

Synerg1y (2169962) | about a year ago | (#43877027)

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.

Re:Coding Architecture Models (3, Interesting)

hondo77 (324058) | about a year ago | (#43877227)

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.

You're assuming that people actually put in that separation all the time. Just because you are using an MVC framework doesn't mean things are separated like they should be. Just like declaring something with "class" doesn't automatically make it (good) OO.

Re:Coding Architecture Models (1)

Synerg1y (2169962) | about a year ago | (#43877381)

Everything depends on implementation, but sticking to an architecture is meant to make implementing the various components a lot easier. The framework is actually supposed to enforce the practices, so while its possible to deviate and not follow the pattern, ...I guess its really not that hard to make those choices, especially for expert programmers (ex. does it require behind the scenes computation? model!).

Re:Coding Architecture Models (1)

Anonymous Coward | about a year ago | (#43877819)

> The framework is actually supposed to enforce the practices,

That's a backwards thought.

Re:Coding Architecture Models (0)

Anonymous Coward | about a year ago | (#43878113)

Totally agree.

My recent experience is that "architecture" means picking a cool framework, with no thought given to how well it matches the system. With contractors you can expect something really new, not really stable, but that's gonna look real good on the CV. "Design" means that whatever class you'd come up with after thinking about the problem for 5s has an interface. Bonus points if you can put some required counter in a different class, that way you have 2 implementing classes, for a change, plus a multiplexer, all configured with spring, at the low-low price of transforming 3 lines of code into 500.

As for enforcing the practices, keep dreaming... You have your cool framework, hibernate to "abstract" the database (better assume anything about null and empty string, otherwise the "abstraction" is going to leak real fast and real hard), and nifty json restful web-services, and suddenly your on-the-wire protocol has a strong dependency on the database schema. How's that for "architecture"?

Re:Coding Architecture Models (5, Informative)

i kan reed (749298) | about a year ago | (#43877437)

No, and I have co-workers who I consider quite skilled, and none of them seem to know when to define an interface. Guys, enums and switches aren't replacements for subclasses.

Re:Coding Architecture Models (1)

hondo77 (324058) | about a year ago | (#43877467)

+1 Informative

Skilled in what exactly? (2)

PCK (4192) | about a year ago | (#43878231)

Because it certainly does n't sound like it is in object orientated program design. Being able to code is just one part of being a skilled programer, being a "rockstar" style coder may seem impressive but banging out pages of code at a time is never a good sign and I say this as someone who spent a good five years working this way.

It is only when you have to maintain your own code for years that you start to step back and think more because at the end of the day you can not code your way out of trouble, well you can but the result is never pretty or maintainable.

Personally I find that I spend around 25% thinking, 25% coding, 25% testing and 25% documenting any one problem. The 50% spent testing and documenting is n't fun by anymeans but it's a necessary discipline. It's all about taming your inner coder and I think this is what the majority of these frameworks do indirectly by creating road blocks so that you have to hit the breaks every so often.

Re:Coding Architecture Models (1)

TheRealMindChild (743925) | about a year ago | (#43878257)

Neither are templates/generics, but these new C++/Java/C# folks fight to the death to avoid class inheritence

Re:Coding Architecture Models (0)

Anonymous Coward | about a year ago | (#43878467)

Inheritance is how OO is supposed to work.

Interfaces are great when you're trying to define how a third-party object should interact with your code. But if you're defining interfaces for yourself, you're probably doing it wrong. (Note the "probably" in there.) A base class with virtual methods (or enforced virtual ones, if your language supports them, like C#'s "abstract" classes and methods) is almost always preferable.

Interfaces really shine when they represent, not objects or traits of an object, but actions an object can take. Then a properly coded object can implement its variation on that action as an interface implementation, and anything expecting something that implements that interface knows that that object can do that action. That's how interfaces should be used. I've seen way too many programmers miss the point of interfaces entirely and use them in ways that just make things difficult.

I can count on the fingers of one hand the number of times I've used interfaces to any useful end in C#. Abstract classes and virtual or abstract methods are far more useful, and doubly so when you need a factory. A static method on an abstract class to generate and return an instance of a derived class is just brain-dead easy. Now throw generics in there and you have and amazing amount of flexibility and code re-use. But only if you do it right and aren't an incompetent boob that doesn't know what these things all do.

I happen to code a lot of objects that don't implement action patterns, it seems...

Re:Coding Architecture Models (2)

pclminion (145572) | about a year ago | (#43878407)

Interfaces often make sense, but you can tell when somebody has gone interface-crazy when it is no longer possible, by simply looking at the source code, to determine what actually is going to happen -- instead, you're reduced to tracing the code in a debugger to see what actually goes on.

Re:Coding Architecture Models (1)

VortexCortex (1117377) | about a year ago | (#43878501)

> enums and switches
> not using a function pointer.
ISHYGD care about performance.

Re:Coding Architecture Models (2)

VortexCortex (1117377) | about a year ago | (#43878439)

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.

You're assuming that people actually put in that separation all the time. Just because you are using an MVC framework doesn't mean things are separated like they should be. Just like declaring something with "class" doesn't automatically make it (good) OO.

Furthermore, not everything can be separated into those classifications. Take your average "Web2.0" website for example: The components of the MVC are spread out across HTML CSS JS and back end code. Sometimes it makes sense to put some controls in the view. Blind adherence to paradigms as a core business strategy can lead to unsynergistic blue-sky thinking that leaves the best and brightest ideas out of the loop. The best game plan is to go the extra mile to make sure that movers and shakers can interface with your knowledge economy -- That's the fast track to empowering partnerships that stretch the envelope and benefit the bottom line results.

P.S. You're welcome. Consider it payment in kind for helping me win design pattern bingo.

Re:Coding Architecture Models (1)

gl4ss (559668) | about a year ago | (#43878555)

if nothing is dependent on any other module/progam, then the whole program does nothing.

of course if it's all designed in advance so that the interfaces are set to stone and so forth no problem.. but then the actual implementation is trivial and the actual "development" with all these same problems happened on the earlier stage. I'd say the problem comes when things are cut to pieces too much in advance for the sake of teamwork to begin earlier - and I go further and claim that companies do this so that they can get bigger amount of people on the case earlier instead of doing the thing that makes sense, the arcitechts are going to be under severe pressure if already on day 1 they're supposed to be providing something relevant to do for a hundred - or just 5 - guys.

Re:Coding Architecture Models (2)

WaywardGeek (1480513) | about a year ago | (#43877443)

Code architecture is key, as is a common coding methodology among the team. Brilliant coders often are loners, and if you put them on a team, each may do what they normally do and do their own thing. You'll have a program written in several different languages, and an integration nightmare.

Here's an integration nightmare that continues to this day, thanks to lame computer language design. To reduce integration problems, a common architecture in EDA is to read a design into a common set of in-memory data structures, and to split up the extensive process of automating design implementation into several "tools". Each tool runs in sequence, moving the process forward, for example we run digital high level synthesis, then lower level technology mapping, placement, and then routing. They read from those common data structures, and write back to them. I have never seen a group succeed who did not use this architecture. The problem is how do you extend the objects in the common data structures so your tool can manipulate them? In C++, we use inheritance to extend the functionality of a class, but these shared common objects have already been instantiated by the time your tool runs, and they don't have your extensions. You can still inherit from there classes, but you'll have to copy all the objects to new objects of your subclasses to be able to use them, doubling the memory required. Alternatively, you could have a void pointer on each object in memory and use run-time hacks to cross-link them to your new extension objects, and throughout your code you wind up going back and forth through the void pointer. Various better systems are often employed, but they're all hacks to work around limitations in languages like C++, Java, D, and C#. If a team doesn't agree beforehand just how they are going to share objects and extend them, the effort is doomed before it begins.

Re:Coding Architecture Models (1)

stanlyb (1839382) | about a year ago | (#43877623)

GraphTalk. The only real Object Oriented Data Base, ever, created. And it even works.

Re:Coding Architecture Models (2)

mbkennel (97636) | about a year ago | (#43877715)

"You can still inherit from there classes, but you'll have to copy all the objects to new objects of your subclasses to be able to use them, doubling the memory required. "

You might try a shared_ptr instead so you may have less need to copy the objects instead of a pointer to them.

Or Lisp.

Re:Coding Architecture Models (1)

alienzed (732782) | about a year ago | (#43878435)

In theory, sure. But we are not robots and in the eyes of humans there are no absolutes. Sometimes code is put in the wrong place and guess what? It doesn't always matter...

Re:Coding Architecture Models (1)

edelbrp (62429) | about a year ago | (#43878723)

No. The first big MVC project I worked on had a project manager with that assumption. What happened is the Models were sparse because those writing them didn't anticipate everything needed by the Controllers and Views. So, a lot of what should have been in the Models was in the Controllers. Worse, the Views ended up having a lot of code that should have been in the Controllers and Models. Since those early days I/we've been very conscious about pushing as much upstream (V -> C -> M) as is reasonable. It seems to work better to divide the workload by app component so code (ideally) gets put in the right place as it is written.

Communication isn't the problem... (3, Insightful)

Stumbles (602007) | about a year ago | (#43877061)

if it were then projects like Linux would have collapsed a very long time ago.

Re:Communication isn't the problem... (0)

Anonymous Coward | about a year ago | (#43877259)

I think it's inter-person compatibility. In projects like Linux when the level of incompatibility between developers exceeds a certain limit a fork or branch happens.

Re:Communication isn't the problem... (1)

Anonymous Coward | about a year ago | (#43877505)

Counter-point: Linux (kernel) hasn't forked significantly yet, despite Jeff V. Merkey's threats, and Linus certainly has incompatibility with more than a few devs.

Counter-counter-point: One of those incompatibilities result in the kernel folks forking the close-to-the-kernel udev, creating projects like eudev [github.com] and mdev [github.com] .

Re:Communication isn't the problem... (1)

Stumbles (602007) | about a year ago | (#43878079)

I think the potential forking aspect has little to do with TFA authors thoughts about code quality. By all rights a small group as she mentions should have no problem and yet they did; why was that? Linux from a developer numbers aspect deals with how many, a thousand or so contributors? I am not convinced it was a communication problem. Well perhaps it was just not in the way she thinks. Like you mentioned, yeah Linus can land on a developer like a sledgehammer and think that tends to keep his "cats" on their toes. In my view such "gruffness" in a "standard software house" or project and the project manager would not be in such a position very long; to much political crap goes on.

Re:Communication isn't the problem... (1)

maccodemonkey (1438585) | about a year ago | (#43877423)

if it were then projects like Linux would have collapsed a very long time ago.

To be fair, just because the people working on Linux have good (well, from what I've seen, decent) communication skills doesn't mean any random developer will.

Working on a solo project is much different than working on a group project.

Re:Communication isn't the problem... (1)

Stumbles (602007) | about a year ago | (#43877999)

Agreed on the differences of working solo versus a group project. They certainly do have differing dynamics and just because a developer might be a hot shot when working alone does not always translate to a group environment. I think in the case of Linux development many of the developers work in a solo/collaborative way that most other projects have been unable to duplicate on the same scale. Maybe it has something to do with openness of the code or the at times hardnosed way Linus goes about managing it all, I don't know. Maybe TFA authors missing the real problem; just because you can write shit hot code does not mean it makes you a good project manager.

Re:Communication isn't the problem... (2)

Darinbob (1142669) | about a year ago | (#43877845)

Linux has been collapsing for nearly two decades now. The trick is to borrow ideas from judo so that when you get stuff done while falling.

I think what's really happening is that Linux isn't aiming for perfect or best. It has something practical it wants to get done and there aren't long arguments over the best architecture to use. Compare to GNU Herd which had very lofty idealistic goals and lots of debate over the best says to proceed. Ultimately having something ugly that does the job will win over something beautiful that is unfinished.

the basement dwellers hate people (5, Insightful)

alen (225700) | about a year ago | (#43877067)

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

Re:the basement dwellers hate people (5, Funny)

Anonymous Coward | about a year ago | (#43877195)

they want to sit in a corner far from other people coding in silence they hate meetings and talking to people

And with good reason. Other people are annoying and I am immensely interesting to me.

Dream job, once upon a time (1)

Dareth (47614) | about a year ago | (#43877499)

My dream job once upon a time would have been coding on something like VT220, green font on black background, terminal in a small office/closet.

Somehow my days are spent interacting with the people necessary to get the job done. Oddly enough, I actually enjoy it.

Re:Dream job, once upon a time (1)

Darinbob (1142669) | about a year ago | (#43877887)

Yes and no. Interacting with others is fine. However it breaks down when it becomes "you must stop what you're doing and interact with them NOW".

Re:the basement dwellers hate people (1)

Tablizer (95088) | about a year ago | (#43878805)

so what you get is code that only talks to itself

That explains all the "self" references such as "self.x = self.foo()" etc. Social programmers would instead code something like "share.x = share.foo()". Maybe if I use more global variables I'll become social. And more Goto's may help me play basketball. Who says coders can't jump!

translation (3, Informative)

Anonymous Coward | about a year ago | (#43877071)

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

Re:translation (1)

Anonymous Coward | about a year ago | (#43877641)

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

I tried something like that during my student days. We made a plan and each coded one part. When it should be put together it turned out that we had:
1: one guy didn't do anything at all
2: one guy who passed strings for everything. Didn't return a int as agreed upon, but instead a string containing the int and stuff like that. He argued "what's the difference?"
3: me who made my part actually work.

Our combined grade was failed (go figure), which is the story of the only time I failed anything regarding programming. I graduated while the other two dropped out within half a year after that incident.

Re:translation (2)

Grishnakh (216268) | about a year ago | (#43878703)

This should be a good lesson about how group projects usually work in college; it's how all the ones I had worked out. One person does all the work, while the other person(s) claim credit and gets an equal grade even though they didn't do anything, or their contribution was very minor.

IMO, they shouldn't have group projects in college classes at all, because they always wind up like this.

load of bs (0)

Anonymous Coward | about a year ago | (#43877089)

this load of bs (register). They are likely had crappy design of inter-module interfaces, that's it.

That why the Indians and Chinese are so good? (0)

Anonymous Coward | about a year ago | (#43877125)

--In another team of seven or eight people, developers were encouraged to do whatever they felt like ... which turned out to include, "Have every developer write code in a different language."

Wait what?

Funny how programmers gripe about eachothers code. (1)

Anonymous Coward | about a year ago | (#43877153)

I find it funny about how programmers gripe about each others code. Often it is mainly a gripe about some intangible such as style or failure to use some feature of a language or even choice of language. This often degenerates into some flame war between sides of these petty issues while real issues the end users care about such as "does it work?", "how long do I have to wait for it to do its thing?", and "do I need to buy a whole new machine to run it?" are ignored.

Re:Funny how programmers gripe about eachothers co (0)

Anonymous Coward | about a year ago | (#43877263)

You're assuming programmers care about the users. Remember Milton? :)

Re:Funny how programmers gripe about eachothers co (0)

Anonymous Coward | about a year ago | (#43877919)

This often degenerates into some flame war between sides of these petty issues while real issues the end users care about such as "does it work?", "how long do I have to wait for it to do its thing?", and "do I need to buy a whole new machine to run it?" are ignored.

No it doesn't

Formal meetings and formal processes (1)

EmperorOfCanada (1332175) | about a year ago | (#43877285)

I have been on teams where someone pulled some process out of their ass and proceeded to turn the whole project into another thing that regularly comes out of asses.

This is not to say formal processes and procedures are a problem just that bad ones are.

Sometimes they come from the heads of stupid people and well that can be understood. But often they come out of the heads of stupid evil people. They are too stupid to actually contribute so they come up with rules that they can then enforce to make other productive people look really bad. They can then write up reports that document just how much everyone around them sucks. "I was doing a code review and found 280 instances where your code was out of spec" (this is because their coding standard required two spaces before and after the == and they weren't there 140 times. "I wrote you up for not using the proper commenting system." "I wrote you up for not coming to the team building meeting scheduled for Saturday at my house." "I wrote you up for handing in an improperly formatted resignation letter."

I am not talking about bad managers, no no no, that is a whole other post, in the above I am talking about a co-worker who thinks that they can take power by quoting specs and standards that nobody else agreed to and they have no authority to create. I worked with a programmer who took an agile programming seminar and came back with binder after binder about agile programming. Whatever the heck they taught him wasn't agile. It was sclerotic programming easily requiring each programmer to generate at least 12 separate process related documents a day. I had only worked at the company a week and went into the owners and said that if they implemented this system that productivity would drop to around 10%. They said that I should be flexible and give it a try. I had received a counter offer to a job I had turned down the week before so I took that job the next day. The company died a year or so later(for mostly fraud related reasons) and the lawsuits among investors continue to this day.

Re:Formal meetings and formal processes (0)

Anonymous Coward | about a year ago | (#43877513)

I have been on teams where someone pulled some process out of their ass and proceeded to turn the whole project into another thing that regularly comes out of asses.

Salami code?

gotta have class (0)

Anonymous Coward | about a year ago | (#43877321)

public functions should be bulletproof. you can be as sloppy as you want with private functions. don't forget error handling as well.

who cares about quality (0)

Anonymous Coward | about a year ago | (#43877337)

Yet another developer who says the quality was poor, who cares in a business domain, does it work and can you sell it. That model has worked for Microsoft so who cares what some developer thinks.

I work in groups so it happens faster (1)

D1G1T (1136467) | about a year ago | (#43877359)

You get a group of 10 together because you have a 400 man-hour project due in a week, not to make your code better.

Re:I work in groups so it happens faster (3, Insightful)

Anonymous Coward | about a year ago | (#43877487)

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

Re:I work in groups so it happens faster (4, Insightful)

khasim (1285) | about a year ago | (#43878143)

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.

Re:I work in groups so it happens faster (1)

WrecklessSandwich (1000139) | about a year ago | (#43878639)

Well, the 1 person does need a communication channel to their rubber duck.

A post I made in another story reflects this well (0)

Anonymous Coward | about a year ago | (#43877365)

This [slashdot.org] post I made in another story touches on some points in this article. I completely agree that communication is the #1 issue. For software to talk to each other, humans need to talk to each other. This is the important problem that management or project leads need to solve.

Re: sub-par teamwork (1)

fahrbot-bot (874524) | about a year ago | (#43877369)

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

Wow, Sarah Mei has worked with Congress?

Re: sub-par teamwork (0)

Anonymous Coward | about a year ago | (#43877453)

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

Wow, Sarah Mei has worked with Congress?

Sub par, not hopelessly broken.

Nobody saw that coming... (1)

mooingyak (720677) | about a year ago | (#43877433)

And, as it turns out, team communication is the heaviest dependency of all.

That's pure brilliance. Groundbreaking stuff.

Real developers don't "generate" code... (1)

raburton (1281780) | about a year ago | (#43877441)

...they write it. Clicking a button to convert your architect's UML to Java isn't the same. Perhaps that's the problem here, but I didn't bother to RTFA because it didn't sound very interesting.

Re:Real developers don't "generate" code... (0)

Anonymous Coward | about a year ago | (#43878453)

...they write it.

Please don't propagate the ignorant notion that software development is just typing. Developers do more than "write" code.

Who says they were great coders? (3, Interesting)

Princeofcups (150855) | about a year ago | (#43877445)

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

EGO, more than communication. (2)

CaptnCrud (938493) | about a year ago | (#43877451)

EGO, EGO, EGO. Every time I have seen this, at its heart, its ego. The just plain stupid notion that: "im the smartest person in the room, I dont need to confer with anyone cause im so good". I would rather work with 6 humble jr. dev's then 6 senior meglomaniacs any day of the week and twice on sunday. Sure the code quality is also going to be suspect but at least, if say a rewrite of a module is needed, people are willing to just do it rather than bitch about why its the other modules part because there work is just that good.

maybe they just don't care about this project (4, Insightful)

TerraFrost (611855) | about a year ago | (#43877461)

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.

Re:maybe they just don't care about this project (1)

CaptnCrud (938493) | about a year ago | (#43877583)

I agree, but that's under optimal situations, life is not always optimal. Doing things "right" is not always the best solution, as horrible as that sounds.

Common problem (0)

Anonymous Coward | about a year ago | (#43877551)

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.

Haven't we all been there? Earlier today I had an experience like that with my own code. Luckily I haven't committed it yet and due to AC posting nobody will ever know how poorly I started compared to how well I can make it :P
However it's still an improvement to the existing code. It abuse resources big time and it happens to be written by a guy who is against me changing anything because "it might cause a slowdown". Go figure.

I think a major part of the problem is that nobody makes the perfect solution for everything. There will always be something where somebody can figure out a better way to do it. When several people look at the same problem, the part which could be improved will never be the same part and they all go "that part is poorly written. I could have done better".

Define good code: (1)

Anonymous Coward | about a year ago | (#43877579)

1. Good as in thorough
2. Good as in clever
3. Good as in quickly developed
etc.

Multiple programmers working towards different definitions of good will likely result in a whole project that is less than the sum of its parts.

Simple formula for code quality (1)

caywen (942955) | about a year ago | (#43877595)

code_quality = time * talent * experience * just_dont_care_factor

If you find code_quality nearing 0, that often means they just didn't care. [youtube.com]

So it is like Office Space (1)

Kingkaid (2751527) | about a year ago | (#43877613)

Apparently being "a people person" is important in the industry :)

Conway's Law (0)

Anonymous Coward | about a year ago | (#43877617)

It states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations".

Excellent *individual* programmers (2)

msobkow (48369) | about a year ago | (#43877705)

They may have been excellent individual programmers capable of producing works of art on their own, but the mindset for working in a team environment is completely different from that required for individual project work.

However, I blame not the developers, but the project management team for failing to realize that even the brightest people in the world need to be organized and have to structure their code properly to be effective. Far too often management takes the attitude that if they just hire "the best" and let them loose, miracles will happen.

Well, they don't.

In fact there is an entire book written about such management mistakes, in particular the fact that the more people you add to a project, the more effort and time it takes in total to complete. A little known text called "The Mythical Man-Month."

Perhaps you've heard of it?

If you haven't, you definitely need to read it.

Same reason "All-Star" teams suck (1)

swb (14022) | about a year ago | (#43877861)

You can get a bunch of guys that are really good on their own teams all together on the same team and end up with a team that's worse than the "lesser" teams they came from.

Sports history is littered with this phenomenon.

Every team I've worked on gives no shit about comm (0)

Anonymous Coward | about a year ago | (#43877747)

Every team I've worked on gives no shit about communication. And I run myself ragged trying to keep up with fragmented docs, fragmented knowledge, utter laziness... Most know when something needs documented, but they don't do it. Information is scattered all over the fucking place. The employees with the experience don't care. I have to train a new guy and he's like, "wtf?!" because there is no consistency. Management gives no fuck.

Every place and every project is like this in my experience. My experience has led me to believe that all projects are like this. So what I read here is no surprise. Am I jaded or something? Have I just been on the wrong projects?

Expert developers know what actually matters (1)

Anonymous Coward | about a year ago | (#43877767)

Expert developers know when it is appropriate to cut corners and not waste time on structures that don't help the end game. Expert developers know that the end game is something appropriate not something perfect.

let me guess (-1, Flamebait)

Velex (120469) | about a year ago | (#43877769)

Let me guess. This means that we need more womyn-born-womyn in software development ASAP because, as we all know, despite any personal experiences otherwise, womyn-born-womyn are all better communicators than any man or trans woman could ever hope to be. I mean, they just feel they communicate better. How can you argue with something a womyn-born-womyn just feels must be true. After all, she has a vagina and gave birth a few times, so that means she must just be a better person than any man or trans woman could hope to be, what with our incomplete XY configuration.

Seriously, all this feminism crap can cram it up its vagina. I've got karma to burn. I don't care.

I am utterly sick and tired of this shit. I am sick and tired of being beat over the head with Ada Lovelace because apparently, according to womyn-born-womyn, her vagina was the body part that enabled her to be a programmer. It couldn't possibly have anything to do with the gray matter between her ears or her reputation as an astute mathematician.

Where are the womyn-born-womyn taking programming classes? Where are the womyn-born-womyn educating themselves to prepare for a career in software development? Where the fuck are they?

And then these feminist assclowns think that the solution to the problem is to put completely unqualified womyn-born-womyn who wouldn't even be able to understand Lovelace's Notes into programming positions just because we absolutely need womyn-born-womyn programmers. "It's so unfair!" they scream. Show me womyn-born-womyn who are being turned away from programming classes because of their vaginas, and I might give a shit.

Show me a womyn-born-womyn who can even understand "garbage in, garbage out." You can't do it!

Yet we still need to get bashed over the head by Ada Lovelace and feminism. Obviously, everyone with a defective Y chromosome must be sexist! How do we know they're sexist? Because they have Y chromosomes! That's why they're sexist.

Never mind that these damned womyn-born-womyn can't even understand that Lovelace herself invented garbage in, garbage out.

Give me a fucking break. I'm sick of it.

Re:let me guess (0)

Anonymous Coward | about a year ago | (#43877871)

> Let me guess. This means that we need more womyn-born-womyn in software development ASAP

BZZT wrong. Next time read the article before going off on a self-delusional rant that makes you look sick AND stupid.

> I'm sick of it.

The voices? Get some help, maybe it will get better.

Re:let me guess (0)

Anonymous Coward | about a year ago | (#43877875)

Give me a fucking break. I'm sick of it.

Come on. Don't hold back. Tell us how you really feel.

Code quality (0)

Anonymous Coward | about a year ago | (#43877813)

Having taking over the code bases of a couple of start-up companies, I have found the code appalling - no in-line commenting, documentation or even a hint towards the concept of testability.

However, I've got to accept that as a start-up, if you have beautifully crafted and documented code then as a result you will be too late to market and your company will have gone under.

groupthink (1)

aahpandasrun (948239) | about a year ago | (#43877847)

Groupthink can destroy creative ideas if you don't have good synergy with the people you're working with. (Please excuse my use of the buzzword synergy). Since programming is partially a creative process, this makes sense.

Good encapsulation (0)

Anonymous Coward | about a year ago | (#43877895)

Yet, these smart people created modules that didn't talk to each other

This just means that they were properly encapsulating their classes.
The ideal program is one where there is no interaction between objects at all.
Source: just about any book about OO programming, or maintaining code.

Configuration Management (1)

Sedated2000 (1716470) | about a year ago | (#43877975)

Isn't this the exact kind of problem that configuration management is supposed to solve?

I call BS (4, Insightful)

bored (40072) | about a year ago | (#43878007)

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.

Collective agreement (4, Insightful)

Todd Knarr (15451) | about a year ago | (#43878033)

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

1st rule of coding (0)

Anonymous Coward | about a year ago | (#43878187)

"quality" is subjective.

Code works or it doesn't.... for the requirements it's suppose to fit (aka does it do what is asked).

But all the consultants sell the pipe dream of better quality. You can make a living out it.

Now get off my lawn...

boast? (0)

Anonymous Coward | about a year ago | (#43878235)

had previous written code that you and I would boast to have created.

It doesn't sound like it.........

It's called management (1)

charnov (183495) | about a year ago | (#43878635)

Management is it's own freaking science FFS... and large systems architecture is, too. Just because someone is a top tier programmer doesn't mean they can run a project to save their lives. I'm a LOUSY programmer... but I have managed hundreds of programmers on dozens of concurrent and many times linked projects and kept it together... because that's my skill set.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?