Forgot your password?
typodupeerror
Programming

When Smart Developers Generate Crappy Code 195

Posted by Soulskill
from the my-code-works-fine-so-it-must-be-your-fault dept.
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."
This discussion has been archived. No new comments can be posted.

When Smart Developers Generate Crappy Code

Comments Filter:
  • by rtfa-troll (1340807) on Friday May 31, 2013 @03:51PM (#43876995)
    people over processes; how deep.
    • by Anonymous Coward on Friday May 31, 2013 @04:03PM (#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.

    • by 0racle (667029) on Friday May 31, 2013 @04:04PM (#43877157)
      I wonder how many meetings we'll have this time around.
      • by Darinbob (1142669) on Friday May 31, 2013 @04:58PM (#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.

    • by Comrade Ogilvy (1719488) on Friday May 31, 2013 @04:23PM (#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.
      • by khasim (1285)

        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

      • by arth1 (260657)

        One of the main purposes of every flavor of formalized process is to enforce some minimum level of communication.

        Ah, the coercion fallacy - a belief that forced communication is better than no communication. Forced communication will, when there's a lack of true data to communicate, lend itself as a channel for made up data.
        You need to adjust the overall structure so communication becomes natural. And no, that does not mean "schedule meetings" and "demand reports". More like "put people who communicate well together", and give solo artists jobs where they have to solicit info from others, not the other way around.
        O

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

  • by Synerg1y (2169962) on Friday May 31, 2013 @03:54PM (#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.

    • by hondo77 (324058) on Friday May 31, 2013 @04:10PM (#43877227) Homepage

      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.

      • by Synerg1y (2169962)

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

      • by i kan reed (749298) on Friday May 31, 2013 @04:28PM (#43877437) Homepage Journal

        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.

        • by hondo77 (324058)
          +1 Informative
        • 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, we

        • by pclminion (145572)
          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.
        • > enums and switches
          > not using a function pointer.
          ISHYGD care about performance.

        • If they don't know when to define an interface, they are most certainly not in "quite skilled" category. Don't confuse smart with skilled; it happens all the time.

          • There are multiple skills in this industry, and they have good command of a number of specialized technologies we use, multi-threading principles, algorithm performance, and a number of a non-design skills. Having one skill doesn't give another.

      • 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 inter

      • by gl4ss (559668)

        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 the

      • by edelbrp (62429)

        Amen. I was once put as a lead programmer for an MVC project that was years behind schedule. What we found was appalling. And, I'm not kidding: They merged all the controllers in one giant class file, moved much of the views into the database (for no apparent reason) and used codewords throughout instead of meaningful class/variable names. They had painted themselves into such a corner that they were refusing basic feature requests because 'it wasn't possible' any more. They were big proponents for MVC

        • by St.Creed (853824)

          Overengineering is a common mistake in people who want to "do it right" and try to design resilience to every possible change. It never works, which is why Agile development emphasizes that building a "code inventory" is just running up a cost, not building an asset.

          But not having a clue really doesn't help.

    • 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

      • by stanlyb (1839382)
        GraphTalk. The only real Object Oriented Data Base, ever, created. And it even works.
      • by mbkennel (97636)

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

    • by alienzed (732782)
      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...
    • by edelbrp (62429)

      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 reasona

  • by Stumbles (602007) on Friday May 31, 2013 @03:56PM (#43877061)
    if it were then projects like Linux would have collapsed a very long time ago.
    • 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.

      • by Stumbles (602007)
        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 a
    • by Darinbob (1142669)

      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 s

  • by alen (225700) on Friday May 31, 2013 @03:56PM (#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

    • by Anonymous Coward on Friday May 31, 2013 @04:07PM (#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.

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

      • by Darinbob (1142669)

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

  • translation (Score:3, Informative)

    by Anonymous Coward on Friday May 31, 2013 @03:56PM (#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...

  • 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
  • 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: (Score:3, Insightful)

      by Anonymous Coward

      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 ma

      • by khasim (1285) <brandioch.conner@gmail.com> on Friday May 31, 2013 @05:36PM (#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.

        • Well, the 1 person does need a communication channel to their rubber duck.
        • Unless the division of tasks is done in a pathologically bad way, not everybody has to talk to everybody else about everything.

          Still, kudos for not [mis]using "exponential".

        • by eulernet (1132389) on Friday May 31, 2013 @07:10PM (#43879067)

          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 [gallica.bnf.fr]

          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.

          • by St.Creed (853824)

            This table only deals with the situation where they all work on the same thing.

            I recently had a crash project. If it didn't work out, the company would be forced to stop work until the project was completed. We were talking millions of dollars per day here, so the project was a tad urgent.

            First, the other information analyst was removed. Then I did the requirements. While they were being completed. a testmanager came in and started writing testcases on the requirements. A programmer came in and did mock-ups

            • by eulernet (1132389)

              I think that you were lucky.
              Luck has a great importance in software projects, but of course, luck is not random.

              I think that the most important fact that you don't mention is that everybody in your team was motivated, they felt that they had some power to do things.
              When you remove the sense of power, people lose motivation and produce some half-assed work.

              Then, I believe that you are an ex-programmer, and most of the managers I know pretend to be able to code, but when I check, I see that they are pretty ba

              • by St.Creed (853824)

                I think that's a fair summary.

                In my previous project I was in charge as architect/information analyst and lead designer, supported (and not hindered) by a very competent project manager who never got in my way but just made sure everyone had what he needed. In my current project things are very different - to the detriment of all.

          • by khasim (1285)

            With 8 people, you get the results of 4 people !

            So a basketball team with 4 people will tie a team with 8 people 50% of the time? (all individual skill levels being equal)

            Or a tug-of-war competition between two teams (one with 4 people and one with 8) of people with similar physical builds will be a tie.

            I always took Ringelmann's findings as support for "work expands to fill the available time" rather than an upper limit on a group's capabilities.

            • by eulernet (1132389)

              Good point !
              But in a sports team, the manager has some other players on the bench, so when he sees that a guy doesn't do his best, the player will be replaced instantly.

              As I explained in another answer, what is important in a team is the sense of power.
              If every member thinks that he can produce something significant (like in a sports team), then everybody will be motivated and will do their best.
              If somebody thinks that his effort will be insignificant, he'll quietly reduce his effort, and sometimes that mea

          • When you have 1 guy, he works at 100%, but when you add 1 guy, you get 93% of their combined force. [...] With 8 people, you get the results of 4 people !

            No wonder the pyramids took so long to build!

        • Every one in your team needs to communicate with every one? What kind of nonsensical system is that? Do you write code that way too? Every source file depends on every include file? Every library depends on every other library?
        • by turp182 (1020263)

          I love this type of information.

          Frankly, I think we should have a series of Slashdot headlines around software development and what people have found works. This crowd could provide very meaningful answers to such questions. Then summarize the best ideas and let people have at them again...

          Myself, I'm on a three developer team (3 channels, with lots of constant interaction) with a very technical manager (he always questions naming conventions and reviews our code and structure constantly, and he knows wha

    • by mysidia (191772)

      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.

      If you think 10 developers can complete a "400 man-hour project" in a normal work week, then you need to read up on Amdahl's law with inherent overheads of parallel processing, and realize... that humans are a lot less efficient, and a lot more overhead is required managing the parallelism

      A particular coding task doesn't have an intrinsic amount of time that it can be done in, that you ca

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

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

    That's pure brilliance. Groundbreaking stuff.

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

  • by Princeofcups (150855) <john@princeofcups.com> on Friday May 31, 2013 @04:29PM (#43877445) Homepage

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

    • by Tablizer (95088)

      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 sometimes don't mind people like that as long as they can carefully justify their choices. People forget that code is largely for people (to read), not computers. The computer doesn't "care" how you organize code; it just follows instructions. Code organization is a matter of human readability, and if the egomaniac can justify their decision in terms of that, then I'll respect them.

      H

    • I'm dealing with this ego shit right now. There's this developer who is highly regarded by his boss so he gives him complete free reign to do what he likes and rarely ever confers with his colleagues because he thinks he's smarter. He may actually be smarter but it doesn't mean he's a better coder. He makes common coding process and design errors all the time. He's fairly young so it's not unexpected but it's still irritating as hell because his decisions often effect the rest of us.

  • by TerraFrost (611855) on Friday May 31, 2013 @04:30PM (#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.
  • 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]

  • by msobkow (48369) on Friday May 31, 2013 @04:51PM (#43877705) Homepage Journal

    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.

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

      • by St.Creed (853824)

        Yup.

        All too often there are multiple "right ways" of going about things, like cooking. Or coding. It's not a problem if you boil your potatoes first, then peel them. Or if you peel, then boil. But if you have to reach a compromise and only peel half of them, the result is sub-optimal.

        If you have to pass something on the road you can go around it to the left or the right. Taking the middle because you had to compromise seldom works out.

        That's why more than one captain on a ship is a bad idea. Even two brilli

  • Isn't this the exact kind of problem that configuration management is supposed to solve?
  • I call BS (Score:5, Insightful)

    by bored (40072) on Friday May 31, 2013 @05:23PM (#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.

  • by Todd Knarr (15451) on Friday May 31, 2013 @05:26PM (#43878033) Homepage

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

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

  • Crappy programmers and crappy development process and crappy project management. It is actually that simple as to why crappy code exist. Well to be fair, it could be a huge bunch of inexeperienced coders mixed with a truly inexperienced team leader and/or project manager.
    1. 1) Before you get your programmers to actually produce code, there should be clear guidelines as to programming style and code construction
    2. 2) There should be peer review of your code before it is even sent for QA.

    All of these logistics

  • Despair.org has the poster [despair.com] 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"
  • 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 w

  • 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, t

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

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

  • At least I find myself doing this. http://en.wikipedia.org/wiki/Broken_windows_theory [wikipedia.org] 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.

If it smells it's chemistry, if it crawls it's biology, if it doesn't work it's physics.

Working...