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();
Just don't force me to hug the other coders. I will NOT hug coders!
Table-ized A.I.
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?
sudo make me a sandwich
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...
this load of bs (register). They are likely had crappy design of inter-module interfaces, that's it.
--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?
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.
You're assuming programmers care about the users. Remember Milton? :)
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.
public functions should be bulletproof. you can be as sloppy as you want with private functions. don't forget error handling as well.
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.
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.
This 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.
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?
It must have been something you assimilated. . . .
And, as it turns out, team communication is the heaviest dependency of all.
That's pure brilliance. Groundbreaking stuff.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
...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.
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.
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.
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.
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.
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.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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".
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.
code_quality = time * talent * experience * just_dont_care_factor
If you find code_quality nearing 0, that often means they just didn't care.
Apparently being "a people person" is important in the industry :)
It states that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations".
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.
I do not fail; I succeed at finding out what does not work.
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 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.
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 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.
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.
> 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.
Give me a fucking break. I'm sick of it.
Come on. Don't hold back. Tell us how you really feel.
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.
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
Isn't this the exact kind of problem that configuration management is supposed to solve?
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".
"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...
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.
had previous written code that you and I would boast to have created.
It doesn't sound like it.........
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.
[RIAA] says its concern is artists. That's true, in just the sense that a cattle rancher is concerned about its cattle.
I am quite familiar with this phenomenon, and have lamented it often. However, I disagree as to its cause. I don't think it's a result of anything so academic as communication issues. I think that, the larger a project or the more important, the more it is driven by non-technical management with unrealistic expectations, and no clue as to what is actually involved in getting computers and networks to do our bidding. They fail to consider the finer points of development and integration (or worse yet, poo-poo them), and then rush the expert, professional engineers through the most critical phases of their processes in the interest of sticking to their unrealistic and ignorantly dreamed-up timelines. The result is overruns of cost and time that would have been more than ample to do the job right in the first place, but instead are almost invariably used to polish a rotten apple just enough to get the customer to eat it.
If this were not all true, please explain why Scott Adams is a millionaire.
All of these logistics seem like afterthought for managers, and thus, the stupidity of dealing with crappy code.
In the end, it comes down to this: Crappy Code = Crappy Project Management.
A bit of organization upfront can save a lot of time, money and embarrassment down the road.
We have super detailed design documents and we still get bit by poor planning. For example, we have 2 groups working on 2 separate but highly related changes. It would have been okay if one was before the other, or if one team were doing both changes, but nope, management wants all of it done yesterday by separate groups. Of course there's going to be issues.
Despair.org has the poster for this one. None of us is as dumb as all of us. This is one of those dumbass articles intended to make programmers feel bad because we're not schmoozers and claim our code suffers as a result. It doesn't. The code suffers because bosses assume you can simply harness programmers together, probably under some MBA, assign them bits of the job ad-hoc, and you'll get miracles.
TFA does not seems to address software architecture. It is harder to contribute bad code to software that has good design.
"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I'd bet this was the standard cube farm, or worse, the open space "collaborative" environment where every conversation carries, making it impossible to focus without some headphones and some music. And nothing says "Hey, I'm approachable" like being hunched over a computer, heads bobbing to the beat.
You want to improve software productivity, start with the environment. Offices. With doors. That you can knock on, close and have a real conversation without distracting others.
Remember Pair Programming? For a while there, there were methodologies that demanded it for all code. Now, it's an afterthought or relic. Sure, most developers don't like it. I surely don't.
But, to be fair, the best development I ever did was working with someone else. It makes sense, being able to bounce ideas around, play off somebody else's strengths. I remember in college, me and a professor knocked out a workable xUnit-like test runner for C++ in a day. This was before cpptest, or course. That code was used for years in his class.
You want good code? Forget that open layout startup space. Get some offices, get some doors, and then get people off their chairs and knocking on them. Build trust by showing people that you value them.
Being a smart developer does not mean being a smart designer.
Being a smart developer means to make a program that has good performance, reasonable number of bugs, can easily be read by other people, etc.
Being a smart designer means code can be easily extended, patterns applied consistently across code, good modularization, can easily be refactored, low coupling etc.
What most projects, if not all, lack is software designers, i.e. people who design APIs, modules and interfaces of high quality.
In most cases, the developers are also the designers, but coding is such a process that losing track of design is extremely easy. You can easily preoccupy yourself with the details of the code and lose tracking of the big picture.
"...forces guiding our day-to-day software design decisions are social..."
Joke that's not quite funny: Quit hiring "brogrammers" and hire more "aspies" who totally don't get social at all, and this effect goes away. Have I used enough of this weeks Slashdot article buzzwords?
Frankly, from reading the article, it seems that there is a poor understanding of component interface contracts. This is like thinking you comply with POSIX because you have a stat(2) system call, but all the structure members are missing the "st_" prefix and/or there are missing structure memebrs which are mandated to be there by the standard. If you don't implement the interface to the interface contract, you've botched the code.
You can see this in Linux by running the VSU and VSX test suites, rather than the cut-down version that The Open Group has released for free. When you do that, you see all sorts of promiscuity in the type definitions in system header files - they typically fail negative assertion tests for things like definitions of size_t being in scope when they aren't supposed to be, as a side effect of including some other (putatively) POSIX header. BTW: negative assertion tests like this are done by using '#define size_t "size_t"' when you need size_t to NOT be in scope.
If your relationships between modules resemble team interpersonal relationships, then you are doing it wrong: (1) interfaces are either defined by an architect and handed down as if from God, or they are negotiated between producer and consumer instead, if you have a lot of time on your hands for that sort of thing; (2) bringing interpersonal relationships into code design is unprofessional, and you should only hire professionals.
junior devs write the .cpp.
(Sorry to be C++ centric).
or "technical lead" or "team leader" or whatever who was organizing how all the pieces fit together, and reviewing the team members' designs to ensure they're compatible with each other and the rest of the system.
It's a management failure that they didn't assign somebody to be in that role (or otherwise have the team choose who within the team will be the technical lead).
---------
There is inferior bacteria on the interior of your posterior.
At least I find myself doing this. http://en.wikipedia.org/wiki/Broken_windows_theory What I mean is that I think I'm a decent developer. However whenever I work on code that someone else did and it's already kind of sloppy I find myself slipping and writing sloppy code as well.(Shit like using magic numbers, writing code with warnings, functions that are too big, etc) Of course if I'm working on code where it's good I tend to follow the higher standards.
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
They ruin the software world,
their first inclination
is to chatter rather than code!
do it like they do where i work;
1) send out all important specs and other docs, in IM rather than email or even (god forbid) a document of some kind. or in a long boring phone call or, even better, phone conference.
2) make sure no developer knows anything about what the other developers are doing or what their requirements are or what their product is looking like
3) don't under any circustances answer any specific questions from the developers; if they get persistent, see item 1 again.
4) when developers present you with an intermediate version to check, do a quick glance/run and give them a thumbs up if it doesn't crash.
If that doesn't produce code modules that interact seamlessly, then I just don't know what our management is getting the big bucks for.
if you think everyone is beneath your "super" grey matter....I dont want to work with you, thats for sure. Not if your going to expect everyone else around you to use the force when you write your brilliant masterpiece.
As ridley scott said: "all sins are forgiven (no matter the anguish) when you succeed. When you fail, you fail hard."
Age should never come into it, if a you guy/gal has a better way of doing things then lets go. Sounds more like CEO prince charming syndrome.
I pity you. I know you're type, you hurt people with your grand idea of logic and sniff your nose at anything you deem unworthy of you. Your type would completely destroy a new dev's dreams (IE the reason's why they love this shit). A new dev needs you're type like he/she needs a third elbow.
C'mon sing it with me...
: )
Yes, a phone call needs to be answered now. You can reply to an email later.
I hate the interruptions when I am finally down to the make it happen phase. I enjoy the interaction during the planning and design phase.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Dude, relax. Feminism is dead. I can't really detect it in modern women and a lot of the older ones I have talked to say that feminism (as in every woman working) was a mistake. It hit me when I stayed home for a few years with my son while my wife worked. It was freaking great, although I didn't allow myself to get bored (coded full time at home while my son played in the room with me). Most of the feminist crap you hear is in the media, but it doesn't really resonate with the populace except to get people riled up. You can't affront nature very long.
I object to power without constructive purpose. --Spock
Sarah Mei is a whiny, entitled, man-hating, incompetent whore.
There is nothing she said that hasn't been said a million times before.
Is this really news that matters?